Keeping It Simple
In August of 2016 we decided to take a risk and put together a simple high altitude balloon. We’ve done this before with K2GXT in Rochester, NY on a scale taking months to design and build. Now we aimed to streamline the effort and increase the data collected by using Faraday. It’s important to note that we did not design Faraday for high altitude balloon use, this is simply one of many uses the radio has. Our goals were simple:
- Use only a Faraday node to complete the flight
- Program the firmware and software necessary to achieve a safe mission
- Invest minimal time and effort
The entire physical construction of this balloon payload took place on Saturday August 13th, 2016 exactly one day before driving out to the Bakersfield, CA area to launch Faraday. We purchased helium from a party supply store along with the balloons for flight. The entire avionics consisted of a Faraday radio with a 9V rechargeable Lithium-Ion battery stuffed inside an old deli meat Tupperware container with masking tape holding everything together. Simple. We did purchase a nice model rocket parachute for recovery, so we splurged a bit.
The night before launch we started construction of the payload and performed some preliminary tests. These tests were flawed as realized during the flight and noted later but did provide some useful information. The payload weighed a total of 133 grams which could have been reduced even more by using a streamer instead of a parachute and no Tupperware container.
We tested the parachute by simply putting some weights in the Tupperware container to equal 133 grams and promptly threw the package off our balcony to make sure the payload descent was safe under parachute. We wanted to make sure the descent could not obviously hurt anyone if it came down in a populated area.
It’s important to note that we did not design Faraday for high altitude balloon use, this is simply one of many uses the radio has
As discussed in the flight recap we will probably never use the hot-wire cut-down method again but our testing certainly showed that in theory it works well. Using the convenient high current MOSFET provided on the Faraday nodes made implementing a cut-down function easy. We have a special firmware application running on Faraday which governs the operation of the MOSFET channel. This program does not allow the channel to stay active for longer than a predefined time. This way we did not have to worry about turning off the MOSFET high current cut-down channel. This not only prevents a fire from starting but also helps prevent power supply brown-out.
To comply with the FAA FAR-101 rules we used 30lb test fishing line to connect the payload to the balloons. This meant we could melt the plastic with the ni-chrome but any plane or object hitting the balloon in flight would easily separate the payload from the balloons. Additionally, several mylar balloons were placed with the bright orange latex balloons in order to help reflect radar signals.
Sunday August 14th, 2016 was the day we decided to drive several hours north towards Bakersfield, CA from Redondo Beach, CA and launch Faraday. We ended up stopping in Buttonwillow, CA next to an orange grove. It was a 105°F day with clear skies and a strong unforgiving sun. The launch location was unobstructed and far from any nearby airports we knew were present.
The goal was not to launch and recover the payload. The data Faraday would send back was our goal. We’ve never seen another balloon flight that had 1Hz RF telemetry. That’s right, we have data from the flight at one second intervals. Extremely detailed. The heat was unexpectedly challenging as it was also severally going to affect the lift of our helium. During the filling of balloons we ran out of helium and were still negatively bouyant. This prompted an emergency trip to Wal-Mart in Wasco, CA where two more helium canisters were purchased just in-case.
We made a crucial mistake. There was one fishing line per balloon. The testing of our cut-down mechanism only consisted of one 30lb fishing line. We had never tested this but decided to take the risk and launch anyways. We wanted data, not the balloon. In the end this was the mistake that cost us the recovery of the payload. Worth it.
We launched the balloon at 1:30PM. Just after letting go of the balloons a driver passing by stopped to asked “…was that a weather balloon?…So neat!”. We’re assuming Californian farmers don’t see many scientific balloon launches! As shown above there were numerous balloons used to lift this payload up and we left the red parachute simply hanging down.
The payload immediately blew south prompting us to drive south a few miles before turning around when we realized it had reverse coarse to fly north. we drove back north chasing the balloon, stopping every few miles to step out and look for it. California is great. Not only was the weather great and land flat but the roads out here are rectangular. Navigation was a cinch. We followed the balloon northeast eventually turning east heading straight for the Greenhorn Mountains in the Sequoia National Park.
During the flight we had a Faraday radio attached to a computer paired with an iPhone to provide internet access. This setup sent a GPS position and telemetry packet to the APRS-IS system once every 60 seconds. This meant that to the APRS-IS system we were just like every other APRS station, however, we were really on 915MHz and obtaining 1Hz telemetry! The APRS packets were configured to request that they never be repeated over RF to avoid congestion on the APRS network. Unfortunately APRS-IS and APRS.fi throw out packets if they are arriving too fast, which 60 second intervals can qualify as, so the data is fragmented and we lost all APRS-IS coverage when we drove into the mountains as we lost cell phone coverage.
This is an important concept to realize. Faraday is designed to interface the world at the network interface. Data is data. We bridged services seamlessly by writing simply Python scripts to move data from Faraday SQLite logs into the APRS-IS system. We envision a future were systems with different protocols play nicely over the network interface. No more exclusion from digital networks simply because you don’t own a specific radio.
The payload was following Route 155 into the mountains so we pursued until we past Glennville, CA. We decided to pull over to a safe area of the road and record telemetry until we lost it. This was the decision because the payload veered north and we were miles from any road that traveled north. Faraday was lost. The last data point came in just prior to the payload disappearing behind a mountain from our vantage point.
We lost the payload because one or more balloons popped but not all which caused a slow descent. Coupling this scenario with the multiple strands of fishing line failing to cut meant we watched as the payload helplessly descended into the mountains.
We did achieve the goal of remote commanding the payload in-flight. A timer counted up until it hit two hours at which point a cut-down was set to automatically fire. This guaranteed we would attempt to cut-down even if RF communications were lost. Minutes prior to cut-down we reset the time from the ground, verifying remote command functionality and then confirmed a commanded disabled of the automatic cut-down timer. We then sent commands to cut-down manually. All commands were received by the payload because our timer indicated it had reset and the state machine indicated we had fired the MOSFET only after the manual attempt.
Minutes prior to cut-down we reset the time from the ground, verifying remote command functionality and then confirmed a commanded disabled of the automatic cut-down timer.
We were stoked. Sad to see a PCBA that helped us build our ideas for nearly a year go away but vindicated by the quality of the data. Ham radio rarely gets to be a part of such high-fidelity data. This data helped us understand the flight, root cause the reason we lost the payload, and make some beautiful maps/graphs. Here is a zip file containing the exported KML data from the Faraday access point SQLite database.
All data was received over the 33cm ham band with Faraday radios at both ends
- Maximum Altitude = 9,691 meters (31,795 feet)
- Flight Path Ground Distance = 185 km (115 miles)
- Maximum Horizontal Speed = 57.6 kmh @ 8,900 meters (35.8 mph @ 29,200 feet)
- Flight Duration (lost communications) = 3 Hours 12 Minutes
As mentioned before, the cut-down mechanism failed. We know exactly why it failed because we have 1Hz data. In retrospect we never would have determined the root cause without such high fidelity data. Several nylon fishing lines were passed through the ni-chrome cut-down device which we had not tested. This was a large area to melt and we only kept the MOSFET on for four seconds at a time.
We know exactly why it failed because we have 1Hz data.
Faraday firmware carried with it a state machine written as an example firmware application which indicated the following information to us:
- Cut-down has never occurred (0)
- Cut-down occurring (1)
- Cut-down has occurred (255)
As shown in the graph above, we see the battery voltage in blue and the cut-down state machine in orange. The state machine clearly indicated we attempted to cut-down several times. Correlated with these events are dips in battery voltage. Ohms Law comes in for the save! The MOSFET conducts nearly 1A into to ni-chrome causing the internal battery resistance to drop voltage. These events lasted only 4 seconds. We also know that descent started prior to any cut-down command due to plotting the cut-down events with altitude. This confirmed that a balloon popped and we did not cut any balloons away since no observable change in descent rate occurred after cut-down.
- High rate data let us see current draw during fire commands
- Confirmed ni-chrome wire present and conducting electricity
- Payload descent started prior to any cut-down commands
- Confirmed RF commands received by Faraday to attempt multiple cut-downs
Since we know high-current events occurred we know the wire was present and therefore know that the nylon fishing line never melted. Faraday 1Hz data let us root-cause the failure. The APRS system considers a position packet every 60 seconds to be high-rate which would have resulted in us never knowing if the ni-chrome was present.
Faraday Wireless Radio
FaradayRF enables radio amateurs to learn about digital radios, experiment with them, and accomplish awesome projects utilizing ham radio as a medium for learning and communications.
Author: Bryce Salmi
Licensed radio amateur KB1LQC and Co-Founder of FaradayRF. Professional Electrical Engineer designing and building avionics for rockets and spacecraft during the day and developing the future of digital amateur radio experimentation by night. All opinions are my own.