# Welcome to the KSC Wiki The hub for all technical, organizational, and operational information about Knights Satellite Club. We are the Knights Satellite Club, the University of Central Florida's student-led CubeSat program. This is where we document everything about what we do to the benefit of anyone. ## Who is this for? :white\_check\_mark: **KSC Members** - Get caught up on how the club works, what we've done, and start getting involved!\ :white\_check\_mark: **Other Student Groups** - Learn from our successes and mistakes, and do cool stuff!\ :white\_check\_mark: **Everyone** - Our mission is to accelerate space exploration through education; anyone counts! ## How to help? * If you're a UCF student, join [our Discord](https://discord.gg/fjKyphuaht) and come to the next GBM or project meeting. We can't wait to meet you! * If you are not a UCF student, feel free to join the Discord as well. Tell us where you are from, and we can discuss how you can help out. We love working with student groups from other schools. * If you are interested in working with us in some other manner, send us an email at . We are always looking for partners to further our mission through collaborations or contributions. Knights Satellite Club is a 501(c)(3) non-profit, so all donations are tax-deductible. ## Projects Each of our projects has individual documentation. Please select a project to view its contents.
Knight SatelliteArchived/files/nr8wkoF5s7BvCYdDIrkN/pages/M0UGKvhSReFjnbKU0mLY
Tethered SatOngoing/files/MqmxDo4kcc3KgEP139U6/pages/zck5kZyYGUpqAz6CXSq8
Knights Air Observation SatelliteOngoing/files/oUCWQZCJ97a0VV8itUMB/pages/PmqKO0jGS6C9c9NkYGyV
Ground StationsOngoing/files/akWpnU06ndg0kmToTQKA/pages/0kfH3hGmp7zZ0YnadtrF
Orbital CubeSatStarting Spring 2026!/files/Rizfs8kjgwZn1zWawl5t/pages/mszqCJFhC3gxOsfr4bn7
# Tethered Satellite Overview of the Tethered Sat program. Tethered-Sat (T-Sat) is the Knights Satellite Club's rapid iteration CubeSat test bed program. These are small, suborbital CubeSats which will be used to test individual subsystem on moored (tethered) balloon flights. T-Sat launches can happen frequently and are mostly launch site agnostic. T-Sat will eventually fly new missions each semester and is structured to allow students to quickly gain hands-on CubeSat experience. This is the recommended project for new members.
T-Sat-0Mission IArchived/files/MqmxDo4kcc3KgEP139U6/pages/JfbPX1RHD0i4RiyLbZJa
T-Sat-1Mission IIArchived/files/acQKvDgHVSM2ybg2nr1m/pages/Ct5MBYvkKrTYA8hufulT
T-Sat-2Mission IIIOngoing/files/ijupFTKkXqXpl036pdlu/pages/ap4Vtc6rvguF8KQjBd0N
# T-Sat-0 Explanation of the T-Sat-0 mission plan, goals, and architecture. Tethered-Sat (T-Sat) is an ongoing balloon project within the Knights Satellite Club initially beginning in Fall 2023 as a beginner-friendly, rapidly developed platform for hands-on learning and experimentation. The project was created to give new members an accessible entry point into satellite systems, reducing the intimidation factor of jumping straight into a full orbital CubeSat development cycle. By utilizing a tethered balloon as a launch platform, T-Sat offers an opportunity for students to engage with the full lifecycle of a CubeSat mission. From design and prototyping, to subsystem integration, testing, and launch all within the span of a single semester. This quick turnaround allows new members to see their contributions materialize in real time, creating a sense of accomplishment early in their involvement.\

Tethered-Sat 0 Flight Profile

Beyond being a training ground, Tethered-Sat also serves as a technical pipeline for the club. More experienced members are encouraged to take on subsystem leadership roles within T-Sat, developing their skills in team management and system integration before transitioning to larger, more complex club projects such as KAOS or our long term orbital CubeSat mission. This progression pathway supports both technical growth and leadership development across all experience levels. Additionally, T-Sat plays a vital role in the club’s research and development strategy. The platform is used to test experimental payloads, validate subsystems, and prototype new technologies before they are integrated into orbital missions. This makes Tethered-Sat not only an educational tool, but also a key component of the club’s iterative design philosophy and mission readiness pipeline.\ \ Tethered-Sat-0 (T-Sat-0) was the Knights Satellite Club's first iteration of the greater T-Sat Project. From project fruition to launch took a little over 3 semesters to complete. Moving forward T-Sat versions will follow a more rapid turnaround period to launch within a single semester or two depending on the demands of the experiment. With the structure, documentation, and launch operations developed during T-Sat-0 this goal will be attainable during future versions. ## Mechanical ### Mechanical Development of T-Sat-0 The mechanical team in the Knights Satellite Club faced the challenge of developing a deployable parachute mechanism for the T-Sat-0 mission, with the primary objective of ensuring a safe payload recovery post release from the burn wire. This endeavor was pivotal and fully centered on mechanical design and rigorous testing. ### **Initial Research and Decision** During the initial research phase, the team evaluated various deployment methods for the parachute system. Ultimately, it was determined that a spring deployment mechanism would offer greater simplicity and ease of integration within a 1U CubeSat, compared to a more complex pneumatic system. ### **Design, Prototyping, and Testing** The team embarked on designing the parachute deployment system (PDS), opting for an open-top canister design equipped with a spring-activated platform. This design aimed to facilitate efficient deployment while maintaining a minimal footprint. Multiple iterations of the PDS were created using 3D printing manufacturing, allowing the team to refine the design, reduce complexity, and enhance functionality. It was tested extensively through drop tests at a four story parking garage on campus. After a couple of failed deployments, and as a result broken parts, the team started using a large tablecloth held by two members to catch T-Sat to prevent damage during testing. This helped greatly and reduced the downtime between tests because of broken panels or parts that needed to be replaced with spare components.

Final CAD assembly of T-Sat-0 PDS

### **Finalization** Through continuous testing and improvement, the final design of the PDS emerged effectively balancing size constraints with operational reliability, thereby achieving the desired outcomes for the T-Sat-0 project.

Flight ready T-Sat-0

# Hardware Details about the mechanical components of T-Sat-0. ## Overview Our mechanical team worked on and iterated design using [OnShape](https://www.onshape.com/en/education/?utm_source=google\&utm_medium=cpc\&utm_campaign=Google_Pmax_NA\&utm_term=\&gad_source=1\&gad_campaignid=22457087470\&gbraid=0AAAAADgbnFnJ2gjElhw0XxAXQ2uHtQ79d\&gclid=Cj0KCQjwjJrCBhCXARIsAI5x66V6pDaH6F1gWIh6D9jksSAQk-fOqibjErFxy45Ss0BbCcIrh9YbisMaAndeEALw_wcB) as our CAD platform. The team developed two major components; [1U Housing Panels](#id-1u-housing-side-panels) and the[ Parachute Deployment System (PDS)](#parachute-deployment-system-pds). As a low cost and easy prototyping option we used 3D printing as our means of manufacturing utilizing PETG filament. This gave us freedom while iterating and helped our relatively inexperienced team at multiple points as changes were made on the fly during testing or other points during development. The mechanical team was also responsible for the [Launch Hardware](#launch-hardware) needed on launch day . ## 1U Housing Panels The housing used for T-Sat-0 was a[ Universal 1U](https://www.thingiverse.com/thing:4096437) (10x10x10 cm) found on Thingiverse. It was printed in PETG and contained slots for M3 nuts and bolts for attaching each panel.

Isometric view of the Universal 1U structure

Each of our panels was specifically designed to be mounted to our housing with its pre-dimensioned through holes as listed on the drawing on the housing page on Thingiverse.

Top and bottom panel drawing

Side panel drawing, consistent for all four sides

Fitting a canister large enough to contain a [24 inch nylon parachute](https://www.amazon.com/Estes-Nylon-Parachutes-Pro-Model/dp/B0071NXTCK/ref=asc_df_B0071NXTCK?mcid=cb63d1c12fbf3325ac6a0025d2efe662\&hvocijid=1387236039281515915-B0071NXTCK-\&hvexpln=73\&tag=hyprod-20\&linkCode=df0\&hvadid=721245378154\&hvpos=\&hvnetw=g\&hvrand=1387236039281515915\&hvpone=\&hvptwo=\&hvqmt=\&hvdev=c\&hvdvcmdl=\&hvlocint=\&hvlocphy=9057291\&hvtargid=pla-2281435179058\&psc=1) with a spring release mechanism in a 1U was one of the largest challenges for our team. This was the point that took the most revising and testing as initial prototypes where nearly twice the size of what would be our final hardware. We also had added requirements of securing a [3.7 volt 3 Ah LiPo battery](https://www.digikey.com/en/products/detail/mikroelektronika/MIKROE-4474/13679437?gad_source=1\&gad_campaignid=20243136172\&gbraid=0AAAAADrbLlgT-Bx2bEEux3I84RPcshTUt\&gclid=Cj0KCQjw0qTCBhCmARIsAAj8C4Zn-9abPx8C8oLW5JSKpuo_IiaJdKqwvTlXjQuw4Z39Qsn35Mz2GZYaAiPiEALw_wcB\&gclsrc=aw.ds), a [Arducam Mega 5MP SPI](https://www.digikey.com/en/products/detail/arducam/B0401/19116501?gad_source=1\&gad_campaignid=20232005509\&gbraid=0AAAAADrbLliEnLAkF7qAveyxn_iOWR-L2\&gclid=Cj0KCQjw0qTCBhCmARIsAAj8C4aWq8Wq-fkCzX5ZIKzm6ne_GKkCGVl-ikIGEEK_8w9Ez0h2zS9acJkaAssJEALw_wcB\&gclsrc=aw.ds), and various other access points for when T-Sat is assembled. In order to contain the required components within the housing we had to store all hardware besides our PCB within the side panels. ### Servo Panel This panel was the only one on the CubeSat that didn't have any mounting or access requirements which made it the best candidate for us to list our club sponsors.

Front of servo panel for T-Sat-0

### Access Panel A critical component for any flight ready CubeSat is a remove before flight pin to avoid battery drain while the CubeSat is assembled and awaiting launch. For T-Sat we aligned the pin height with our power switch on the PCB so we could easily cutoff power while assembled. The front of the panel also contained a raised ledge that allowed the team to insert the pin and twist it clockwise to lock it in place and prevent the pin from accidently being removed. This was an element that was added after the first assembly, were we found that the remove before flight pin could easily fall out while being handled. The panel also has two rectangle holes that function as access to our ESP32's micro USB header and our micro SD card. These elements were also additions to the panel so we could avoid unneeded removal of the panel. Both of which were vital for analyzing the data collected and making software changes while testing T-Sat while it was assembled.

Front of access panel for T-Sat-0

### Battery Panel To securely store our battery while having easy access to remove it for charging we added space for x4 3mm heat pressed threaded inserts that were used to bolt a back plate to the panel. At the bottom of left corner of the raised battery compartment we added a cutout for the battery cable to run to our PCB.

Front of battery panel for T-Sat-0

Rear of panel

### Camera Panel The Arducam was secured with a back plate that was taped to the panel itself and a pass through for the camera cable that runs to the PCB. The team originally had hopes of a back plate that slotted and clipped into place similar to a TV remote. There were multiple iterations made with this idea in mind but we found that thin walls and 3D printing of the components made the objective challenging. We ran into many issues with reliability of the design and the overall printability. This panel and the method for securing the camera is a priority for improvements to be made on T-Sat-1.

Front of camera panel for T-Sat-0

Rear of panel

### Top Panel The top panel contained four loops on the corners of the panel for the tether to attach to T-Sat and run to the burn wire. Ultimately, the team found that it was best to only use two loops with [#18 braided nylon](https://www.amazon.com/Romeda-Construction-Gardening-Braided-Masonry/dp/B0D2K7RHR5?ref_=pd_ci_mcx_mh_pe_im_d1_hxwPPE_sspa_dk_det_cav_p_11_2\&pd_rd_i=B0D2K7RHR5\&pd_rd_w=thncR\&content-id=amzn1.sym.57b80066-10e8-4be7-a5f2-ce3f1faa4959\&pf_rd_p=57b80066-10e8-4be7-a5f2-ce3f1faa4959\&pf_rd_r=Q3F7SKSMM5YVYR5YEBS8\&pd_rd_wg=5kU0R\&pd_rd_r=bc37c5ec-d1c4-4b6a-b0cd-4aca939d94ee\&th=1) tied between them with enough slack that the nylon would fall to the side and avoid blocking the PDS. The PDS was also mounted alongside the top panel using two of the corner bolt holes and nuts on the inside of the structure. This panel undertook few iterations as its requirements were very straightforward. One of which was adding fillets to the base of each loop to increase their tensile loading abilities.

Isometric view of top panel for T-Sat-0

### Bottom Panel The bottom panel functioned as protection for the pins of the breakout boards that were soldered to the PCB. It was mounted using the holes on two of the side panels with bolts that went through both. The four through holes on the panel were additions to the original design as we overlooked the need for clearance of the M2 Nylon PCB mounting screws.

Isometric view of bottom panel for T-Sat-0

## Parachute Deployment System (PDS) T-Sat-0's Parachute Deployment System functioned with the combination of five 3D printed components shown in the exploded view below. The additional hardware used in the PDS was a [23/32" x 3.5" compression spring](https://www.amazon.com/dp/B008RG54YG?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_2) and two separate M3 bolts that ran through the base and cap of the PDS to secure the spring to the canister. The system had to be printed as separate components in order for us to secure the spring in the canister. For the assembly of the canister we used both epoxy and plastic welding and neither created issues in our testing.

PDS exploded view

The PDS undertook countless revisions through many phases of testing. This is where 3D printing thrived as we had the flexibility to make substantial changes and compare multiple designs. It also allowed the team to perform drop tests without worries of damaging flight hardware as we were capable of printing several backups for critical parts that would often break during failed drop tests. This was one of our biggest lessons from the project, as trying to save a few dollars at times by purchasing a single electronic component or printing one of each panel caused a ton of delays during testing and even problems the night before our launch.

Isometric view of final PDS with servo linkage

The final design came from a culmination of improvements that we found were needed from testing. At the top of the canister, the two mounting arms were a common weak point if the parachute deployment failed as they would consistently snap with an upside down impact. After a couple of failures we added gussets to the bottom side of each arm which eliminated the issue. Another problem was the cap/plate that pushed the parachute would occasionally get stuck on the corner of the guide when it was rotated. This was fixed with a fillet on the corners to prevent it from binding as the spring pushed if it wasn't fully aligned with the vertical part of the guide. An adjacent problem to the system was the 9g micro servo we were initially using was undersized and was also being limited by the 3.7 volts we were supplying. We found that the 9g micro servo was only consistent if the battery was at or near peak voltage. We installed a 21g micro servo that worked without failure that we are going to use on T-Sat-1 as well. The last key issue is the servo linkage being used to rotate the plate for parachute deployment. The main problem with the linkage is the use of bolts to pivot the two links as the nuts backout after a few tests. This linkage was flown on T-Sat-0 but was the teams main point of concern and was carefully tightened before launch. Too loose and the nuts could back out and too tight and the linkage wouldn't pivot as it was needed to in order to pull at the right angle. In the end, significant testing got us to a place we were comfortable with as we were able to revise what was needed and account for potentially points of failure on launch day. {% embed url="" %} ## Launch Hardware T-Sat-0 was flown with a 600g weather balloon filled with a 125 cubic foot tank using helium as our lifting gas. To tether the payload a forty five pound plate was used with the [#18 braided nylon](https://www.amazon.com/Romeda-Construction-Gardening-Braided-Masonry/dp/B0D2K7RHR5?ref_=pd_ci_mcx_mh_pe_im_d1_hxwPPE_sspa_dk_det_cav_p_11_2\&pd_rd_i=B0D2K7RHR5\&pd_rd_w=thncR\&content-id=amzn1.sym.57b80066-10e8-4be7-a5f2-ce3f1faa4959\&pf_rd_p=57b80066-10e8-4be7-a5f2-ce3f1faa4959\&pf_rd_r=Q3F7SKSMM5YVYR5YEBS8\&pd_rd_wg=5kU0R\&pd_rd_r=bc37c5ec-d1c4-4b6a-b0cd-4aca939d94ee\&th=1) ran through a hole in the center of the plate. A 360 degree swivel with two carabiners on either side was used to rig T-Sat to the 500ft nylon tether. For future flights 3D printed or other non-metal alternative carabiners will be used to reduce the volume of lifting gas needed. As generating enough lift with the harsh winds on launch day was a challenge and the excessive size and weight of the metal carabiners utilized more of our lifting capabilities than what was required.

T-Sat-0 being lifted simultaneously with another clubs payload. The parachute deployed prematurely due to acceleration readings that triggered our freefall detection threshold.

Another key component within the rigging was a 3D printed stabilizer that can be seen in the image above. This was necessary as we were flying another payload belonging to another club and wanted to avoid tangling. With 3D-printing being our means of manufacturing. Our mechanical team decided on using PLA filament, as it is a budget-friendly prototyping option. Allowing there to be a bit of leniency when it came to adjusting any errors that showed up, such as incorrect measurements or mishaps in the design process. With PLA filament also gives us the ability to create spare parts as needed. Even so, PLA did have its downsides when it came to the rigidity and durability of the prints. In which our mechanical team took notice and decided to change to a PETG filament, relieving such problems. In turn, making our final material of choosing to be PETG.

Flight Day Final Assembly

# Electronics Details about the electrical subsystem of T-Sat-0. # Software Details about the T-Sat-0 flight and ground software running on ESP32 and Seeeduino XIAO microcontrollers. ## Overview T-Sat-0 utilizes 3 pieces of software. The [Flight Software](#flight-software-tsat0-fsw), [Burnwire Receive Software](#burnwire-receive-burnwire_recv), and [Burnwire Send Software](#burnwire-send-burnwire_send). The main payload runs the Flight Software on a DOIT ESP32 DEVKIT V1. The Burnwire Receiver that attaches the payload to the balloon runs the Burnwire Recieve software on a Seeeduino XIAO. The Burnwire Transmitter runs the Burnwire Send software which also runs on a Seeeduino XIAO. ## Development Environment All of the software is developed with the [Arduino IDE](https://www.arduino.cc/en/software/) and external libraries. Unless stated otherwise, all libraries can be found in the Arduino IDE Library Manager. ### Dependencies * **Arduino ESP32 Core** ([installation instructions](https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html)) * **Seeeduino Arduino IDE Support** ([installation instructions](https://wiki.seeedstudio.com/Seeed_Arduino_Boards/)) * **Radiohead** by Mike McCauley (Arduino IDE Library Manager version is outdated, [download directly](http://www.airspayce.com/mikem/arduino/RadioHead/)) * **Adafruit MMA8451 Library** by Adafruit * **Adafruit BMP3XX Library** by Adafruit * **Adafruit GFX Library** by Adafruit * **Adafruit SSD1306** by Adafruit * **Arducam\_Mega** by Arducam * **ESP32Servo** by Kevin Harrington ## Flight Software ([TSat0-FSW](https://github.com/UCF-Knights-Satellite-Club/Tethered-Sat-0/blob/main/software/TSat0-FSW/TSat0-FSW.ino)) The T-Sat-0 FSW is written in C++ using the ESP32 Arduino Core. This allows use of existing Arduino libraries and includes FreeRTOS. The FSW monitors altitude and accelerometer readings to determine when to deploy the parachute. ### Tasks The Flight Software makes use of 3 main FreeRTOS tasks. All tasks run on one core since a single ESP32 core is more than enough and multi-core software is more complicated. | Task Name | Job Description | Priority | Frequency | | -------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------------- | | Check Altitude | Continuously monitor the altimeter and accelerometer and manage the state machine. | 2 | 20 Hz | | Camera Capture | Capture pictures with the ArduCam and copy the image data to the SD card. | [tskIDLE\_PRIORITY](https://www.freertos.org/Documentation/02-Kernel/02-Kernel-features/01-Tasks-and-co-routines/15-Idle-task) | Whenever possible | | Log Data | Write sensor data to the SD card. | 1 | 10 Hz | The Check Altitude task must run at 20 Hz which means any functions need to return with minimal delay. Sensor data is pushed into a queue which the Log Data task then writes onto the SD card. This is to reduce contention between the SD card and ArduCam over the SPI bus to prevent delays. ### State Machine The Flight Software utilizes a state machine to perform various tasks throughout the flight. The states can only move forwards and can only be reset by a reboot.
State NameFunctionDescription
CALIBRATIONcalibrationRunAverage several altimeter readings to determine starting altitude. Immediately moves to PREFLIGHT when done.
PREFLIGHTpreflightRunMonitor altimeter and accelerometer to detect liftoff. Move to ASCENT once detected.
ASCENTascentRunMonitor altimeter and accelerometer to detect Burnwire activation and free fall. Move to FREEFALL once detected.
FREEFALLfreefallRunMonitor altitude during free fall and compare against preset deployment altitude.
LANDINGlandingRunParachute deployed, (hopefully) gently return to the ground.
This system is designed to ensure that the parachute will always be deployed if the payload is in free fall and below the deployment altitude. This is done to be resilient against scenarios such as a premature separation. ### Image Capture The ArduCam makes taking images extremely simple. JPEG encoded image data is copied from the camera over SPI and written directly to the SD card. Image transfer speed is limited by the SPI clock speed which is set to 1 MHz for stability. It takes 20-40 seconds to successfully transfer an image which necessitates the Camera Capture task to be run at the lowest priority to not inhibit other operations. Only data between the JPEG file header 0xFFD8 and the JPEG file footer 0xFFD9 is written to the SD card. ### SD Card The SD card must be FAT32 formatted; exFAT will not work. We have had write issues due to the cards getting corrupted, a reformat usually fixes this. Files will be written to a new folder each run named tsatlogX with X being incremented with each run. All sensor data is logged to data.csv and images written to picY.jpg with Y being incremented with each picture. ## Burnwire Receive ([burnwire\_recv](https://github.com/UCF-Knights-Satellite-Club/Tethered-Sat-0/blob/main/software/burnwire_recv/burnwire_recv.ino)) The Arduino program for T-sat 0 listens for a specific message from its ground station via (RH\_RF95) When it receives this message it activates a burn wire, which will cut and detach the T-sat from the ballon. It also sends a message back to ground confirming the burn process. ## Burnwire Send ([burnwire\_send](https://github.com/UCF-Knights-Satellite-Club/Tethered-Sat-0/blob/main/software/burnwire_send/burnwire_send.ino)) This Arduino program for T-sat 0 ground station, When a button is pressed, it sends the message ("BurnWire") to the T-sat using the RH\_RF95 LoRa radio module. it also turns on an LED indicating that the message is being sent, and waits for a reply from T-sat to confirm the burn process. # Flight Results Results collected from the 2/20/25 test flight of T-Sat-0. ## Overview T-Sat-0 took flight from the UCF Arboretum on the morning of January 20th, 2025. The same balloon was used for two flights. The parachute deployed early on both flights, and the burn wire detachment system was used successfully on the second flight. ## Flight 1 The first flight carried T-Sat-0 and MEDUSA, a Muon detection experiment from the UCF Astronomy Society.

Altitude graph for flight 1 of T-Sat-0. Measured in m.

The mass of both payloads and rigging hardware was around 1300g and close to the limit of what our balloon could lift. Due to this, wind caused the payloads to get pulled sideways and down faster than the balloon could lift them up. This flight lasted around 3 minutes reached an altitude of 34m (111ft) before high winds caused T-Sat-0 to hit a tree and break free from the balloon.

Acceleration graph for flight 1 of T-Sat-0. Measured in m/s/s.

T-Sat-0 was programmed to only deploy it's parachute after it began falling. One way of detecting free fall was to check when the onboard accelerometer read close to zero. The threshold was set to 2m/s/s which was hit several times during the flight causing the parachute to deploy early. We believe the accelerometer readings were caused by the high wind and manually releasing the tether inconsistently.

Ascent velocity graph for flight 1 of T-Sat-0. Measured in m/s.

The second way of detecting free fall was to monitor the rate of change in altitude measured by the onboard barometric altimeter. The threshold was -5m/s which was not reached during this flight. The parachute only needed one trigger to deploy so the ascent velocity data was effectively ignored.

Temperature graph for flight 1 of T-Sat-0. Measured in °C.

T-Sat-0 also records the temperature during flight. There was not much variation during this flight, but the higher temperature before and and after landing could be caused by handling of the payload.

T-Sat-0 flight 1 being pulled into trees by wind.

Picture taken by T-Sat-0 during flight 1.

## Flight 2 Once the balloon was reeled in, MEDUSA and some rigging hardware was removed. The new payload mass was around 500g. The same balloon was used so the lift to mass ratio was much higher than before.

Altitude graph for flight 2 of T-Sat-0. Measured in m.

This flight overcame the winds and achieved a max altitude of 119m (390ft) before the burn wire was remotely triggered and T-Sat-0 detached from the balloon. Unfortunately, the payload drifted to a paved area and was destroyed when it hit a concrete loading dock.

Acceleration graph for flight 2 of T-Sat-0. Measured in m/s/s.

Again, rough conditions and inconsistent tether release caused the accelerometer reading to go below threshold and activate the parachute. The early deployment caused the excessive drift which led to the destruction of the payload.

Ascent velocity graph for flight 2 of T-Sat-0. Measured in m/s.

The ascent velocity dipped below the -5m/s threshold only after the burn wire had triggered. Based on this, we can conclude that had we only relied on the velocity data the parachute deployment would have likely worked correctly. This graph shows that T-Sat-0 was falling at 6m/s after the parachute deployed.

Temperature graph for flight 2 of T-Sat-0. Measured in °C.

For this flight, the temperature clearly follows the altitude. Contrary to expectations, the temperature rose with altitude. This may be due to ground absorbing heat after the cold night. {% embed url="" %} ## Lessons Learned This was the first balloon flight from KSC. Lots of things went wrong but it was overall very successful. Here is what we want to improve on: ### Mechanical * Build 3 models - one for the Mechanical Team, one for the Avionics Team, and one for flight. * Invest in tools and equipment to build and test prototypes. * Order backup components to test, allow for faster development, and allow for quick recovery after losing or breaking components just before launch. * All future 3D printed housings should be using heat-press threaded inserts rather than the difficult to work with nut inserts. * Never use bolts as linkage pivot points. * No more press fit back panels, all should be bolted or otherwise secured. ### Avionics * When utilizing servos, supply a minimum of 4.8V. * Use a less sensitive or different style of power/RBF switch. * Invest in aerospace grade switches (definitely not overkill). * Place accelerometers in the middle of PCB to prevent centrifugal forces creating very messy data for free fall detection. * Investigate better algorithms and filtering for more reliable free fall detection. * Investigate new camera with faster image processing (ArduCam Mega limited to 20+ sec per image). * Integrate components onto PCB rather than using breakout boards. * Invest in programmer and debugger. * Develop real-time Tx/Rx capabilities with payload for better debugging before and during flight. * Implement real satcom capabilities for transmitting commands such as force reboot. * Develop proper ground station (maybe future project for mobile, general purpose ground station: SBC + antenna mount + SDR transceiver). * Investigate storing flight-critical data in persistent memory since if T-Sat-0 rebooted in-flight it would lose its ground calibration. * Invest in proper battery charging bays that can charge multiple batteries at once. * PCB design changes * Connector for RBF switch to make it chassis mounted (not directly mounted to PCB). * Better chassis mounting method (ground plane reinforced screw mounts on PCB). Metal standoff screws with Loctite or something more robust than nylon screws. ### Operations * Monitor wind conditions and prioritize for go/no go decision. * Mass and gas calculations need to be completed ahead of time. * Invest in physical force scale (physics weights). * Invest in hardware gloves. * Better way for releasing (and retracting) tether line consistently. * Do not underestimate the length of approval process for campus flights. Start early! * Set up payloads inside initially. # T-Sat-1 Explanation of the T-Sat-1 mission plan, goals, and architecture. Tethered-Sat-1 (T-Sat-1) was the Knights Satellite Club’s second balloon-based CubeSat mission and the direct successor to [T-Sat-0](/projects/tethered-satellite/t-sat-0). The goal of this mission was not to introduce a new experiment but to refine and validate the systems first flown on T-Sat-0. Lessons learned from the initial mission directly shaped the design, software, and operations of T-Sat-1, ultimately resulting in a smoother flight and a successful parachute deployment at the correct altitude. Where T-Sat-0 served as a proof of concept, T-Sat-1 demonstrated maturity. The most important change was the elimination of accelerometer based freefall detection, which in the past had caused premature parachute deployments. For T-Sat-1, the [software](/projects/tethered-satellite/t-sat-1/software) was restructured to rely solely on barometric altitude readings, ensuring the parachute deployed only once the payload crossed the programmed altitude threshold in true free fall. This improvement greatly increased mission reliability. The mission showed that an iterative, semester to semester development process works. Deployment, housing, and operational issues identified during T-Sat-0 were directly addressed in T-Sat-1. As a result, the payload completed a clean ascent under the weather balloon, separated successfully using the burnwire system, and deployed its parachute exactly as planned. This can be seen in the [flight results](/projects/tethered-satellite/t-sat-1/flight-results). Key objectives of T-Sat-1 included: * Validating usability improvements to mechanical components. * Proving the effectiveness of barometric only deployment logic. * Improving launch day operations through better planning, tools, and hardware usability. * Continuing to develop rapid turnaround workflows for new member training. By achieving these goals, T-Sat-1 refined the tethered balloon platform and solidified the T-Sat program as a dependable test bed for subsystem validation and hands-on training. # Hardware Details about the mechanical components of T-Sat-1. ## **Overview** The hardware for T-Sat-1 built directly on the mechanical foundation of T-Sat-0 but corrected critical shortcomings identified in earlier testing and flight. Several subsystems were reworked for greater robustness, usability, and integration, while others were streamlined to improve handling on launch day. The CubeSat continued to use a 1U form factor with PETG 3D printed components for rapid prototyping and iteration. ## Major Improvements from T-Sat-0 * [**Parachute Deployment System (PDS)**](/projects/tethered-satellite/t-sat-0/hardware#parachute-deployment-system-pds)**:** * Linkage problems, where pivot bolts would loosen or bind, were redesigned for more reliable motion * [**Housing and Panels**](/projects/tethered-satellite/t-sat-0/hardware#id-1u-housing-panels)**:** * The 1U structure was updated to use heat-pressed threaded inserts for panel mounting, improving assembly consistency * The camera panel was redesigned with the same threaded inserts as the battery panel, addressing the failures of thin-walled 3D printed parts from T-Sat-0

Figure 1: T-Sat-1 redesigned housing capable of using 3mm threaded inserts

Figure 2: Front of camera panel for T-Sat-1

Figure 3: Rear of panel

* **Materials and Manufacturing:** * PETG remained the material of choice, balancing durability and flexibility * Extra housings and panels were printed to allow for parallel testing and flight backups, eliminating the bottlenecks experienced when single components broke during T-Sat-0 * [**Launch Hardware**](/projects/tethered-satellite/t-sat-0/hardware#launch-hardware)**:** * Rigging was simplified and lightened using appropriately sized 3D printed carabiners and rings * Ground support equipment was expanded to include physics weights for lift testing and a 25 lb iron anchor for tether stability, making launch day operations more predictable and controlled ## Outcomes The T-Sat-1 mission successfully demonstrated controlled separation and parachute deployment at the programmed altitude. By addressing both mechanical and software shortcomings of its predecessor, T-Sat-1 achieved a complete and reliable flight cycle. This mission validated the T-Sat platform as an effective stepping stone between basic student projects and more complex efforts such as KAOS and the orbital CubeSat program. Although the PDS is not a system intended for long-term use in future missions, it served as an excellent engineering challenge. The development process gave the team valuable skills, practical testing experience, and awareness of pitfalls to avoid in subsequent designs. T-Sat-1 stands as proof of the club’s iterative design philosophy: start simple, learn quickly, and refine relentlessly. # Electronics Documentation for the electrical subsystem of T-Sat-1. # Software Documentation of the changes between the TSat-0 and TSat-1 flight software. Since TSat-1 used the same electronics as TSat-0, most of the software stayed the same. The main differences were removal of accelerometer based triggers and improvements to the picture writing code. ## Accelerometer Triggers The accelerometer-based triggers for TSat-0 caused premature parachute deployment. Improved data filtering or processing was considered but the barometric altimeter data was very reliable so we decided to move forwards using only altimeter data. ## Picture Transfers One of the biggest problems with TSat-0 was the slow picture rates. Since the Arducam and SD card use SPI, we are somewhat limited in the speed which we can transfer data. We also had a high rate of corrupted pictures where all JPEG data after a certain point was missing. ### Buffer Size The code works by reading blocks of data from the cameras using the `readBuff` function provided by Arducam. This function can only read 254 bytes at a time which is then written to the SD card. The ESP32 SD card library is much more efficient with larger writes so we increased the buffer size to 4096 bytes and filled it with multiple calls to `readBuff`. This appeared to speed up file writes fairly significantly. At the time we also thought it somewhat improved the situation with corrupted files but that may have just been due to faster transfers providing less time for whatever was causing the corruption to occur. ### Image Corruption This was the most important fix. What's the point of having a camera if all the images are corrupted? We confirmed that all image data was being transferred from the Arducam to the ESP32 by checking for the JPEG magic bytes `0xFFD8` and `0xFFD9` which signify the start and end of a JPEG file. The ESP32 was always finding the ending bytes but on corrupted images they were missing indicating the bug was with writing data to the SD card. After more investigation, we found that calls to `write` from the ESP32 Arduino Core would sometimes fail and return 0 bytes written. The code did not previously check for the return value and assumed that all bytes got written. The really strange thing is that once `write` would fail and return 0, all subsequent calls would also fail and return 0. The only way we could find to get `write` to work was to close and reopen the file. The new code checks for that 0 return value and automatically closes and opens the file. This drastically reduced the frequency of corrupted images. ### SPI Clock Speed We previously slowed down the clock speed because it helped with the corruption problems. This worked, but meant that it could take 30 seconds to write a single \~500 KB JPEG file. This meant that our first flight which lasted a little longer than 3 minutes only recorded 16 photos. The system should be capable of much more than that. Once we found the main corruption issue, we experimented with increasing the SPI clock speed. We originally had it reduced to around 1 MHz and were able to increase it to 16 MHz before the SD card started crashing. This increased the speed for copying images off the cameras as well as the SD writing speed so had a very significant effect. Over the \~4 minute flight we recorded over 80 photos. ## I2C Clock Speed We occasionally noticed some issues with our I2C devices. Devices would fail to initialize with errors such as these. ``` E (9) i2c.master: I2C hardware NACK detected E (10) i2c.master: I2C transaction unexpected nack detected E (10) i2c.master: s_i2c_synchronous_transaction(924): I2C transaction failed E (15) i2c.master: i2c_master_transmit_receive(1220): I2C transaction failed ``` The I2C bus speed defaults to 100 kHz when using the ESP32 Arduino Core. Using a logic analyzer we saw invalid packets and a lot of NACK packets in these error states. We tried decreasing the clock speed to 50 kHz which permanently resolved this issue. # Flight Results Results collected from the 6/21/25 test flight of T-Sat-1. ## Overview T-Sat-1 took flight from the UCF Arboretum on the morning of June 21st, 2025. The burnwire mechanism worked correctly allowing the parachute to deploy successfully and at the correct altitude. ## Flight 1 The flight of T-Sat-1 began around 9:30 AM and reached a max altitude of roughly 125m (410ft).

Figure 1: Altitude graph for flight 1 of T-Sat-1. Measured in m.

Figure 2: Temperature graph for flight 1 of T-Sat-1. Measured in °C.

Figure 3: Temperature vs. Altitude graph for flight 1 of T-Sat-1. Temperature measure in °C. Altitude measured in m.

Figure 4: Ascent velocity graph for flight 1 of T-Sat-1. Measured in m/s.

{% embed url="" fullWidth="true" %} Video from the ground as the burnwire radio signal was sent and then received by the burnwire. {% endembed %} Due to T-Sat-1 getting caught in a tree at the arboretum we were limited to a single flight. We were able to recover T-Sat a day later when one of our members climbed the tree and untangled the parachute. {% embed url="" %} Pictures captured from T-Sat-1 flight. {% endembed %} {% embed url="" %} Pictures captured the day after launch while T-Sat-1 was stuck in a tree during a thunderstorm. {% endembed %} # T-Sat-2 Explanation of the T-Sat-2 mission plan, goals, and architecture. In the Tethered-Sat 2 mission, the team has decided to bifurcate the work into two focused sub-projects: **T-Sat 2A** and **T-Sat 2B**, each with its own scope but working toward the common mission goals. * **T-Sat 2A** will concentrate on the *mechanical, deployment, and hardware systems*. This includes a controlled separation system with deployment by a parachute. Essentially, 2A handles everything needed to make the physical system fly, deploy, and behave safely and reliably with attachments such as on-board cameras and sensors. * **T-Sat 2B** will be more focused on *optical, electronic, and software systems*. This covers the cameras, altitude sensors/readings, remote control / telemetry, possibly image capture and processing, and the software that will interpret data and drive control of deployment or parafoil steering. B will ensure strong integration of electronics and software to support the hardware platform designed by 2A. {% hint style="info" %} This mission will begin Fall 25' with more information to be published soon. {% endhint %} # T-Sat-2 Mission A # Weekly Reports Team reports which cover each subsystems progress. {% hint style="success" %} This mission is actively happening this Fall 25' with more information to be published soon. {% endhint %}
Week 1 (9/16/25) Date:  9/16/25 * The Tethered-Sat 2A team held its first project meeting to discuss deployment mechanisms for the satellite. The group initially considered using a drone system, either mounted on the side or bottom of the satellite and released through a servo-activated trapdoor, with a potential housing size of 2U to accommodate the design. After discussion, the team decided to move forward with a guided parafoil deployment system. Unlike a passive parachute, this system will incorporate mechanisms to create controlled swaying, enabling remote steering during descent. * Cameras and altitude sensors will be included, along with a spring-loaded parafoil release system, though the exact deployment method is still under consideration. * To organize the project, four subsystem teams were established: Communications, focusing on aviation and camera integration; Mechanical, covering motors, servos, and CAD design; Guided Parafoil, responsible for motorized control of the parafoil; and a separation system team, tasked with developing a scissor-like snipping mechanism mounted separately from the 2U satellite but attached to the balloon, ensuring the satellite functions independently once released. Date: 9/18/25 * Through this Tethered-Sat 2A team meeting there was progress in the discussions on what would be the final product as was mentioned in the previous meeting on a goal that wanted to be achieved. With the design continue being a 2U satellite. * With the bottom 1U part being where two cameras will be mounted, with one of the cameras being directly on the bottom panel facing and the second one being mounted on the one of the side panels. With the opposing panel having a customized structured side panel wall that will have trusses formation to hold the PCB stack that will be used. Allowing for quick and easy insertion of the PCB stack there will be slidable rail attachment to the structured walls. * Focusing on the PCB stack itself, the first layer will contain all the modules that will be used from; ESP32, SD module, camera module, power distributor, and ready-to-launch switch. With the second layer being more focused on the power distribution and the direct to PCB terminal connectors. Such as connectors for the battery packs, servomotors, and cameras. Finally, with the final and third layer to this stack not actually being a PCB itself but inside a 3D-printed panel that will have aligned holes to stay connected to the stack. Which will be used as the mounting point for all the battery packs that will be used., allowing all the electronic components to stay as close as possible. * Leaving 1U of the space of the satellite to be used for the control system of the parafoil. Which will be working by a horizontal like reel system powered by a servo which will be connected to a couple of the strings on the parafoil to allow sway to happen for a controlled guidance. With the other strings being attached to the top of the satellite through the top panel and its mounting points that will be used for stabilization. * While the reeling system will only take-up to 0.5U of the free space, all other space will be equipped by the spring-loaded system that will allow the parafoil to pop out deploy. The scissor-like snipping mechanism stayed the same as the past meeting. Without any change to the design.
Week 2 (9/23/25) Date: 9/23/25 * Continuing from the meeting that took place on the 9/18 the T-Sat team decided to scrape the idea of the spring-loaded system. Instead, the discussion began about the idea of a top panel separation system. * With this idea it would involve the whole 2U satellite being separated from the top panel so the top panel can stay attached to the ballon with the whole 2U housing becoming its own system allowing for guided deployment. With another modification being the servomotor position that will be involved in controlling the guidance. Instead, it will be standing vertically for easier control in the sway with better stabilization even if there is much air resistance against the whole housing. * In creating the separation, which would be where the four servos will take place and be the stabilizing and mounting point for both systems. Each servomotor being mounted on each respective side panel with having an attachment. With the attachment that will be connected to the servomotors being a half cylindrical ring. With having a flat part that can be used to screw into the servomotors while the slide that would involve having contact with the part connected to room of system 2. Except instead of a complete ring, there will be an opening on the ring. With the part that would be connected to the roof of system 2 being a hook-like mechanism. The design would involve making it a hook, except if it is hanging upside down from the roof. In doing so the servomotor ring link would just be connected to the hook by inserting it through the opening of the ring then, rotating the servo so it is doing connection to the ring itself. Once commanded or desired altitude has been achieved and through confirmation of the team at the launch sight the servomotor will rotate to the opening in the ring allowing system 2 to become its own payload which goes into freefall and deploys the parafoil through air resistance. * With the rest of the meeting involving just listing needed parts for this mission and finalizing the design, so the T-Sat 2A team lead can submit the Mission Concept Review (MCR) to the board for approval of the mission. Date: 9/26/25 * As stated from the past meeting taking place on 9/23, the Mission Concept Review (MCR) was submitted to the board. Through further discussion between the board and T-Sat 2A team lead the decision involving how this mission would proceed was modified. With the main focus of T-Sat 2 being a mission project that can be completed in one school semester while being an introductory project for any members, it was decided the guided parafoil would push that deadline quite a bit and quite complicated for newer members. As such the team lead had to inform the rest of the team of the heart-breaking news. * With the main focus of the project now being on the separation system that involves the top panel and the 2U CubeSat becoming its own system. As such there was a modification of the items needed for the mission which was the main focus of the meeting. Allowing there to be a start on the CADing for next meeting.
Week 3 (9/30/25) Date: 9/30/25 * As stated, the previous meeting taking on 9/25 where the main mission had a bit of medication, which changed the parts list. Making confirming and finalizing the items needed for this mission the focus of the beginning of the meeting, which will be sent to the Knight’s Satellite Club (KSC) treasurer for approval. * Once the budget list was completed, the CADing of the PCB and housing began. With most of the time being used to teach and allowing the team to get accustomed to each software. While each respective team brainstorming ideas on the design and assortment the housing was going to be created. * At the same time the software team was looking back at previous T-Sat mission code to get an idea of how it was assorted. Which leads them to decide on creating a five-step calibration system for the mission. The first being **Calibration**, which will get started as soon as the ready-to-launch pin gets removed and will set the starting point as altitude zero. Once there is a gain in altitude the second step **Preflight** begins which is in waiting state for the third step **Ascend**. In the step is where the cameras will get activated and keep on taking pictures until **Freefall** state. This fourth step would involve the separation of the system that can be initiated by manual button or if it reaches a certain height of 400ft. The last step being **Landing** which will begin retaking pictures for the descent until the ready-to-launch is placed back in. Since the milliseconds between the **Freefall** state the pictures will stop to allow the servomotor command to begin. All while data of altitude and the pictures being record in an SD card. * The next meeting will involve counting these three teams’ progression in CADing both housing and PCB. With start of writing code for the final flight and test code that will be used for testing hardware. Date: 10/2/25 * No notes recorded :/
Week 4 (10/7/25) Date:  1\. Progress This Week * Key accomplishments / milestones. 2\. Issues / Blockers * What challenges came up? * How were they addressed (or what support is needed)? 3\. Priorities for Next Week * Key tasks and deadlines to focus on. 4\. Risks / Concerns * Potential risks, delays, or scope changes. * Any risks that might affect deliverables or timelines. 5\. Support Needed (optional) * Resources, tools, or leadership input required. * Cross-team collaboration or dependencies. 6\. Notes / Lessons Learned (optional) * Testing notes, design trade-offs, or upcoming reviews/tests. * Lessons learned this week worth sharing. * Anything you’d like feedback on before finalizing.
Week 5 (10/14/25)
# TSAT 2B Weekly Reports Weekly Reports for TSAT - 2B Week of 9/15/2025: Started planning the main goals of the project and what we want the satellite to be able to do, and began the Project Concept Proposal document. Week of 9/22/2025: We'll see when we get there :) # Software Details about the software components of T-Sat-2A. The software ... {% hint style="warning" %} This mission already happened. {% endhint %} # Electronics Details about the electrical systems components of T-Sat-2A. {% hint style="warning" %} This mission is actively happening this Fall 25' with more information to be published soon. {% endhint %} # Hardware Details about the mechanical components of T-Sat-2A. {% hint style="warning" %} This mission is actively happening this Fall 25' with more information to be published soon. {% endhint %} # Flight Results Details about the upcoming flight of T-Sat-2A. {% hint style="danger" %} This mission is actively happening this Fall 25' with more information to be published soon. {% endhint %} # T-Sat-2 Project B # Weekly Reports Weekly Reports for TSAT - 2B {% hint style="success" %} This mission is actively happening this Fall 25' with more information to be published soon. {% endhint %} Week of 9/15/2025: Started planning the main goals of the project and what we want the satellite to be able to do, and began the Project Concept Proposal document. Week of 9/22/2025: We'll see when we get there :)
Week: 9/15/25 Date:  9/16/25 * The Tethered-Sat 2A team held its first project meeting to discuss deployment mechanisms for the satellite. The group initially considered using a drone system, either mounted on the side or bottom of the satellite and released through a servo-activated trapdoor, with a potential housing size of 2U to accommodate the design. After discussion, the team decided to move forward with a guided parafoil deployment system. Unlike a passive parachute, this system will incorporate mechanisms to create controlled swaying, enabling remote steering during descent. * Cameras and altitude sensors will be included, along with a spring-loaded parafoil release system, though the exact deployment method is still under consideration. * To organize the project, four subsystem teams were established: Communications, focusing on aviation and camera integration; Mechanical, covering motors, servos, and CAD design; Guided Parafoil, responsible for motorized control of the parafoil; and a separation system team, tasked with developing a scissor-like snipping mechanism mounted separately from the 2U satellite but attached to the balloon, ensuring the satellite functions independently once released. Date: 9/18/25 * Through this Tethered-Sat 2A team meeting there was progress in the discussions on what would be the final product as was mentioned in the previous meeting on a goal that wanted to be achieved. With the design continue being a 2U satellite. * With the bottom 1U part being where two cameras will be mounted, with one of the cameras being directly on the bottom panel facing and the second one being mounted on the one of the side panels. With the opposing panel having a customized structured side panel wall that will have trusses formation to hold the PCB stack that will be used. Allowing for quick and easy insertion of the PCB stack there will be slidable rail attachment to the structured walls. * Focusing on the PCB stack itself, the first layer will contain all the modules that will be used from; ESP32, SD module, camera module, power distributor, and ready-to-launch switch. With the second layer being more focused on the power distribution and the direct to PCB terminal connectors. Such as connectors for the battery packs, servomotors, and cameras. Finally, with the final and third layer to this stack not actually being a PCB itself but inside a 3D-printed panel that will have aligned holes to stay connected to the stack. Which will be used as the mounting point for all the battery packs that will be used., allowing all the electronic components to stay as close as possible. * Leaving 1U of the space of the satellite to be used for the control system of the parafoil. Which will be working by a horizontal like reel system powered by a servo which will be connected to a couple of the strings on the parafoil to allow sway to happen for a controlled guidance. With the other strings being attached to the top of the satellite through the top panel and its mounting points that will be used for stabilization. * While the reeling system will only take-up to 0.5U of the free space, all other space will be equipped by the spring-loaded system that will allow the parafoil to pop out deploy. The scissor-like snipping mechanism stayed the same as the past meeting. Without any change to the design.
# Mission Goal and Overview The objective of this program is to help students gain experience in creating and implementing systems into the CubeSat format. Further objectives of this project are to design and prototype systems that can be further implemented into later KSC projects (i.e. KAOS) and to provide an environment to onboard new members. T-Sat stands for "Tethered Satellite." While 'satellite' usually is understood as something in space, this satellite will still be attached to the ground and won't actually reach anything past the troposphere. The goal of the satellite is to perform a moored launch with a weather balloon reaching a maximum height of \~500ft while receiving all video and data from the satellite in real time. Although the satellite could go to higher altitudes beyond just 500ft, we are limited by FAA regulations that require all non-FAA-certified devices using radio waves to stay under an altitude of 500ft, thus constituting our goal. # Satellite Body Still need to show the detailed schematics. Also mention that we used M2 screws for the body and M3 screws for the PCB, Raspberry Pi, and camera. In the smallsat industry, there is a measurement standard known as the U. The U is a scalar value that describes the overall volume of your satellite. Each U represents a 10cm x 10cm x 10cm volume. The notation when describing the size using the U system is to add a scalar multiple before the U. For example, in our project, we aimed to make a 1.5U satellite. This means a satellite with a base that measures 10cm x 10cm and a height of 15cm. For the simplification, we designed the satellite using CAD programs like SolidWorks and 3D printed the final designs using PLA filament. We used 25% infill on all of our designs to try to find a balance between the amount of time it takes to print each piece and how strong each piece is. Below are detailed schematics of all parts that were used for the final satellite body and an explosion GIF to show how the body was assembled. The Following are schematics for each part of the satellite body note that you will need SolidWorks to be able to properly view them. {% file src="/files/PwUWurPwFfekEfWbRJyx" %} {% file src="/files/SOlOIv92xyPZB2ekJdVc" %} {% file src="/files/7wOox8d70lxirYYNgGcO" %} {% file src="/files/IlzQgYEImsnuJ2hbdLlb" %} {% file src="/files/oM4EG82IPthIjKxSYlMJ" %} The following two pictures showcase the final design of the satellite.
# Electronics and PCB Despite being in such a compact area, the live video and telemetry systems have largely separate electronics and are completely independent of each other. For our live telemetry system, we had to design a PCB that would house all of the electronic components for that system. The following is a list of electronics used on the PCB. 1. ESP 32 * 2. JST Connector * 3. 3.3V Buck Converter * 4. BMP388 (Temperature and Pressure Sensor) * 5. MMA 8451 (Accelerometer) * 6. RFM69HCW 915 MHz Transceiver * 7. Bump Switch 8. SD Card Breakout Board The following file has the PCB design. Please note that you will need KiCad to be able to properly view it. {% file src="/files/zebXiO6cZEinI6F2jJdd" %} We did not design a PCB for the live video system. Instead, this system had everything wired through the Raspberry Pi. The electronics for the live video system are listed below. 1. Raspberry Pi 0 2 W * Bought on DigiKey 2. ASUS USB-AC56 WiFi Adapter (2 were used) * 3. TPS61023 5V Boost Converter * 4. JST-PH 2-Pin Breakout * The live video and live telemetry systems are independent, so they run their own software too. Live telemetry works using code created by Fred R, Adam S, and Tolu E. This code can be found in the "Live Telemetry Code" section of this project. Live video was run on a third-party software known as "OpenHD". Further details about OpenHD can be found in the "OpenHD" section of this project. # OpenHD To preface, I'll first explain how regular wifi works and then explain how OpenHD works. When you use Wi-Fi on a device, your device is constantly receiving packages of data from the Wi-Fi modem. These packages hold the data needed to refresh pages, work applications, etc... This process has 4 steps: 1. The modem sends the packages to your device 2. Your device receives/does not receive the package 3. Your device sends a signal back to the modem verifying that the package was received. 4. If the package was not received, the modem sends the package again and continues with other packages. This process works well for devices like phones and laptops, where you need everything to be loaded properly. It is a connection-focused system that ensures you receive all of the packages that you need to run your application. For example, when running a website, package loss could mean that the website won't load properly or, in extreme cases, won't load at all. In a system like live video, where it is more important to get the current frame rather than the frame that we should have gotten 2 seconds ago, it's more important to prioritize receiving current data rather than receiving all data. This is where OpenHD comes in. OpenHD puts Wi-Fi into a state where the modem sends data regardless of verification. This significantly reduces latency in data transfer but also makes the stream of data you receive less reliable, where if you lose connection, all packages will be lost, and you will not be able to get any data. In the end, OpenHD was selected because it allows reliable video transfer over long distances and is an easy software to use. ### The Ground Unit: Setting up the ground unit for this system was the easiest part, but it still had its learning curve. We decided to use a laptop with SecureBoot turned off to run the OpenHD Desktop software without needing a separate Pi and screen for it. After booting OpenHD on the laptop, we are greeted with a Desktop with all of the options that OpenHD provides, two of which are the ones we used: "OpenHDGroundUnit" and "OpenHD." To get everything set up, we first had to boot up the Ground Unit and then open the main OpenHD UI. In the main UI, we are greeted with a black screen until the Air Unit automatically connects to it, which then shows the video that the camera is capturing. To get the best results out of the system, before every field test and the final flight, we scanned the networks where the Ground unit and the Air unit are connected. We do this so we can use the channels that are least polluted in the area. So, it is advised to do this process right after the Ground and Air connect. The main UI also gives many other options in terms of customization. For TSat-2B, most customizations were cosmetic changes, which included hiding some of the pre-set widgets and changing the colors of the UI theme. The other option we changed to better fit our system was the Ground Unit power intake, which helped lessen the overall package loss of the video. This option was the main contributor to how long the system would last on a single battery and how reliable the system was. On lower settings, we would consume less power but wouldn’t be able to move as far away from the ground unit. For our system, we found that having the power of the Ground unit set on “Max 2” and the power of the Air unit set on “Medium” gave it a good balance between flight time and package loss (These settings will change depending on your system). ### The Air Unit: Since it was our first time using OpenHD, we decided to use regular cables to connect everything at first, just to see how the system functioned and if the Raspberry Pi turned on. We had the battery connected to a buck converter, which would supply power to the Pi and all of its constituents. On the Pi, we connected the WIFI adapter using a USB to Micro-USC adapter, and the camera. During the first boot-up, OpenHD usually takes a bit longer to boot and connect to the ground unit. Our first boot-up went well. Everything was connected, and we were getting live video from the Air unit perfectly. However, a few tests later, our live video stopped working for some reason. At first, we thought it was because the system wasn't soldered together, but later on, we found out that it was because the copper connections in our camera wire were damaged from the mechanical stress of too much plugging and unplugging of the camera and the Pi. For future iterations, we advise that if it is not necessary to disconnect fragile cables, such as a camera cable, leave those connections connected. That way, the wires don’t end up damaged over the course of the project. The image below showa the Air unit during one of the early tests: ![](/files/L3CK0xFUG5P1xyrYEdsA) After troubleshooting the camera, we started soldering everything together. While OpenHD recommends soldering every component together. However, we decided that since this was our first time using software, and we did not want to ruin our components, we would solder the USB-to-Micro-USB adapter to the Pi and connect the WIFI adapter through the USB port. We cut the wire of the USB-to-Micro-USB adapter close to the Micro-USB head so that we had as much cushioning as possible in case we needed to cut some more wire. The picture below was taken from the OpenHD website and is the diagram we used to wire the Air unit. ![](/files/zTf4tcJQygYNvDqUm0sK) Below is a picture of the diagram of the back connections of the Pi.
When we stripped the wires of the USB-to-Micro-USB adapter, we followed the Pi diagram to solder the Data+ wire to Data+ connector, Data- wire to Data- connector, Ground to Ground, and 5V to the 5V. The reason this is advised is that the Pi itself can’t provide enough power to the WIFI adapter through the Micro-USB port, so soldering it to the 5V connector at the back of the Pi is the best way to bypass this issue. It is also recommended to have a separate battery for the WIFI adapter to properly power it, but for the purposes of T-Sat2B, we decided to have a large battery power both components, but this choice gave us a flight limit of around 32 minutes. For more information about the wiring, check out the “Wiring” section on the OpenHD website. More information about OpenHD can be found here: # Live Telemetry Code Give an overview of how the code works and show the code (should have detailed comments in it already). All code mentioned below can be found here: ## Telemetry > Note: The code for these systems are documented quite well, so be sure to take a look at any comments in the code for additional information. TSAT-2B has many on-board sensors, including pressure, temperature, and acceleration. From these, we can use pressure to derive altitude, and altitude + time to derive ascent velocity. Telemetry data is stored in all SI units. Three systems work together to provide live telemetry on launch day: * **Air**: This is the main board on TSAT-2B. It handles all communication with the satellite and collects all telemetry data. * **Ground Pipe**: This is a receiver on the ground that allows a laptop to communicate with the Air controller. * **Ground**: This is a Python program running on a laptop that displays and graphs received telemetry data. All three systems are required for live telemetry, however if only on-board telemetry (and therefore post-landing data) is desired, then only `Air` is needed. ### Air This is the main system that runs on TSAT-2B. While theoretically it can serve more purposes, its only purpose for this project is to collect sensor data and send it to the ground. Sensor data is collected and saved to the on-board SD card, and sent to the ground via the RFM69. While there is logic that allows `Air` to receive packets, for the purpose of this launch, it only sends `Telemetry` packets. Once turned on, the system should initialize, showing a solid blue LED (via the built-in LED on the ESP32 dev board). If there is an error while initializing, the LED will begin blinking instead. See below for errors. Every 500ms, a datapoint is collected through sensor data. This datapoint is saved to the SD card (appended to the CSV file), then converted into a telemetry packet. The telemetry packet is simply a C struct that is read as raw bytes and sent over the network. This is the easiest since it requires no (de)serialization for `Air` compared to other formats like JSON. This makes it very easy to compute and space efficient, but may be slightly riskier since it requires ensuring the structs have the correct alignment, and anything that communicates with it must use the same endianness. In the future, it may be useful to utilize more advanced protocols like CAN Bus if multiple systems are in use. ### Ground Pipe This is a program that runs on an ESP32 on the ground. The ESP32 is hooked up to an RFM69 on the same frequency as `Air` (this can just be done on a breadboard). Any packets that are received on the ground are read as bytes and output to the UART bus as space-separated decimals. While this may seem weird, this offers an easy interface to transmit binary data without the pitfalls of non-packetized UART (such as having to create a protocol to delimit packets). Example output: ``` 0 0 0 1 209 200 189 109 139 172 215 86 145 19 61 103 86 127 37 248 79 172 192 30 195 108 7 43 115 141 176 217 ``` `Ground` then reads this serial output, converts it to bytes, and decodes it using the Python `struct` module. ### Ground This is the main ground program. This program has 2 main run modes. * **Live**: This creates a serial connection to `Ground Pipe` from a device (`/dev/ttyUSBX` on Linux, `COMX` on Windows usually, replace X with a number). It will take any lines outputted by `Ground Pipe` and attempt to decode them using the Python struct module. Then, any telemetry packets are graphed live. * **From File**: This opens a CSV file, specifically the CSV file recorded by on-board telemetry onto the SD card. The data is then graphed and displayed. > Linux Note: If you get some type of 'Invalid Permission' error when trying to access the port, you might need to give yourself permissions. Ex: `sudo chmod a+rw /dev/ttyUSBX` > Windows Note: You may need to download [Serial Drivers](https://meshtastic.org/docs/getting-started/serial-drivers/esp32/) in order for windows to correctly recognize the serial device. We use plotly to graph data, mainly because matplotlib began to be very slow for this use case. In the plotly interface, there are 2 options at the top-left of the screen: * **Autoscale 60s**: Displays the last 60s of data, scrolling when new data comes in. * **Show Packet Loss**: Replaces the KSC logo with a packet loss graph, showing the percentage of packets lost within a timeframe. This will be 0 when loading from a file. ### Errors If the `Air` system errors, it will begin to blink the blue LED. How many blinks occur depends on the type of error, as seen below: * **1 Blink**: Radio is unable to initialize. * **2 Blinks**: SD card is unable to initialize. Check that the SD card is formatted (Fat32) and inserted correctly. If this continues to happen, try reformatting the card anyways, since it may look correct but secretly not be (this is a real issue that happened). * **3 Blinks**: Same as above, unsure if this can happen. If the USB cable on the laptop disconnects the `Ground Pipe` system, the `Ground` system program will disconnect the socket. Unfortunately, there is no way to recover from this besides restarting the `Ground` software, losing all live telemetry data. All information here is courtesy of Fred Reynolds (lead software engineer for T-Sat-2B). # Results T-Sat-2B took flight from the UCF arboretum on March 28th, 2026. From start to finish, the flight lasted about 30 minutes, and the maximum altitude reached was around 450ft. With both live video and live telemetry systems lasting the entire flight duration. The mass of the payload was 512.6 grams, far below the limit of what the balloon could lift. The following is the full on-board video from T-Sat-2B. This is the video that was captured locally onto an SD card on the satellite itself. This is the live video without any lagging or cuts due to packet loss. {% embed url="" %} The following is the data received from the satellite during its flight. The satellite had three sensors. A temperature sensor, an accelerometer, and a barometer. Together, these sensors took four measurements: temperature, acceleration, pressure, and altitude. The barometer was used to measure both pressure and altitude.
All measurements are in SI units (i.e., the metric system). ### Points of Interest: * The flight officially started \~260 seconds (8.7 minutes) after the system was activated. * The satellite reached peaked altitude at \~550 seconds (9.1 minutes) after the system was activated * The temperature of the satellite generally decreased as its altitude increased and increased again as the altitude decreased. * The acceleration and velocity seem to be extremely erratic. This could be due to how high the wind speed was that day. # Knights Air Observation Satellite Overview of the Knight Air Observation Satellite program. The Knights Air Observation Satellite (KAOS) program is the Knights Satellite Club’s high-altitude balloon (HAB) launched, suborbital CubeSat demonstrator initiative. KAOS serves as a stepping stone between ground and tether based projects, such as Tethered-Sat, and the long term goal of a fully functional orbital CubeSat. KAOS missions are flown aboard high altitude weather balloons, allowing the team to test CubeSat class hardware, avionics, power systems, communications, and payloads in a near space environment while avoiding the cost, regulatory burden, and risk of orbital launch. KAOS provides hands-on experience with real flight dynamics, thermal extremes, and operational constraints, making it a critical training and validation platform for future orbital missions.
Cover image
KAOS-0Mission IArchived/files/egll6VHdrcIbyHzPlBzM/pages/JE70VkagV9EOV2qtBkvr
KAOS-1Mission IIArchived/files/8wKmv90I9730QccgrnFG/pages/Rj9Yyv2LgDYptEbPYnKF
KAOS-2Mission IIIOngoing/files/d0HGuvhFLEaFhNRDRDmd
# KAOS-0 Overview of KAOS-0 Results After Launch of Payload. Initially utilizing a 3D printed housing KAOS-0 was launched August 13, 2022. Unfortunately a catastrophic failure occurred with another RSO's rocket that KAOS-0 was within.

CAD Model of Housing

As seen below the results were also catastrophic for our CubeSat without any of the data being recoverable. However this version was still valuable to our team and a lot of expertise was gained throughout every stage of version 0.

KAOS-0 after a catastrophic failure occurred during the launch of the payload

# Post Flight Results # KAOS-1 ## Project Overview KAOS-1 Is an high-altitude balloon mission designed to validate core subsystems and operational workflows that directly support future orbital CubeSat missions.

KAOS-1 flight hardware conducting a communications test

The primary objective of KAOS-1 is to collect atmospheric telemetry (temperature, pressure, GPS, orientation, CO2, humidity, etc.) at stratospheric altitudes and demonstrate end to end communication, power management, and recovery processes. Pushing systems into the near space environment, we reduce risks for subsequent orbital platforms developed by the Knights Satellite Club.

KAOS-1 flatsat configuration

\ This project also serves as hands on training for club members, providing experience in systems integration, flight hardware assembly, telemetry analysis, and regulatory compliance. It's intentionally architected to reflect future satellite constraints to ensure maximum reuse of hardware and software when needed for future missions.

Electrical member soldering flight hardware

# Hardware Details about the mechanical components of KAOS-1. ## Overview \ Following the foot steps of our previous projects our mechanical team utilized [Onshape's](https://www.onshape.com/en/education/plans) educational license as our CAD platform. From a hardware perspective we had two main focuses on KAOS-1; [Electronic Integration](#electronic-integration) and [Payload Temperature Testing](#payload-temperature-testing). Both were the central focuses when it came to establishing our design and iterating to our eventual flight hardware. All of our CAD for KAOS-1 can be viewed and exported [on Onshape](https://cad.onshape.com/documents/d8ec8b69a1bae0e7a9f94029/w/ac2041561a361db9fbc85842/e/0252f4e742c3d5c2741b99e8?renderMode=0\&uiState=69545cd807123b77856fa423). The first observable difference between KAOS-1 and the majority of CubeSats or HAB payloads would be the wood housing we are using. This design decision took some inspiration from the [WISA Woodsat](https://www.wisaplywood.com/wisawoodsat/) and [Lignosat from JAXA](https://www.nasa.gov/image-article/jaxas-first-wooden-satellite-deploys-from-space-station/) when we first started developing the project in Fall 22'. This design decision brought many advantages and many unexplored challenges. Wood gave the team a high level of flexibility when it came to integrating or iterating our design. Being able to drill and bolt in new hardware to a prototype payload bus to test a variety of components such as a new GPS patch antenna. Making on the spot changes was incredibly helpful and made things a lot easier for our mechanical team. All while spending about $3 per payload bus and 30 minutes of assembly. More can be read on the payload bus and the wood we used under the section [Payload Bus](#payload-bus). The challenges came from concern on woods ability to withstand drastic temperature and humidity changes during the span of the flight without cracking. Without access to standard testing equipment such as a thermal vacuum chamber we were left to create a budget thermal test that can be seen [here](#sub-zero-temperature-conditions). ## Electronic Integration A key requirement for any mechanical team working on a CubeSat project is integrating electrical systems. For our team that included incorporating four [PCB's](/projects/knights-air-observation-satellite/kaos-1/electronics), two ArduCam Mega cameras, sensors, and a remove before flight pin switch.

KAOS-1 in flatsat configuration

The flatsat configuration was important for our mechanical team to pull dimensions and be able begin the design process for integrating electronics. Our main requirements were accessibility to the main components like our batteries, cameras, and the micro-usb header on the ESP32 microcontroller for software changes. Keeping this as the focus of our design means that testing and launch day operations can run much smoother and quicker. ### PCB Sled The four custom PCB's our electrical team designed needed a way to house the stack inside the payload bus. For this, we designed two main components that would allow us to have a rigid mounting solution while being able to easily remove the stack and let the electrical or software teams work with the boards. The PCB sled seen below has a rail component that mounts to one of the side walls of the bus and another component that slides onto the rail and can be locked in place via a single pin at the top of the rail.

Assembly of our PCB Sled

The stack bolted straight onto the sled and allowed us to still have access to the batteries through the top cutout and the ESP32 header through one of the open sides. These features were useful on launch day when it came time to do final checks, as seen below.

PCB sled being lowered into payload bus

Software checks while the PCB's are stacked in sled on launch day

### Cameras Two Arducam Mega variants were used on KAOS-1. Both of the cameras being 5MP with one having a [M12 lens](https://www.arducam.com/mega-5mp-color-rolling-shutter-camera-module-with-m12-lens-for-any-microcontroller.html) and the other [without a lens](https://www.arducam.com/presale-mega-5mp-color-rolling-shutter-camera-module-with-autofocus-lens-for-any-microcontroller.html). With the lofted front of the M12 lens variant we had two versions of the camera mounts. The lens variant required a few millimeters to be added to accommodate the extra thickness of the camera.

KAOS-1 assembly where both camera mounts can be seen. One pointing downward and the other to the side

For simplicity and ease of access the camera mounts were two 3D printed components. They were secured with 30mm M3 bolts that went through the mount and to the outside of the bus where a nut was attached to each bolt.

Front view of one of the camera mounts

### Payload Bus The payload bus was made from [low cost 1/4" plywood](https://www.homedepot.com/pep/ProWood-1-4-in-x-2-ft-x-2-ft-Sanded-Plywood-Project-Panel-109114/202093828?source=shoppingads\&locale=en-US\&fp=ggl\&pla=\&mtc=SHOPPING-BF-CDP-GGL-D21-021_001_PLYWOOD-NA-NA-NA-PLALIA-NA-NA-NA-NA-NBR-NA-NA-NEW-_PLATEST\&cm_mmc=SHOPPING-BF-CDP-GGL-D21-021_001_PLYWOOD-NA-NA-NA-PLALIA-NA-NA-NA-NA-NBR-NA-NA-NEW-_PLATEST-22114087436-173523647899-299067764094\&gclsrc=aw.ds\&gad_source=1\&gad_campaignid=22114087436\&gbraid=0AAAAADq61UdHIveq5AaMwaO9c9T-e8Y2p\&gclid=CjwKCAiA09jKBhB9EiwAgB8l-A4FfXVglP7iFutXKTjvUEvz7ryOFop-Jm72HLghL8hV5Nxa29wLBBoCP0MQAvD_BwE#overlay) and laser cut for free in UCF's engineering center. We tried a few methods for assembling the bus but the best method we found was [M2 wood screws](https://www.amazon.com/dp/B0C5JVC6Z3?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_3). Alternatively we tried to pre drill the holes and use M3 bolts, however, this was time consuming and with the thinness of the wood, very easy to crack or pierce the side of the bus.

Payload bus assembly

Every aspect of the bus in the assembly was able to be laser cut including M3 through holes and engraving our sponsors on the top panel. Overall, wood was a phenomenal material to use for a HAB launch. Each prototype was inexpensive, easily manufactured in as little as 30 minutes, and survived the atmospheric conditions without any signs of defects. It allowed us to make changes quicker than 3D printing our payload buses, as we usually do. ## Payload Temperature Testing A key focus for us using a wood housing for a HAB launch was to ensure that our bus could survive extreme changes in temperature and humidity without major cracks forming. As seen in the altitude vs. temperature graph below we knew that we could expect temps from 80 degrees Fahrenheit on the ground and -70 degrees Fahrenheit for a majority of the flight. We were worried about this cold and dry air causing the wood to contract and crack as it was restricted by the wood screws. As a result we conducted the best [testing](#sub-zero-temperature-conditions) we could with the resources we had access to.

Approximate altitude vs. temperature relation

### Sub Zero Temperature Conditions The best form of testing we could conduct involved a large styrofoam cooler and a few pounds of dry ice. We placed two [thermometer probes](https://www.amazon.com/dp/B0C4YL76WY?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_1\&th=1) in the cooler, one inside of the payload and another on top to record the temperature of the air inside the cooler. In this test we were able to record air temperatures as low as -55 degrees Fahrenheit and tested our electronics and batteries down to -22 degrees Fahrenheit. Although we weren't quite able to reach the exact temperatures we expected to see during flight, we were still able to test under extremely cold conditions for two hours and all systems performed flawlessly.

Dry ice testing setup

Outside of the wood withstanding the temperatures we were also concerned about our electronics getting too cold. To combat this we insulated the bus and added hand warmers to help with internal temperatures. In the graph below it's visible that these efforts certainly helped us maintain safe operating temperatures for our electronics. Although the hand warmers weren't very impactful in this test due to the CO2 omitted by the dry ice. We still proceeded with them for launch in order to keep our internal temperature a bit higher than what was reached an hour into testing. As well as above zero in flight conditions. The use of hand warmers being untested ended up being a problem for us on flight day which can be read more in [post flight results](/projects/knights-air-observation-satellite/kaos-1/post-flight-results#lessons-learned).

Temperature vs. Time for inside payload bus and the exterior testing environment

# Electronics Documentation for the electrical subsystem of KAOS-1. ## Overview

Assembled KAOS-1 electronics stack.

KAOS-1 uses a stack of 4 simple PCBs. Each PCB has 2-layers and is designed for breakout boards to be soldered on. This results in poor utilization of PCB real estate necessitating the 4-board design, but makes the individual boards much easier to develop and test. All boards except for Communications have a ground pour on both layers. The boards from top to bottom are Power, Sensor, Primary, and Communications. Each board is 8cm x 8cm with a 4mm filet on the corners. Each corner has a plated M3 hole centered 4mm from either edge. The boards connect to one another through JST-XH connectors placed on the edge of each board. The connectors are designed to line up vertically when stacked for simple cable management. The boards are stacked using M3 standoffs and loaded into a sled that slides into the 4U enclosure. The boards were designed in Autodesk EAGLE which worked well and was relatively easy to learn. All design files are available [on GitHub](https://github.com/UCF-Knights-Satellite-Club/KAOS-1/tree/main/flight/electronics). Future projects will likely use KiCAD because of the larger feature set, active development, and open ecosystem. ## Power Board

Render of Power Board top layer.

Render of Power Board bottom layer.

Schematic for Power Board.

The Power Board holds 2 18650 lithium batteries, a 3.3V linear regulator, and connectors for other boards and the Remove Before Flight (RBF) switch. The RBF switch is a normally-closed limit switch that disconnects the batteries from the rest of the system when a pin is inserted. ### Battery Chemistries We have tested 18650 cells with Li-ion and LiFePO4 chemistries. LiFePO4 have lower voltage and power density but are reported to handle the low temperatures of high altitude balloon flights better. LiFePO4 batteries also pose a lower fire hazard which is ideal since we may not recover the payload. KAOS-1 is planned to fly with LiFePO4 batteries but more testing needs to be done. ### Errata It was incorrectly assumed that the heat sink of the linear regulator should be connected to ground. It is actually connected to the 3.3V output so insulating tape must applied to prevent the heat sink from contacting the exposed pad under the regulator. ## Sensor Board

Render of Sensor Board top layer.

Render of Sensor Board bottom layer.

Schematic for Sensor Board.

The sensor board holds a BMP388 barometric altimeter, an SCD-30 CO2 and humidity sensor, a GY-521 MPU6050 6-axis IMU, and a connector for a 10k thermistor. There is also a 10kΩ resistor which is needed to read the thermistor. This board is responsible for taking atmospheric measurements during the flight. The most useful readings to meteorologists are pressure, temperature, and humidity. Agencies such as NOAA regularly fly [radiosondes](https://www.noaa.gov/jetstream/upperair/radiosondes) which measure this information. ### Errata The 3-pin power connector has ground and 3.3V switched. The workaround for this is to switch these conductors on the cable assembly. The SCD-30 pinout is backwards. For the sensor to work, the original headers needed to be removed and installed coming from the front of the sensor. The sensor is then installed face down on the Sensor Board. ## Primary Board

Render of Primary Board top layer.

Render of Primary Board bottom layer.

Schematic for Primary Board.

The Primary Board holds the ESP32 microcontroller, a MicroSD reader, a PCF8523 real time clock, connectors for two ArduCam Mega cameras, and a connector for a piezoelectric buzzer. Both ArduCams share the VSPI bus, and the MicroSD card uses the HSPI bus. Both busses are implemented in hardware on the ESP32. All other peripherals communicate over I2C. Several GPIO pins go to the sensor board for interrupts and analog readings. There is also a resistor divider to measure the unregulated battery voltage. ### ESP32 Pin Numbers
PinDescription
4ArduCam A chip select
5ArduCam B chip select
12HSPI MISO
13HSPI MOSI
14HSPI CLK
15SD card chip select
18VSPI CLK
19VSPI MISO
21I2C SDA
22I2C SCL
23VSPI MOSI
25Piezoelectric buzzer
27SCD-30 RDY
32BMP388 INT
33External thermistor measurement
34Battery voltage measurement
VSPI and HSPI pins are the same as the default configuration for both busses. ### Errata The HSPI bus is used by the ESP32 during boot. If the SD card has been initialized and there is a reset, the ESP32 may crash with invalid header messages. More research and testing is needed on this. ## Communications Board

Render of Communications Board top layer.

Render of Communications Board bottom layer.

Schematic for Communications Board.

The Communications Board holds a [LightAPRS](https://qrp-labs.com/lightaprs.html) radio and exposed pads for the tape measurer antenna. There is no ground plane on this board due to uncertainties about how a ground plane would interact with the antenna. The LightAPRS only receives power from the Communications Board and contains an integrated controller, sensors, and GPS receiver. When powered up, the LightAPRS automatically transmits telemetry information to the [APRS network](https://www.aprs.org/). The radio signal from the LightAPRS is carried to the board over a coax cable that connects to a surface mount U.FL connector. ### Errata The power regulator on our LightAPRS board stopped working. In order to power it, we have to connect its 3.3V output pin to our 3.3V regulator. This limits our transmit power from 1W to 0.5W but for balloon flights this is not a problem. Replacing or fixing the LightAPRS should fix this issue without any changes on the PCB design. # Software Documentation for the software used on KAOS-1. # Launch Day ## Before Launch Day In the week leading up to the scheduled launch day, Nathan, the KAOS-1 Project Lead, ran the flight prediction software every day to find a good launch site. Habhub takes the Latitude/Longitude of launch sites, the Launch Altitude (in meters), Launch Time (UTC), Launch Date, Ascent Rate (m/s), Balloon Burst Height (meters), and Descent Rate (m/s) as inputs and outputs a predicted flight path. The Knights Satellite Club was looking at a few possible launch locations two days before launch: Econ River Wilderness Area, Sunrise Community Park, Sanlando Park, and the Oviedo Sports Complex.

Figure 1: Launch Trajectory From Econ River Wilderness Area (28.6134, -81.1742)

Figure 2: Launch Trajectory From Sunrise Community Park (28.6523, -81.2585)

Figure 3: Launch Trajectory From Sanlando Park (28.6759, -81.3964)

Figure 4: Launch Trajectory From Oveido Sports Complex (28.6692, -81.1872)

On August 29th, 2025, the Econ River Wilderness Area was chosen as the best-suited launch site as the payload was predicted to land in Wedgefield, Florida, approximately 2 hours after launch. The FAA was also notified of this launch. {% columns %} {% column %}
{% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} *** ## Launch Day The morning on August 30th, 2025, the Knights Satellite Club drove out to the Econ River Wilderness Area at 8 am and began setting up. To learn more about inflating and rigging a balloon for flight, please visit the [High Altitude Free Balloons](/ballooning/high-altitude-free-balloons) page. ### Payload Preparation More in depth technical regulations and HAB launching information can be found [here](/ballooning/high-altitude-free-balloons). The final additions made to the payload leading up to or on launch day were minor and made intentionally to not interfere with any systems onboard the payload. This included attaching dense foam to the bottom and some of the edges of the payload bus to help with ground impact. Taping a sheet of paper to the top of the bus stating that what the box was and our contact info to aid with recovery if a pedestrian found the project before we got to it. The final preparations included rigging the payload with masonry line and 3D printed PETG O-rings and carabiners before connecting it to our inflated balloon.

Final payload preparations being made before attaching to HAB

### Balloon Launch! After preparing the payload, the balloon train was constructed. A 5-foot line of string connected the top of the parachute and the Balloon together, then a 360-degree swivel eyebolt was attached to the bottom of the parachute to prevent the balloon train from winding up and popping the balloon. Below the parachute was another 10 feet of string before attaching to the payload. At approximately 10:07 am EDT, the balloon was released, and KAOS-1 took flight. # Post Flight Results Results collected from the 8/30/25 test flight of KAOS-1. ## Overview After three years of development KAOS-1 was released with a balloon just after 10:00 am on August 30, 2025. The flight was just under two hours in length and had to be recovered from the Hal Scott Regional Preserve about 10 miles away from our launch site. The data is currently unclear but we believe that our payload likely reached an altitude of 120,000 feet. ## KAOS-1 Flight Video {% embed url="" fullWidth="true" %} A collection of pictures and videos captured by our team along with those captured by KAOS with its two onboard cameras {% endembed %} ## Lessons Learned The primary issue encountered during the KAOS-1 flight was overheating of the onboard electronics, a risk that had been underestimated during design and testing. One of our major requirements when we begun development was withstanding extremely harsh frigid temperatures along the majority of our flight. In order to withstand the flight environment we insulated the box, sealed all gaps with Kapton tape, and added two hand warmers inside the bus (more details on this can be found [here](/projects/knights-air-observation-satellite/kaos-1/hardware#sub-zero-temperature-conditions)). This was the solution we went with on flight day, however, there was a major component overlooked with this approach.\ \ We put too much consideration on withstanding the cold and didn't consider the potential for overheating with the heat generated from the hand warmers and electronics. This likely wouldn't have been an issue in a perfect world where launch operations run as planned, but that was not our experience. Having idled about an hour with a sealed payload bus before being released a lot of heat was generated by the hand warmers. This is what we believed caused a couple of power cycles not long into the launch, as KAOS wasn't quite high enough into the atmosphere to be cooled by the frigid environment. Looking forward to KAOS-2 we have begun to brainstorm solutions to thermal regulation with our payload as that project will likely be an advanced iteration of version one. The most prominent solution being put forward would be a 3D printed sliding door that could be installed into one of the panels and controlled by a linear servo. We would need create a software control loop that constantly collects data from a thermistor in the interior of the bus and determines if the door should be opened or closed to adjust the internal temperature. # KAOS-2 {% hint style="info" %} This is a future project. More information will be available soon. {% endhint %} # Ground Stations
Engineering Ground StationOngoing/pages/drps5Pg1kvV81tce24im
Physics Ground StationOngoing/pages/qITdqAJlGODoFGpzxyv5
# Weekly Project Updates # Engineering Ground Station Documentation for the satellite tracking ground station on the roof of the UCF Engineering I (ENG1) building. Collaborative project with ARC\@UCF. ## Overview The [ground station](http://newton.i2lab.ucf.edu/wiki/Amateur_Satellite_tracking) ARC\@UCF currently operates uses a Yaesu G-5500 rotator controller. This controller has a computer interface port which allows their GS-232B computer interface unit to automatically point the rotator at a target as instructed by a computer. The GS-232B is very expensive so many have implemented their own such as the [K3NG Controller](https://github.com/k3ng/k3ng_rotator_controller). KSC is currently developing a custom computer interface unit to restore satellite tracking functionality to ARC's ground station. This open source interface is build around a Raspberry Pi Pico and will ultimately include firmware, a PCB, and enclosure. This custom option was chosen to build experience with the Pico, train members on PCB design, and to have a simpler code base... most of the K3NG code resides in a single 22,000 line .ino file!

Ground station on ENG1.

## Custom Computer Interface The G-5500 instruction manual briefly describes the external control interface. The DIN cable colors are specific to our cable breakout, I am not sure if they are standard.

G-5500 external control interface diagram from instruction manual.

PinDIN ColorFunction from Manual
1BrownProvides 2 to 4.5 VDC corresponding to 0° to 180° (elevation)
2GreenConnect to Pin 8 to rotate right (clockwise)
3WhiteConnect to Pin 8 to rotate up
4BlueConnect to Pin 8 to rotate left (counterclockwise)
5YellowConnect to Pin 8 to rotate down
6BlackProvides 2 to 4.5 VDC corresponding to 0° to 450° (azimuth)
7RedProvides DC 13 V to 8 V at up to 100 mA
8GrayCommon ground
### ADC Voltage Ranges From our testing, we have found the azimuth voltage to vary from 0.22V (0°) to 4.23V (450°) and the elevation voltage to vary from 0.20V (0°) - 2.20V (90°). ### Motor Control Circuitry We had hoped that switching pins on the Pico between low and high or input (low impedance) mode, we could create the active low control signals expected by the G-5500 without external circuitry. Initial testing was unsuccessful so a circuit utilizing an NPN transistor was tested but that also did not work. The only difference between our test circuit and an example K3NG rotator diagram is a capacitor between the control line and ground just before the transistor. I am not sure why this would make a difference but it will be tested.

K3NG rotator circuit from the Radio Artisan Blog

## Useful Links A collection of useful links relevant to this project. * [Radio Artisan K3NG blog post](https://blog.radioartisan.com/arduino_rotator_controller/) * [Ava K3NG hardware design](https://ava.upuaut.net/?p=372) * [K3NG controller source and documentation](https://github.com/k3ng/k3ng_rotator_controller) * [Yaesu G-5500 instruction manual](https://www.yaesu.com/downloadFile.cfm?FileID=8814\&FileCatID=155\&FileName=G-5500_IM_ENG_E12901004.pdf\&FileContentType=application%2Fpdf) # Physics Ground Station Documentation for the satellite tracking ground station on the roof of the UCF Physical Sciences Building (PSB). KSC is working with the UCF Department of Physics to help operate the satellite tracking ground station installed on the roof of the Physical Sciences Building. This section collects the operating procedures, setup notes, calibration steps, and manufacturer reference documents needed to use and maintain the station. ## Quick links * [Hardware](/projects/ground-stations/physics-ground-station/hardware) * [Ground Station PC Setup](/projects/ground-stations/physics-ground-station/pc-setup) * [Radio and Software Notes](/projects/ground-stations/physics-ground-station/radio-software) * [Antenna Rotator Calibration](/projects/ground-stations/physics-ground-station/calibration) * [Ground Station Registration](/projects/ground-stations/physics-ground-station/registration) * [Project Notes](/projects/ground-stations/physics-ground-station/project-notes) * [Reference Documents](/projects/ground-stations/physics-ground-station/reference-documents) ## Current documentation status Some hardware details still need on-site confirmation. # Hardware Hardware overview for the PSB Physics Ground Station. ## Station location The ground station antennas are mounted on the roof of the UCF Physical Sciences Building. The station equipment rack is located in the PSB lab space. Roof work requires at least one person in the lab and one person on the roof, with active communication between both groups. ## Antennas * Yagi antenna for the 70 cm band. * Dish antenna for the 13 cm band. * Future 2 m antenna support remains under consideration. The Yagi antenna and dish antenna should be co-aligned straight outward with the rotator. ## Cabling * The Yagi antenna uses N-type coax. * The rotator has two motor-control wires. * The rotator may also require a separate power wire; this still needs confirmation. * The dish antenna cable type still needs confirmation. * The cable distance from the lab to the ground station is approximately 100 ft. * Coax attenuation may be a concern for the dish antenna frequency because of the long cable run. ## Radio equipment * IC-R8600 software-defined radio. * IC-9700 radio transceiver. ![IC-R8600 rear panel](/files/ysyF8e5Kg8C1LG3ZTelN) ![IC-R8600 front panel](/files/RzyKiGvD9RCtqF0Tdx5J) ## Power equipment The rack includes Astron power distribution units. There are two units, Use the Astron 1 and Astron 2 labels when identifying radio power paths. ![Astron rack power units](/files/1fU6ngv2aVRMF6fTZomq) ## Rack layout The rack layout image is shown below for quick reference. (will update this image with labels soon) ![Rack layout](/files/EjGq5AfZ7oX8sZCZOofi) ## Open hardware questions These items still need confirmation: * Confirm whether the rotator controller powers the rotator or whether there is a separate power cable. * Confirm the specific rotator installed on the roof, including whether it is the 12 V or 18 V model. * Confirm the dish antenna use case, cable type, and what equipment connects to it. * Confirm cable specifications for the approximately 100 ft run. # Ground Station PC Setup Ground station computer setup procedure for the PSB Physics Ground Station. Use this procedure to bring up the ground station computers from the equipment rack. ## Setup procedure 1. Confirm the computers are receiving power from the PDU. 2. Confirm the PDU power switch is on. The red switch position is the on state. 3. Connect the HDMI cable to a monitor. 4. Connect the keyboard to the other end of the USB extension cable. 5. Plug the mouse into the keyboard USB port. 6. Press the computer power button. 7. Confirm the monitor receives signal from the computer. ![Computer rack front panel](/files/SjDGPBtFHLupVupVHCix) ![Computer rear connections](/files/jhZfvawhBwUnzj8czfnZ) ![Monitor, keyboard, and USB connection](/files/SkRB0HTWKAupzuq9ZN1n) ## Troubleshooting ### Computer is on but the monitor has no signal If the computer has been left on for a long time, it may enter a deep sleep state. Hold the computer power button until the light turns off, then press it again to power the computer back on. If restarting from the front power button does not restore video, power the computer down again and toggle the power supply switch at the rear of the computer off and back on. Also confirm: * The monitor is powered on. * The monitor input source is correct. * HDMI is connected to the monitor. * The USB extension and keyboard are connected. # Radio and Software Notes Radio and software setup notes for the PSB Physics Ground Station. Use these setup notes as the current working procedure until they are verified during an operating session. ## IC-R8600 The IC-R8600 is documented as the station software-defined radio. ### Computer interface setup 1. Power on Astron 2 PDU. 2. Power on the radio. 3. Connect USB A from the computer to USB B on the radio I/Q OUT port. 4. Power on and set up the rotator controller. 5. Launch SDR Console v3.2. 6. Select the IC-R8600 radio. ![SDR Console radio selection](/files/hoC9tmGmf1nFQeEp7x0t) ## IC-9700 The IC-9700 is documented as the station radio transceiver. ### Computer interface setup 1. Power on Astron 1 PDU. 2. Power on the radio. 3. Complete the remaining radio-interface setup after the station team verifies the final IC-9700 connection procedure. ## Satellite tracking software Current station software includes: * SDR Console v3.2 for SDR control. * Orbitron for satellite tracking and rotator control. * SpidAlfa 0.97 driver for Orbitron rotator support. * FLRig for transceiver control. Orbitron should be the main rotator-control program because the rotator documentation supports Orbitron through the SpidAlfa 0.97 driver. SDR Console's satellite interface can also use Orbitron rotor control in the background, which allows radio and rotor control through the SDR Console satellite interface. ## Network notes Current network notes: * DHCP was turned off. * Ethernet ran from the transceiver to the PC. * The PC successfully pinged the radio. * Future work may include connecting radios to the UCF Ethernet network for remote access. # Antenna Rotator Calibration Antenna rotator calibration procedure for the PSB Physics Ground Station. This procedure requires at least one person in the lab with access to the rotator controller and at least one person on the PSB roof. Both groups must maintain active communication throughout the procedure. ## Tools Confirm the required tools to adjust the mounting pole before roof access. ## Calibration procedure 1. Use the rotator controller down arrow to set the rotator altitude/elevation to `0` degrees. 2. Confirm the antennas on the mount bar are parallel with the horizon. 3. If the antennas are not horizontal, loosen and rotate the mounting bar until they are horizontal, then retighten the bar. 4. Use the rotator controller left or right arrows to turn the rotator to true north, which is `0` degrees azimuth. 5. Reset the controller: * Turn the controller unit off. * Hold the `F` button down. * Turn the controller back on while holding `F`. * Confirm the display shows `0.0, 0.0`. 6. At this point, the azimuth is calibrated. 7. Use the controller down arrow to move the rotator to full downward travel, which should be approximately `-21.0`. 8. If the rotator stops and the display does not show approximately `-21.0`, the mechanical stop in the rotator has been triggered. 9. Reset the controller again using the reset process above. 10. Use the controller down arrow to move the rotator to full downward travel again. 11. Repeat the full-downward-travel and reset process until there is no more travel. 12. Use the controller up arrow to move the rotator up to the `10` degree mark. 13. Reset the controller again. 14. Test for a full `180` degrees of travel using the controller up arrow. 15. If the travel is approximately `180` degrees or more, setup is correct. 16. If the travel is not approximately `180` degrees or more, repeat the downward-travel and reset process until the travel is correct. ## Maintenance note Apply WD-40 maintenance spray to the motors while personnel are on the roof, if maintenance is scheduled. # Ground Station Registration Registration notes for the PSB Physics Ground Station. This procedure still needs to be written for ARRL registration. ## Status This procedure still needs to be written after the station team confirms: * Which ARRL registration path applies to the PSB station. * Which club or university contact owns the registration. * What call sign, station location, equipment, and operator information must be submitted. * Whether any UCF department approval is required before registration. # Project Notes Planning notes and unresolved items for the PSB Physics Ground Station. This page tracks planning notes and unresolved items for the PSB Physics Ground Station. ## September 23, 2025 meeting notes ### Antenna notes * Coax attenuation may be a problem because the coax run is long for the dish antenna frequency. ### Radio and software notes * A future 2 m antenna may require an N-female to PL-259 adapter. * Future work may include connecting radios to the UCF Ethernet network for remote connection. * FLRig can interface with and control the transceiver. * Orbitron can be used for rotator control. * SDR Console can be used for SDR control. * DHCP was off during testing. * Ethernet was connected from the transceiver to the PC. * The PC successfully pinged the radio. ## Open tasks * Confirm whether the rotator controller powers the rotator or whether a separate power cable is required. * Gather complete dish antenna information, including use case, cable type, and connected equipment. * Confirm the exact rotator model installed on the roof. * Confirm whether the installed rotator is the 12 V or 18 V model. * Confirm cable specifications for the approximately 100 ft run from the lab to the ground station. * Acquire one USB hub or extension cable. * Acquire one long HDMI cable. # Reference Documents Vendor manuals and reference files for the PSB Physics Ground Station. Use these vendor manuals and reference files when operating or maintaining the PSB Physics Ground Station. ## Antenna references * [M2 Antenna Model 425CP16](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/m2-antenna-model-425cp16.pdf) * [FGMAN425CP16.B](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/fgman425cp16b.pdf) * [12 cm Loop Yagi Kit DSE1276LY](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/12-cm-loop-yagi-kit-dse1276ly.pdf) * [Sim-Hyperlink Wireless Dish Antenna Model HG5158DP-32D](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/sim-hyperlink-hg5158dp-32d.pdf) ## Rotator references * [SPID Setup Standard Rotor](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/spid-setup-standard-rotor.pdf) * [SPID BigRAS/HR Operation and Maintenance](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/spid-bigras-hr-operation-maintenance.pdf) * [Satellite Rotator Manual](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/satellite-rotator-manual.pdf) * [AlfaSpid ROT2Prog Manual](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/alfaspid-rot2prog-manual.pdf) * [ALFARotator FAQ](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/alfarotator-faq.pdf) * [SPID RAS Specifications](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/spid-ras-specifications-md03.pdf) * [SPID HR Support Page](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/spid-hr-support-page.pdf) ## Tower reference * [Aluma Tower Safety Data](https://github.com/UCF-Knights-Satellite-Club/kscwiki/blob/main/.gitbook/assets/physics-ground-station/reference-documents/aluma-tower-safety-data.pdf) # Orbital CubeSat {% hint style="info" %} This is a future project. More information will be available soon. {% endhint %}
# Knight Satellite The project that started the club. # General Ballooning Information Access to ballooning is an integral part of any student space organization, providing cheap and reliable access to different environmental conditions across the Earth's Atmosphere. There are two ways to perform ballooning experiments: Unmanned Moored Balloons, which are limited by the FAA to be no greater than 500 feet, and Unmanned Free Balloons, which fly to the top of the Earth's atmosphere. This portion of the Wiki is meant to serve as a guide for new students within the Knights Satellite Club and other groups who want to get started in experimenting with ballooning. ## Definitions Unmanned Moored Balloon - A balloon carrying a payload that is secured to the ground and flies at an altitude of less than 500 feet. Unmanned Free Balloon (High Altitude Balloon -or- HAB) - A balloon carrying a payload that flies to the top of the atmosphere. Unmanned Free Balloons pop when the volume of gas in the balloon stretches the latex beyond its failure point. Neck Lift - How much upward force a filled balloon has when measured at the neck of the balloon. Lifting Gas - The gas that fills the balloon to produce lift. It should be either Hydrogen or Helium. ## Materials Below is a list of reusable materials that you should have prior to any balloon flight: * Picnic Blanket/Tarp * Rubber Gloves * Shower Hair Nets * Hardware Gloves * Balloon Inflator Hose * Zip Ties * Nylon String or Heavy Duty Fishing Line * Electrical Tape * Force Spring Scale * 2-inch O-Rings (3D Printed or Metal) * Carabiners (3D printed or Metal) * Key Chain Rings * 360 Swivel Eye Bolt * Parachute * Stabilizer (if a 2 payload setup is used) * Radar Reflector Below is a list of materials that will need to be replaced often: * Balloon (Sized Correctly) * Payload * Lifting Gas
## Sizing Balloons You need to choose the right balloon for what you are launching and where you are launching to. Unmanned Moored Balloons don't need a very large balloon since you are restricted to 500 feet off the ground. First, you need to determine if you're launching a Moored Balloon or a Free Balloon. If you're launching a Moored Balloon, your Neck Lift, or how much upward lift your balloon has, doesn't need to be too large. Second, you need to determine the weight of your payload. Launching on a Moored Balloon requires slightly more Neck Lift than what is required for buoyancy since the balloon doesn't need ot lift very fast. Once these two things are determined, you can start playing with a launch calculator like [Habhub](https://habhub.org/) to determine the balloon size and how much Lifting Gas you will need. Launching in Florida is not great for unmanned free balloons that want to be recovered. There is only a short window in the year when the upper altitude winds blow westward. Thus, most free balloons will want to be slightly overfilled to travel to the top of the atmosphere quickly without traveling a great distance across the ground. Depending on the size of the balloon, this could mean that the balloon pops at a lower altitude than desired. ### Orlando FSDO Contact 8427 Southpark Circle, Suite 500\ Orlando, FL 32819-9060 Phone: (407) 487-7000 <9-AVS-AFG-ORL-FSDO-91@faa.gov> This will be the point of contact when submitting launch & landing notices. ### Misc. Information It is a good idea to label both Moored and Free Balloons with contact information so that if the payload gets lost, it can be recovered by private citizens. Place the identifying piece of paper on the top of each payload box with a few other phone numbers on each box. In the past, the Knights Satellite Club has used the sitting Project Committee Chair or the President's phone numbers. The following Template can be used. {% file src="/files/u5sc9mZAaphC94htXJ4A" %} # Moored Balloons ## Definition The Official Definition of a Moored Balloon (also known as a Tethered Balloon) is "a balloon that is secured by a rope or cable to the surface of the Earth or an object thereon." (Federal Aviation Agency Part 48 Civil Air Restrictions, Operation Rules For Moored Balloons and Kites, June 4, 1962). ## Restrictions {% embed url="" %} No Balloon that is Moored to the Surface of the Earth of an object thereon may * Have a diameter of more than 6 feet or a gas capacity of more than 115 cubic feet. * Operate less than 500 feet from the base of any cloud. * Operate more than 500 feet above the surface of the Earth. * Operate from an area where the ground visibility is less than three miles or within five miles of the boundary of any airport. * Operate between sunset and sunrise unless the balloon and its mooring lines are lighted so as to give visual warning equal to that required for obstructions to air navigation in the FAA publication "Obstruction Marking and Lighting." * Additionally, colored pennants or streamers attached at not more than 50 foot intervals beginning at 150 feet above the surface of the Earth and are visibile for at least one mile is required. * Operate unless it has a device that will automatically and rapidly deflate the balloon if it escapes from its moorings. If the device doesn't function properly, the operator must immediately notify the nearest ATC facility of the location and time of the escape and the estimated flight path of the balloon. Every Moored Balloon that exceeds 150 feet above the surface of the Earth must notify the FAA of the following **at least** 24 hours before beginning the operation. * The names and addresses of the owners and operators. * The size of the balloon. * The location of the operation. * The height above the surface of the Earth at which the balloon is to be operated. * The date, time, and duration of the operation. ## Launching an Unmanned Moored Balloon At the start of every operation of launching an Unmanned Moored Balloon, after everyone has arrived, a safety meeting must be conducted. The safety meeting should consist of the operation's plans, personnel assignments, action items if something goes wrong, and a list of safety equipment. Once the team has arrived at the launch site, please ensure that there are a maximum of 4 people around the balloon to avoid overcrowding it, and everyone working with the balloon should be wearing gloves, hair nets, and safety glasses. Below is a list of steps to follow on how to fill and tie off the balloon, and a document with pictures. While this is ongoing, there should be another team preparing the payload for flight. 1. Lay a blanket, towel, or tarp on the ground to prevent the balloon from directly touching the ground. Especially when working on grass, the macroscopic sharpness of the grass can cause microtears in the balloon. 2. Unscrew the safety lid from the gas tank. From this point on, everyone within 20 feet of the balloon should be wearing safety glasses. 3. Attach the regulator to the gas tank. For Helium, this should be a CGA-580 regulator. A single-stage regulator is fine, but a dual-stage regulator is preferred due to safety reasons. A dual-stage regulator will allow users to regulate the rate at which the gas leaves the tank and has a separate valve to cut off the gas from leaving the regulator; however, dual-stage regulators are much more pricey. 4. Spread the balloon out on the blanket, and be careful not to step on the latex. The neck of the balloon is much thicker and can stand a little bit of roughness, but the skin on the rest of the balloon is very easy to tear. Using gloves and hairnets prevents the oil produced from the human body from getting onto the balloon and degrading it, as well as preventing the hair on our heads from poking microscopic tears in the balloon. 5. Insert the balloon fill-line into the neck of the balloon and zip tie it around the outside of the neck of the balloon. Before tightening the zip tie, please attach a small string with a loop to the zip tie and tie another length of string to attach to the gas tank cart or another weight to prevent the balloon from flying away if someone lets go of it. 6. If using a single-stage regulator, open the valve at the top of the tank, then slowly open the valve to stream gas into the balloon. Slowly open the regulator until the valve is entirely open. If using a dual-stage regulator, open the valve at the top of the tank, set the flow limit of the gas into the regulator, then slowly open the other valve at the end of the regulator. Slowly open the regulator until the valve is entirely open. 1. It is good practice that once a valve is opened entirely, the valve be closed a hair of a turn, so if someone else tries to test the state of the valve that they don't break it. 2. During this process, someone should be holding onto the tank and monitoring the pressure left in the tank while a separate person monitors the balloon by holding onto the neck. 3. Additional people may be required if the balloon is large or if it is windy; these additional people can put their hands up to stop the balloon from blowing in a certain direction. 7. Once the balloon lifts itself off the ground, attach the force scale to the string with the loop and either stake the other end into the ground or securely hold the force scale in place, like by gripping the handrail of the gas cart, so the lifting weight can be measured properly. Continue filling the balloon until the desired lift weight is achieved. 1. If the predetermined lift weight is too much for the force spring scale, a digital fish scale is not recommended. It is recommended that gym weights or calibration weights be used to hang from the same loop and to continue to fill the balloon until the balloon naturally lifts these weights off the ground without sinking. 8. Once the balloon has achieved its desired lift weight, close the valve to the regulator and the tank. Hold the neck of the balloon and twist the rest of it to cut off the flow through the neck. Place a zip tie around the twist so it doesn't undo itself. While maintaining a tight grip on the balloon, twist the inflator hose out of the neck and try not to let the zip ties that are holding the tether string fall. Push these zipties further up the neck of the balloon, and tighten them down around the twist. Very carefully, with the points pointed away from the balloon, snip the tails of the zip ties off. 9. Feed the neck of the balloon through an o-ring and fold the neck over the o-ring so it sits next to the twist. Use additional zip ties to hold the end of the neck up so the o-ring stays in place. Carefully cut the tails of the zip ties off and use electrical tape to cover the sharp ends so they do not swing up and puncture the balloon. 10. Attach a string for the payload to attach to, and attach the string tether to the o-ring. 11. Assign someone from the balloon filling team to hold the balloon via the o-ring until it is launch time. {% file src="/files/NIVzndQPoqAHxURhTHJc" %} ## Launching an Unmanned Moored Balloon at UCF Previous Unmanned Moored Balloon launches at UCF, conducted by the Knights Satellite Club, took place in the Arboretum Park behind the L3 Harris Building. However, due to the safety concerns of rolling compressed gas over uneven terrain, without the ability to lift the tank off the ground if it gets stuck, it is recommended that future Unmanned Moored Balloon launches be conducted in Surface Lot D1. Ideally, all launch materials should be gathered, and the payload should be in a testing phase ahead of launch. In order to launch, a SAFE form must be filled out **AT LEAST 15 days** before the scheduled launch date. Please use the following as a reference when completing each SAFE form (). Additional information will be required if each launch chooses to launch from a parking lot as well as communication with UCF Parking Services. (Just copy and paste into fields) These regulations are subject to change over time. * Organization Name: Knights Satellite Club Organization * Type: RSO * Advisor Email: * Event Title: Tethered Balloon Launch *Name of Mission* * Location: Arboretum * Location Details: Arboretum Park * Number of Students: ## * Number of Non-Students: 0 * Description: This is a Moored (Tethered) Balloon Launch from the Arboretum Park behind the L3 Harris Engineering Building. We intend to use the space right behind the trailer as it has little tree coverage and electrical outlets on the trailer. Similar to the last launch we performed earlier this semester, a 125 cubic foot Helium tank will be purchased and stored in PSB 461, where it will be transported via handcart to the Arboretum Park. The handcart has large enough pneumatic wheels that it traveled easily over mulch without the need for it to be picked up as that is prohibited. We intend to launch on the morning of **DATE** starting at around 8 am and will be done by no later than noon. If **DATE** is rained out, then we request a backup date of **BACK UP DATE** at the same time. To be clear, this is a Moored Balloon Flight as defined by the FAA rules found at the following link. This is NOT a Hot Air Balloon, it is an unmanned scientific payload. * No Food * No Alcohol * Organization will clean * Description: Club Members will keep track of all materials brought to the launch site and gather all trash produced, which will mainly be zip tie tails and the remains of the balloon once it has been expended. Once the Helium has reached its destination, all parties working directly with the Helium will be expected to wear safety glasses, and anyone who comes within 20 feet of the gas tank is also expected to wear safety glasses. * No Open Flame * No Additional Sound/Lighting * No Minors * No Temp Bleachers * No Power * Start Time is 8 am, End Time is 12 pm Set repeat Daily and end on the next day If launching from the Arboretum Park, please use the following information to fill out an Arboretum Park Use Form. These must be submitted **AT LEAST 3 weeks** in advance of the launch date (). * Event Title: Tethered Balloon Launch *Mission Name* * UCF Department/Affiliation: Knights Satellite Club * Open Grass Space (behind office) * Event Name: Tethered Balloon Launch *Mission Name* * Start and End Date should be consecutive Day(s) of the week: Saturday/Sunday (if the form only allows you to choose one, choose the first day) * Start Time 8:00 am End Time 12:00 pm * No Assistance * No Power * No Plants * \## Students, 2 Faculty, 0 Staff, 0 Other *** ### Safety Regulations Dictated by UCF Safety Departments: #### Environmental Health and Safety: * UCF Policy (Laboratory Safety Manual, digital page 67) does not support transportation of gas cylinders on public roadways by means other than vendor delivery. * From Dr. Sandra Hick @ Environmental Health and Safety * "Gas cylinder dollies are **not** generally built for easy movement across soft terrain or over objects that may become entrained in the wheels. It may be difficult to move a size 80 tank of helium (roughly 49 lbs and 36” high) safely through the Arboretum path to the proposed location. Though it may be tempting, **safe cylinder transportation does not allow the cylinder to be carried**." * From David Fikhman @ Environmental Health and Safety * "The main worry is the uneven path that your group may face on the way to the launch site, but if you are careful and have the cylinder appropriately strapped and transferred as they say then it is fine. * My main suggestion/recommendation for them, if they could do this, is to find a launch site that could potentially be in an open parking lot of area where they do not need to move the tank over uneven surfaces. Even if it rained beforehand, it could make the ground surface slippery as well which could be a big hazard. * It would be best to do the suggestion to avoid any uneven surfaces/potential hazards associated with an unpaved road." * "If you are able to apply the impact-resistant plastic material to help move the cart, and have the PI come launch with you, I approve of it. * Just want to ensure there is as minimal of a risk as possible. Thank you!" * When traversing uneven ground, the club must use non-slip flat surfaces to roll the gas cart over the uneven terrain. Plywood, Balsam Wood, or plastic sheets work fine. #### Emergency Management * No Balloon Flight may take place during a football game, as there is a Temporary Flight Restriction in place for each game. #### Risk Management * Must specify that Unmanned Moored Balloon Launches are not Hot Air Balloon Launches. #### Reference Documents {% file src="/files/SsUdGFHzMMkz5QQWv1Ye" %} {% file src="/files/6nZDgC7kNdqRytT0rBCF" %} {% file src="/files/frFRmUdRMwULdDMATqcU" %} # High Altitude Free Balloons ## Definition The definition of an Unmanned Free Balloon (also known as a High Altitude Balloon) is a balloon that travels freely through the atmosphere through atmospheric buoyancy, and is unpowered. ## Restrictions {% embed url="" %} For the following types of unmanned free balloons must follow the rules detailed below as outlined in Title 14 Chapter 1 Subchapter F Part 101: * Carries a payload package that weighs more than four pounds and has a weight/size ratio of more than three ounces per square inch on any surface of the package, determined by dividing the total weight in ounces of the payload package by the area in square inches of its smallest surface; * Carries a payload package that weighs more than six pounds; * Carries a payload, of two or more packages, that weighs more than 12 pounds; or * Uses a rope or other device for suspension of the payload that requires an impact force of more than 50 pounds to separate the suspended payload from the balloon No Unmanned Free Balloon may * Operate below 2,000 feet within the surface area of Class B, Class C, Class D, or Class E airspace. * Operate at any altitude where there are clouds or obscuring phenomena of more than five-tenths coverage. * At any altitude below 60,000 feet, standard pressure altitude where the horizontal visibility is less than 5 miles. * During the first 1,000 feet of ascent, over a congested area of a city, town, or settlement or an open-air assembly of persons not associated with the operation. * Operate in such a manner that the impact of a balloon, or any part of its payload, with the surface creates a hazard to persons or property not associated with the operation. No person may operate an unmanned Free Balloon * Unless it is equipped with at least two payload cut-down systems or devices that operate independently of each other. * Unless at least 2 methods, systems, devices, or combinations thereof that function independently of each other are employed for terminating the flight of the balloon. * Unless the balloon is equipped with a radar reflective device or material that will present an echo to surface radar operating in the 200 MHz to 2700 MHz frequency range. * Below 60,000 feet standard pressure altitude between sunset and sunrise unless the balloon and its attachments/payload, whether or not they become separated during the operation, are equipped with lights that are visible for at least 5 miles and have a flash frequency of at least 40 and not more than 100 cycles per minute. * That is equipped with a trailing antenna that requires an impact force of more than 50 pounds to break it at any point, unless the antenna has colored pennants or streamers that are attached at not more than 50-foot intervals and that are visible for at least one mile. * Between sunrise and sunset, that is equipped with a suspension device (other than a highly conspicuously colored open parachute) more than 50 feet long, unless the suspension device is colored in alternate bands of high conspicuity colors or has colored pennants or streamers attached which are visible for at least one mile. Every Unmanned Free Balloon must notify the nearest FAA ATC facility of the following **within 6 to 24 hours** before beginning the operation. * The Balloon Identification. * The estimated date and time of launching, amended as necessary to remain within plus or minus 30 minutes. * The location of the launching site. * The cruising altitude. * The forecast trajectory and estimated time to cruising altitude or 60,000 feet standard pressure altitude, whichever is lower. * The length and diameter of the balloon, the length of the suspension device, the weight of the payload, and the length of the trailing antenna. * The duration of the flight. * The forecasted time and location of impact with the surface of the Earth. For solar or cosmic disturbance investigations involving a critical time element, the above information shall be given within **30 minutes to 24 hours** before beginning the operation. If the operation is canceled, the person who intended to conduct the operation shall immediately notify the nearest FAA ATC facility. Each person operating an unmanned free balloon shall notify the nearest FAA or military ATC facility of the launch time immediately after the balloon is launched. Each person operating an unmanned free balloon shall * Monitor the course of the balloon and record its position at least every 2 hours and forward this information to the nearest FAA ATC as requested. * One hour before descent, provide the following information to the nearest FAA ATC facility * The current geographical position * The Altitude. * The forecasted time of penetration of 60,000 feet standard pressure altitude (if applicable). * The forecasted trajectory for the balance of the flight. * The forecasted time and location of impact with the surface of the Earth. * If a balloon position report is not recorded for any 2-hour period of flight, the person operating an unmanned free balloon shall immediately notify the nearest FAA ATC facility. The notice shall include the last recorded position and any revision of the forecasted trajectory. The nearest FAA ATC facility shall be notified immediately when tracking of the balloon is re-established. * Each person operating an unmanned free balloon shall notify the nearest FAA ATC facility when the operation is ended. ## Launching an Unmanned Free Balloon ### Balloon Filling Instructions: Once the team has arrived at the launch site, please ensure that there are a maximum of 4 people around the balloon to avoid overcrowding it, and everyone working with the balloon should be wearing gloves, hair nets, and safety glasses. Below is a list of steps to follow on how to fill and tie off the balloon, and a document with pictures. While this is ongoing, there should be another team preparing the payload for flight. 1. Lay a blanket, towel, or tarp on the ground to prevent the balloon from directly touching the ground. Especially when working on grass, the macroscopic sharpness of the grass can cause microtears in the balloon. 2. Unscrew the safety lid from the gas tank. From this point on, everyone within 20 feet of the balloon should be wearing safety glasses. 3. Attach the regulator to the gas tank. For Helium, this should be a CGA-580 regulator. A single-stage regulator is fine, but a dual-stage regulator is preferred due to safety reasons. A dual-stage regulator will allow users to regulate the rate at which the gas leaves the tank and has a separate valve to cut off the gas from leaving the regulator; however, dual-stage regulators are much more pricey. 4. Spread the balloon out on the blanket, and be careful not to step on the latex. The neck of the balloon is much thicker and can stand a little bit of roughness, but the skin on the rest of the balloon is very easy to tear. Using gloves and hairnets prevents the oil produced from the human body from getting onto the balloon and degrading it, as well as preventing the hair on our heads from poking microscopic tears in the balloon. 5. Insert the balloon fill-line into the neck of the balloon and zip tie it around the outside of the neck of the balloon. Before tightening the zip tie, please attach a small string with a loop to the zip tie and tie another length of string to attach to the gas tank cart or another weight to prevent the balloon from flying away if someone lets go of it. 6. If using a single-stage regulator, open the valve at the top of the tank, then slowly open the valve to stream gas into the balloon. Slowly open the regulator until the valve is entirely open. If using a dual-stage regulator, open the valve at the top of the tank, set the flow limit of the gas into the regulator, then slowly open the other valve at the end of the regulator. Slowly open the regulator until the valve is entirely open. 1. It is good practice that once a valve is opened entirely, the valve be closed a hair of a turn, so if someone else tries to test the state of the valve that they don't break it. 2. During this process, someone should be holding onto the tank and monitoring the pressure left in the tank while a separate person monitors the balloon by holding onto the neck. 3. Additional people may be required if the balloon is large or if it is windy; these additional people can put their hands up to stop the balloon from blowing in a certain direction. 7. Once the balloon lifts itself off the ground, attach the force scale to the string with the loop and either stake the other end into the ground or securely hold the force scale in place, like by gripping the handrail of the gas cart, so the lifting weight can be measured properly. Continue filling the balloon until the desired lift weight is achieved. 1. If the predetermined lift weight is too much for the force spring scale, a digital fish scale is not recommended. It is recommended that gym weights or calibration weights be used to hang from the same loop and to continue to fill the balloon until the balloon naturally lifts these weights off the ground without sinking. 8. Once the balloon has achieved its desired lift weight, close the valve to the regulator and the tank. Hold the neck of the balloon and twist the rest of it to cut off the flow through the neck. Place a zip tie around the twist so it doesn't undo itself. While maintaining a tight grip on the balloon, twist the inflator hose out of the neck and try not to let the zip ties that are holding the tether string fall. Push these zipties further up the neck of the balloon, and tighten them down around the twist. Very carefully, with the points pointed away from the balloon, snip the tails of the zip ties off. 9. Feed the neck of the balloon through an o-ring and fold the neck over the o-ring so it sits next to the twist. Use additional zip ties to hold the end of the neck up so the o-ring stays in place. Carefully cut the tails of the zip ties off and use electrical tape to cover the sharp ends so they do not swing up and puncture the balloon. 10. Attach a string for the payload to attach to, and attach the string tether to the o-ring. 11. Assign someone from the balloon filling team to hold the balloon via the o-ring until it is launch time. {% file src="/files/NIVzndQPoqAHxURhTHJc" %} Balloon Filling Video WIP ### Launching with a Single Payload Configuration The weight capacity of a single payload is 6 pounds. Be sure that the payload is turned on and is broadcasting its telemetry, and \*most importantly\* that you’re receiving that telemetry BEFORE you tie up the payload. Use the following video to help tie up the payload box. Instead of finishing with a bow, finish with a knot. {% embed url="" %} Additionally, knots similar to Alpine Butterfly Loops will be needed on the four sides of the payload, so make sure you leave enough rope for you to complete this. We recommend tying these loops as you tie up the payload. For assistance with the Alpine Butterfly Loops, follow this video: {% embed url="" %} On each of the Alpine Butterfly Loops, attach key rings on the top payload (or for Single Payloads, the payload) 1. Tie the end of the string to another key ring, then loop the string through one of the key rings on the payload. 2. Then loop it back through the “tied key ring,” then down to the key ring on the payload opposite of the side you just looped through. 3. Go back up to the “tied key ring”, then down to the payload again. 4. Return to the “tied key ring”, then down to the last key ring on the payload. 5. Return to the “tied key ring” and pull up on the “tied key ring” to stabilize the four points. Cut the rope from step 4 and tie it to the “tied key ring. This will be the point at which the payload attaches to the balloon train.
For the rest of the balloon train, we will start at the top with the balloon. 1. Using the O-ring that the balloon neck was zip-tied around, run a length of at least 6 feet of string to the top of the parachute. The parachute should have a loop at its apex. 2. Gently lay the parachute out so that it doesn’t tangle as the balloon rises when liftoff comes. 3. Attach the 4 loops of the parachute to a carabiner and attach that to one side of the swivel eye bolt. 4. Tie another length of string, at least 6 feet long to the side of the swivel eye bolt that is not shared with the parachute. Tie the other end of this string to the “tied key ring” from the steps above. 5. When it is time to launch, slowly raise the balloon train into the sky and hold on to the payload. 6. Count down and release. ### Launching with a 2 Payload Configuration Launching with a 2 payload configuration doesn’t deviate too much from a single payload, but there are a few more considerations. Firstly, the total payload capacity now is 12 pounds, with each payload being a maximum of 6 pounds. Because of the addition of a second payload, stability between the 2 payloads is important, and they should not be positioned right next to each other. According to physics, a longer pendulum swings at a longer frequency, so we recommend a separation distance of at least 6 feet between the payloads with a stabilizer in between. In the past, half of a 3D print filament has been used. See the picture below (stabilizer between the 2 white boxes):
We recommend tying the payloads up separately, then attaching them to the balloon train. Use the following YouTube video to help tie up the payload. Instead of finishing with a bow, finish with a knot. (This is the same sequence as the single payload.) {% embed url="" %} Additionally, knots similar to Alpine Butterfly Loops will be needed on the four sides of the payload, so make sure you leave enough rope for you to complete this. We recommend tying these loops as you tie up the payload. For assistance with the Alpine Butterfly Loops, follow this video: {% embed url="" %} On each of the Alpine Butterfly Loops, attach key rings on the top payload (or for Single Payloads, the payload) 1. Tie the end of the string to another key ring, then loop the string through one of the key rings on the payload. 2. Then loop it back through the “tied key ring,” then down to the key ring on the payload opposite of the side you just looped through. 3. Go back up to the “tied key ring”, then down to the payload again. 4. Return to the “tied key ring”, then down to the last key ring on the payload. 5. Return to the “tied key ring” and pull up on the “tied key ring” to stabilize the four points. Cut the rope from step 4 and tie it to the “tied key ring. This will be the point at which the payload attaches to the balloon train. On the payload stabilizer, add 4 key rings to it and attach 2 pieces of string that are at least 3 feet long each to each key ring. Tie the other end of 4 pieces of string (one from each key ring) to the key rings on the Alpine Butterfly Loops. Attach key rings to the 4 Alpine Butterfly Loops to the bottom payload, and tie the other ends of the remaining 4 pieces of string.
For the rest of the balloon train, we will start at the top with the balloon. 1. Using the O-ring that the balloon neck was zip-tied around, run a length of at least 6 feet of string to the top of the parachute. The parachute should have a loop at its apex. 2. Gently lay the parachute out so that it doesn’t tangle as the balloon rises when liftoff comes. 3. Attach the 4 loops of the parachute to a carabiner and attach that to one side of the swivel eye bolt. 4. Tie another length of string, at least 6 feet long to the side of the swivel eye bolt that is not shared with the parachute. Tie the other end of this string to the “tied key ring” from the steps above. 5. When it is time to launch, slowly raise the balloon train into the sky and hold on to the payload. 6. Count down and release. # Board Details about how the leadership within KSC is structured. The Board is made up of four Board Members, also known as Officers. Each Officer has a unique and critical role in keeping KSC running smoothly. Officers are elected by KSC Members in April and serve a one year term. The Board in turn creates and manages Committees to assist in completing their tasks. The Board is also responsible for keeping KSC's Faculty Advisors informed about all activities. Each Officer must be registered with UCF Student Government (SG) which regulates the **Knights Satellite Club** Registered Student Organization (RSO), and registered with the Florida Department of State's Division of Corporations which regulates the **Knights Satellite Club Inc.** not for profit corporation. Serving on the Board is a significant commitment and will require working with many individuals and organizations within and beyond UCF. More details about Officer roles and elections can be found in the KSC Constitution: {% file src="/files/tvDqsZ3Eh4gORD2K0Ne9" %} Knights Satellite Club Constitution as of 2023 {% endfile %} *** ## [President](/club-operations/board/president) The President is the leader of the Knights Satellite Club. They are primarily responsible for keeping the club on track with club goals and the implementation of activities, events, & projects toward those club goals. The Knight Satellite Club's primary objective is "To Create a Platform which Acceleraties the Learning Curve for Students Aspring to Work in Engineering Field thorugh Space-System Development." These student not only include engineers from within UCF's College of Engineering and Computer Science, but also Business, Finance, Marking, Visual Arts, etc. students who are necessary for club success. *** ## [Vice President](/club-operations/board/vice-president) The Vice President of the Knights Satellite Club is to assist the President with their duties. *** ## [Treasurer](/club-operations/board/treasurer) The Treasurer is the link between the legal entity of KSC and the group of people acting as KSC. They must be listed as the responsible party with the United States Internal Revenue Service (IRS), must be a financially trained authorized officer with UCF Student Government (SG), and must be the person listed on and in control of the bank account. They are also responsible for filing the annual paperwork that is required by law. *** ## [Secretary](/club-operations/board/secretary) The Secreatry of the Knights Satellite Club is primarily responsible for keeping records of meeting notes at Advisor Meetings & Officer Meetings. They are also responsible for the timely upkeep of the club's Webpage & Social Media. *** ## Elections {% hint style="info" %} More Information Coming Soon {% endhint %} *** ### [Committees](/club-operations/committees) Each Board Member is supported by a Committee. Please visit the Committees page for more information. # President Description and responsibilities of the President within KSC. ### RSO Upkeep Responsibilities * Supervise and coordinate the activities of the organization. * Maintain communication with the Office of Student Involvement and ensure that all RSO paperwork is current. * Be one of three signers on financial documents. * Ensure that all officers are performing their duties as defined in this Constitution. * Be familiar with the Golden Rule regulations as they relate to student organizations and communicate them to the organization as needed. * Provide all documents and records pertaining to their responsibilities to the newly-elected President. * Delegate Tasks to other Board and Committee Chair Members to advance club progress. ### Meetings Responsibilities * Be familiar with Robert’s Rules of Order to conduct meetings. * Maintain Routine Communication with Club Advisors * Preside over all meetings and call all meetings to order. These include but are not limited to: * Advisor Meetings * Board Meetings * General Body Meetings * Project Committee Chair Meetings *** ### Project Responsibilities All projects are a reflection of the President, thus the responsibility of competing all open projects falls on the President who is to identify adequate project leads. As President, it is your responsibility to create & augment the vision of the Knights Satellite Club to maintain and enhance an organization committed to developing engineers and connecting them to research and internship opportunities. # Vice President Description and responsibilities of the Vice President within KSC. ### Responsibilities * Assist the President in their duties. * Assume the President’s responsibilities in their absence. * Coordinate all conferences. * Keep accurate records of all meetings in the Secretary’s absence. * Plan and be responsible for all retreats and training of the organization. * Perform an audit of all financial transactions of the organization once per semester. * Provide all documents and records pertaining to their responsibilities to the newly-elected Vice President. * Assist in special projects as assigned by the President. *** ### Event Responsibilities # Secretary Description and responsibilities of the Secretary within KSC. ### Responsibilities * Notify members of meetings via e-mail and/or telephone at least 48 hours in advance. * Keep accurate minutes and records of all meetings. * Maintain an accurate list of members and their contact information. * Prepare the organization’s Update Form to submit to OSI at the beginning of each semester, and when there are changes in organizational information over the course of the semester. * Take attendance at all meetings and maintain an attendance record. * Prepare ballots for elections. * Check eligibility for potential officers, prior to annual elections. * Keep a copy of the constitution and have it available for members. * Provide all documents and records pertaining to their responsibilities to the newly-elected Secretary. * Assist in special projects as assigned by the President. *** ### Public Relations Responsibilities # Treasurer Description and responsibilities of the Treasurer within KSC. ### Responsibilities * Keep an accurate account of all funds received and expended. * Present a budget report of deposits and expenditures to the membership at least once per month, and as requested by the President, Vice President, advisor, or Office of Student Involvement. * Be one of three signers on financial documents. * Be responsible for collecting dues and notifying members who are delinquent in their payments. * Be responsible for creating a budget at the beginning of each fall and spring semester, in conjunction with the President. * Provide financial records sufficient to allow the Vice President to perform audits. * Provide all documents and records pertaining to their responsibilities to the newly-elected Treasurer. * Assist in special projects as assigned by the President. ### Required Paperwork * File [8822-B](https://www.irs.gov/forms-pubs/about-form-8822-b) with IRS * This form allows for changing things like address and responsible party of a business * Only change should be updating the responsible party to the new Treasurer * Must be filed within 60 days of election * Will need to be mailed * File [990n](https://www.irs.gov/charities-non-profits/annual-electronic-filing-requirement-for-small-exempt-organizations-form-990-n-e-postcard) with IRS * Annual filing requirement for tax exempt organizations * Gross receipts of prior fiscal year must be less than $50,000 (they will be) * Due May 15th for fiscal year ending on December 31st * Can be submitted electronically * File [Annual Report](https://dos.fl.gov/sunbiz/manage-business/efile/annual-report/instructions/) with Florida Division of Corporations (Sunbiz) * Annual filing requirement for businesses in Florida * Needs to include the new officers * Due May 1st * Can be submitted electronically * File [Solicitation of Contributions Annual Financial Reporting Form](https://www.fdacs.gov/Business-Services/Solicitation-of-Contributions) with Florida Department of Agriculture and Consumer Services * Annual filing requirement for anyone who solicits donations in Florida * Can be submitted electronically * Submit RSO Re-Registration Form with SG Office of Student Involvement * Will be accessible from KSC KnightConnect home management page * All authorized officers (President, Vice President, Treasurer, Secretary) must complete [RSO training](https://osi.ucf.edu/rso/) * Submit Banking Letter Request with SG Knights of the Round Table * Will be accessible from Forms tab on KnightConnect * Anyone with access to the bank account (minimum President and Treasurer) must complete [financial training](https://asf.sdes.ucf.edu/training/) and be listed on banking letter * Once form has been approved, take form to the campus FAIRWINDS branch to have the account transferred over *** ### Fundraising Responsibilities # Committees Details on how Committees function within KSC. Committees are a way for Knight Satellite Club members to get involved with the day-to-day operations of the organizations. Each committee is led by a Committee Chair who is appointed by the Board each semester. * The Committee Chair * May only be appointed for 2 Semesters in a row. * Is responsible for ensuring the Committee is fulfilling its clearly defined roles and responsibilities. * Is responsible for managing Subcommittee/Project Lead appointments. * Reports directly to and is assisted by one of the Officers on the Board. * KSC members are free to participate in any committees and may be appointed to Subcommittee/Project Lead roles by each Committee Chair. Committees can be created, modified, or disbanded at any time at the discretion of the Board. If there are no candidates for a Committee Chair, the Officer in which the Committee Chair would normally report to assumes the role of Committee Chair until a candidate is found. *** ## [Projects Committee](/projects/tethered-satellite) **Reports to: President** The Projects Committee oversees the direction and execution of all technical projects within KSC. The Project Committee must maintain proper documentation, adherence to timelines and goals, and follow relevant regulations. ### Responsibilities 1. Strategic Direction 1. Collaborate with the Board to define the mission, vision, and priorities for all KSC projects. 2. Accept and review proposals for new projects from KSC members. 2. Project Management 1. Ensure all Project Leads adhere to timelines and deliverables. 2. Foster communication and collaboration between teams. 3. Documentation 1. Maintain up-to-date project documentation on the KSC Wiki. 2. Ensure projects and missions have appropriate conclusions and reflections documented upon completion. 3. Establish best practices for documentation and technical workflows. 4. Regulatory Compliance 1. Ensure all project activities meet university, local, and state regulations. 2. Handle administrative tasks related to project launches and events *** ## [Events Committee](/club-operations/committees/events-committee) **Reports to: Vice President** The Events Committee is responsible for the planning and execution of socials, General Body Meetings, workshops, industry tours, conference visits, and other non-project KSC activities. ### Responsibilities 1. Tours 1. Schedule and coordinate industry tours with relevant partners. 2. Manage logistics, including carpooling and headcounts. 2. Conferences 1. Organize participation in conferences such as the Small Satellite Education Conference at Kennedy Space Center and the SmallSat Conference in Utah. 2. Identify costs such as transportation, room, and registration, and communicate these costs to the Treasurer. 3. Technical Workshops 1. Identify, develop, and prepare materials for workshops relevant to KSC members and projects. 2. Partner with relevant UCF RSOs to hold collaborative workshops. 4. Professional Development Workshops 1. Develop and maintain current material on topics pertaining to building a career such as resumes, LinkedIn profiles, networking, and internships. 2. Identify and facilitate collaboration with industry guest speakers such as recruiters, HR specialists, and representatives. 5. Certification Workshops 1. Identify relevant industry certifications that could benefit KSC members, and contact certifying organizations for potential collaboration. 2. Host certification training and test sessions. *** ## [Fundraising Committee](/club-operations/fundraising) **Reports to: Treasurer** The Fundraising Committee secures financial resources for KSC by organizing events, seeking sponsorships, and maintaining compliance with nonprofit regulations. ### Responsibilities 1. Sponsorships and Grants 1. Identify potential sponsors and collaborate with the Board to establish mutually beneficial relationships with sponsoring organizations. 2. Identify grants that KSC might be eligible for and work with the Board to submit any required applications or proposals. 3. Work with the Public Relations Committee to ensure sponsors are adequately recognized for their contributions. 2. Fundraising Events 1. Collaborate with the Events Committee for integrated fundraising opportunities such as partial proceeds events. 2. Collaborate with the Public Relations Committee for tracking and collecting funds from merchandise sales. 3. Record Keeping 1. Maintain detailed records of income and expenses for fundraising activities. 2. Regularly report progress to the Treasurer. *** ## [Public Relations Committee](/club-operations/committees/public-relations-committee) **Reports to: Secretary** The Public Relations Committee maintains KSC's online presence and visual branding, creating promotional materials and maintaining communication channels to engage members and the broader community. The Public Relations Committee is also tasked with growing KSC through recruitment and outreach events. ### Responsibilities 1. Online Presence 1. Create and post engaging content on Instagram, LinkedIn, and other platforms. 2. Maintain KSC's website with up-to-date information about projects, events, and achievements. 3. Ensure branding consistency across all platforms. 2. Physical Presence 1. Design flyers, posters, and logos for KSC events and missions. 2. Produce recruitment materials and share them with prospective members. 3. Organize tabling events to recruit students with technical, artistic, and administrative interests. 4. Work with UCF organizations such as KoRT and SG to ensure KSC is represented at campus events. 5. Work with professors for key classes such as the required introductory engineering classes (EGS 1006C and EGN 1007C) to inform students about opportunities within KSC. 3. Merchandise Management 1. Design, produce, and distribute KSC merchandise. 2. Collaborate with the Fundraising Committee for sales and inventory tracking. # Projects Committee Description and responsibilities of the Projects Committee within KSC. # Events Committee Description and responsibilities of the Events Committee within KSC. # Public Relations Committee Description and responsibilities of the Public Relations within KSC. # Fundraising Committee Description and responsibilities of the Fundraising Committee within KSC. # Fundraising Details and documentation on how KSC raises the money to accomplish our goals. Knights Satellite Club primarily relies on fundraising for operating funds. Most of our fundraising comes in the form of tax-deductible donations made possible by our 501(c)(3) status. We also get significant support from the UCF Student Government. This page documents our fundraising process to provide guidance to KSC members and other relevant student groups. ## Florida Space Grant Consortium (FSGC) {% hint style="info" %} This information is specific to Florida. Information on your local Space Grant Consortium can be found on [NASA's Website](https://www.nasa.gov/learning-resources/national-space-grant-college-and-fellowship-project/consortium-directors). {% endhint %} FSGC has several [grant opportunities](https://floridaspacegrant.org/programs/higher-education/), but two are particularly relevant to KSC. The [Student Club Project Grant](https://floridaspacegrant.org/program/student-club-projects/) offers financial support for projects, and the [Student Travel Grant](https://floridaspacegrant.org/program/student-travel-grant/) offers financial support for students traveling to present a paper or poster at a conference. FSGC funding is offered on a first come first serve basis so the sooner you apply the more likely FSGC will be able to accommodate your request. All requests must go through your institution's Sponsored Research Office so you need to work with faculty in order to apply for grants. If you think you qualify for an FSGC grant the best thing to do is contact the director, currently [Dr. Jaydeep Mukherjee](mailto:jaydeep.mukherjee@ucf.edu), and work with him to ensure you have the best chance at getting funding. ### Student Club Project Grant {% hint style="warning" %} KSC is in the process of applying for this opportunity. More information will be published once completed. {% endhint %} ### Student Travel Grant {% hint style="warning" %} KSC has yet to apply for this opportunity. {% endhint %} ## UCF Student Government (SG) SG offers several avenues for Registered Student Organizations (RSOs) to receive funding for their activities. SG requires applicants to have undergone [Financial Training](https://asf.sdes.ucf.edu/training/) which explains the details for different types of funding. Overviews of the opportunities here will be provided but the training will go into detail on current procedures. All funding comes in two forms: allocations and bills. Allocations are dispersed by the relevant committee within SG and have specific limits on the amount of funding available. RSOs can only receive $4,500 (2024-2025) across all allocations each Fiscal Year. If an individual request exceeds twice the allocation limit, it might be advantageous to try for a bill. Bills have much higher limits but only cover 50% of the expenses (which is why they only make sense at 2x the allocation limit) and must be voted on by the SG Legislative Branch making them a much more arduous process. ### Financial Allocation for Organizations (FAO) Allocations {% hint style="warning" %} KSC has yet to apply for this opportunity. {% endhint %} RSOs are eligible for funding to produce promotional items that are given away. FAO funded promotional item designs must include "Funded by SG" (or similar) and be approved. FAO funded promotional items must be available to all UCF students, not just club members, and should be relatively cheap; production of individual items that cost more than $15 require special justification. An RSO can receive up to $800 in FAO funding each Fiscal Year. ### Conference, Registration, and Travel (CRT) Allocations {% hint style="success" %} KSC has previously used CRT Allocations to support travel to the SmallSat Education conference. {% endhint %} RSOs are eligible for funding to support student travel. Different amounts of money are available depending on the event type. Each type may also have additional requirements or funding opportunities. | Travel Type | Max Funding (2024-2025) | | --------------------------- | ----------------------- | | Research Presentation Trip | $1,500-$3,000 | | Observational Research Trip | $2,500 | | Competition Trip | $2,500 | | Seminar/Networking Trip | $1,500 | | Service Trip | $2,500 | The process for applying and receiving CRT funds is roughly as follows: 1. Apply on KnightConnect 2. Wait for email from CRT Chair 3. Attend CRT Meeting and explain trip to the committee 4. If approved, fill out [Funding Forms](https://asf.sdes.ucf.edu/forms/) 5. Work with A\&SF Office to coordinate funding and purchases If all steps are completed correctly, the CRT Committee will likely approve your request unless they run out of funds. Apply sooner rather than later to allow time for any problems to be worked out and to ensure SG will still have the funding to support you. ## Sponsorships Sponsorships from local and relevant businesses offer a very powerful fundraising avenue. Some larger businesses have a specific sponsorship process, but working with most smaller companies usually means knowing for finding out who to contact. Direct connections such as friends or family working for a business are great places to start. Some companies may be able to offer discounted goods or services with an in-kind sponsorship. When reaching out to a company, explain why that specific company should sponsor you. This is especially effective for in-kind sponsorships from relevant companies, but all requests should be tailored. Be sure to mention the 501(c)(3) status and that KSC is a student-led organization. Explain briefly what KSC does and link to our website. Queries to general inboxes are less effective than messages to specific people. LinkedIn can be useful to find specific people in a company such as recruiters or public relations who might be able to help. ### Blue Origin {% hint style="success" %} We are happy to report that Blue Origin has sponsored KSC in 2025! {% endhint %} Blue Origin provides annual sponsorships of $1,000 to $3,000 to support student engineering teams and projects. Blue also provides technical mentorship to the teams it partners with. Applications are by invitation only; reach out to [Blue Origin University Relations](mailto:u@blueorigin.com) for more information. # Templates ## Weekly Project Updates Template ### Week of Month Date, Year The Project Goals this week were: * Goal 1 * Goal 2 * Goal 3 #### Project Meeting MM/DD/YYYY Tasks Completed this meeting: * Task 1 * Task 2 * Task 3 Other Notable Achievements: * Achievement Project Timeline Update: Insert Pictures/Videos Date:  9/16/25 * The Tethered-Sat 2A team held its first project meeting to discuss deployment mechanisms for the satellite. The group initially considered using a drone system, either mounted on the side or bottom of the satellite and released through a servo-activated trapdoor, with a potential housing size of 2U to accommodate the design. After discussion, the team decided to move forward with a guided parafoil deployment system. Unlike a passive parachute, this system will incorporate mechanisms to create controlled swaying, enabling remote steering during descent. * Cameras and altitude sensors will be included, along with a spring-loaded parafoil release system, though the exact deployment method is still under consideration. * To organize the project, four subsystem teams were established: Communications, focusing on aviation and camera integration; Mechanical, covering motors, servos, and CAD design; Guided Parafoil, responsible for motorized control of the parafoil; and a separation system team, tasked with developing a scissor-like snipping mechanism mounted separately from the 2U satellite but attached to the balloon, ensuring the satellite functions independently once released. Date: 9/18/25 * Through this Tethered-Sat 2A team meeting there was progress in the discussions on what would be the final product as was mentioned in the previous meeting on a goal that wanted to be achieved. With the design continue being a 2U satellite. * With the bottom 1U part being where two cameras will be mounted, with one of the cameras being directly on the bottom panel facing and the second one being mounted on the one of the side panels. With the opposing panel having a customized structured side panel wall that will have trusses formation to hold the PCB stack that will be used. Allowing for quick and easy insertion of the PCB stack there will be slidable rail attachment to the structured walls. * Focusing on the PCB stack itself, the first layer will contain all the modules that will be used from; ESP32, SD module, camera module, power distributor, and ready-to-launch switch. With the second layer being more focused on the power distribution and the direct to PCB terminal connectors. Such as connectors for the battery packs, servomotors, and cameras. Finally, with the final and third layer to this stack not actually being a PCB itself but inside a 3D-printed panel that will have aligned holes to stay connected to the stack. Which will be used as the mounting point for all the battery packs that will be used., allowing all the electronic components to stay as close as possible. * Leaving 1U of the space of the satellite to be used for the control system of the parafoil. Which will be working by a horizontal like reel system powered by a servo which will be connected to a couple of the strings on the parafoil to allow sway to happen for a controlled guidance. With the other strings being attached to the top of the satellite through the top panel and its mounting points that will be used for stabilization. * While the reeling system will only take-up to 0.5U of the free space, all other space will be equipped by the spring-loaded system that will allow the parafoil to pop out deploy. The scissor-like snipping mechanism stayed the same as the past meeting. Without any change to the design. *** # Themes