On Sunday 15 December 2024 the SF-HAB group got together and flew a bursting high-altitude balloon. We had a whole crew there, including Martin W6MRR, Kazu AG6NS, Robert K6RGG, John NI6D, Walter K6ATV, Benjamin KO6CNT, and Steve K6WW. Everyone helped out with assembling the payload train, filling the balloon, or documenting the launch.
Preflight Planning
The days before the flight we had an atmospheric river in the Pacific Northwest, so the upper winds were very unsettled. The lower-level winds were also blowing all different directions, and it rained significantly the day before. But the weather forecast for launch day was clear and sunny, and the Sondehub predictions showed a general Southeast flight. We picked Walnut Creek as the launch location to have our balloon land on the eastern side of the Central Valley
Balloon Assembly and Filling
The launch site was at a local park in Walnut Creek, and we met at 9:30am on a very cool and cloudy day. There was no wind at all. The balloon was a standard Kaymont 1500 gram filled with hydrogen.
Unfortunately, during balloon filling, the fill hose connecting the regulator to the balloon filling tube disconnected. About half of the tank of hydrogen was lost before the leak was stopped. We continued filling the balloon after reconnecting the hose, but the damage was done.
High-altitude bursting balloons typically target a 5 meters/second ascent rate. This gets the balloon from the surface up to burst altitude in about 2 hours, then another 1 hour or so to fall back to the ground (without a parachute).
Balloons that are under filled with lifting gas (such as our balloon) rise slower than the desired 5 meters/sec ascent rate, and also burst at a higher altitude. Slower rise also means they travel slower through the wind layers of the atmosphere, and are pushed further from the launch site. Using the Sondehub Ascent Calculator you can punch in payload mass and predict your ascent rate and burst altitude.
After assessing our options after the loss of hydrogen and running the numbers based on our measured 1 kg of free lift, we made a game-time decision: We would remove any heavy payloads, and assume that we would not get the balloon back. Since we probably weren't going to get the balloon or payloads back, most of the team decided not to chase the balloon. I decided to drive to the top of the Altamont Pass on Highway 580, which overlooks the Central Valley. Launch was very easy because there was no wind.
The payloads were connected to the balloon with neon green twine, each separated by five to ten feet from the other payloads. Starting from the balloon (top of the train), here are the payloads that we flew:
Meshtastic
Meshtastic is a open-source network project that uses inexpensive LoRA radios as a mesh network, providing long-range off grid messaging. Benjamin KO6CNT provided a Seeedstudio Sensecap T1000e node, which also contains a GPS in addition to the LoRA hardware. It was programmed to transmit its location to any other nodes every 30 seconds on 906.875 MHz.
Unfortunately, the integrated Mediateks AG3335 GPS receiver has a maximum elevation of 18 km, and the main processor won't transmit valid locations when the device is above 10k meters elevation. So this mesh device will transmit stale locations above 33k feet, which is not ideal for a high-altitude balloon. Once it falls below 10k meters it should resume beaconing its accurate position.
Reprogrammed RS41
I provided the reprogrammed RS41 radiosonde on amateur radio frequencies. Dial frequency was 431.050 MHz, transmitting the Horus Binary v2 modulation every 10 seconds with +14 dBm of power (~25 mW). This reprogrammed RS41 worked well throughout the flight.
APRS Transmitter (and GoPro Cameras)
Kazu AG6NS provided his Raspberry Pi RP2040 HAB tracker, which is an ultralight picoballoon tracker designed for HF WSPR transmissions. For this flight, the tracker was programmed to transmit regular 1200 baud APRS on 144.39 MHz with a dipole antenna.
The original plan was to have two GoPro cameras inside this insulated lunch box, recording hi-def video during the entire flight. But because of the hydrogen leak, we knew we probably wouldn't get the balloon back, so the two GoPro cameras were removed. The APRS transmitter was working on the ground before launch, but it failed around the release time. No APRS packets were received by the APRS-IS network during flight.
Cross-Band Repeater
Down at the bottom of the payload train, Martin W6MRR provided a FM cross-band repeater for communications between the chase team during the flight. It's based on two NiceRF SA818 modules, which are the same RF modules as are inside all of the various cheap Chinese handie-talkie radios. Two modules, one for VHF and one for UHF, are mounted to a small custom PCB which powers the modules and connects the carrier sense to the PTT line.
Uplink frequency was 445.525 MHz tone 162.2 Hz, and the downlink frequency was 145.250 MHz. Unfortunately, the downlink frequency was in the FM repeater allocation, and it just happened that this is the same frequency as the NASA Ames repeater in the Bay Area, so there was some interference when that repeater was in use. If we had chased the balloon into the Central Valley, there was another repeater output on this frequency above Fresno that would have jammed us as well.
This cross-band repeater worked on the ground when the transmitters and receivers were nearby, but very quickly stopped working after liftoff. Bits of audio came through the repeater every once in a while, but it seemed like the downlink transmitter was shutting itself off every few seconds. Maybe that was due to a low battery, or self-interference, or some a PTT issue.
Mobile Chase System
The mobile chase hardware I used is very similar to the setup used to chase radiosondes. Just a RTL-SDR dongle and a laptop.
For software, I ran horusdemodlib for demodulating the Horus Binary v2 signal from the reprogrammed RS41. In addition, I ran chasemapper in a docker container for tracking my car and uploading my position to Sondehub.
At the beginning of the chase, I ran the Horus GUI software, but as the balloon rose higher this setup stopped decoding the balloon. I'm not sure why, but I suspect the SDR++ front end receiver was misconfigured. The callsign for this setup was KF6ZEO-H1.
Towards the end of the flight, I switched from Horus GUI to the headless horusdemodlib version, and this was able to receive packets from the balloon on the way down. The callsign for this setup was KF6ZEO-H3.
Horus Binary Receiving Stations
In addition to the mobile receiving station in my vehicle, I also contacted the Mt. Carmel High School Amateur Radio Club (W6SUN) down in San Diego. David WD6DRI and Randy KQ6RS have flown many reprogrammed radiosondes as a part of their STEM curriculum, and provided valuable advice for programming and reflying radiosondes.
W6SUN has several high-level receiving sites around San Diego. Each site has several Raspberry Pis and RTL-SDR dongles, and can be configured either for receiving radiosondes or Horus Binary transmitters. The amateur radio operators down in San Diego activated three Horus Binary receive stations for this launch:
- W6SUN-Toro has four Raspberry Pis and seven RTL-SDR dongles on Toro Peak at 8,717 ft (2,657 meters) in elevation. This site is about 20 miles south of Palm Springs and 400 miles (~650 km) from the flight center point.
- W6SUN-Otay is at an elevation of 3,568 ft (1,088 meters) on the top of Otay Mountain. The station there consists of two Raspberry Pis with three RTL-SDR dongles each. This mountain is just outside of San Diego, only 2.5 miles (~4 km) north of the Mexican border, and 430 miles (700 km) from the flight center point.
- Randy KQ6RS pointed his 7-element yagi towards the northwest.
Of the approximate 907 packets transmitted by the reprogrammed radiosonde between launch and last packet received at 11,196 meters elevation, 801 were received by at least one of the stations. When the balloon was up at altitude, many of the transmitted packets were received by multiple stations, and one packet was received by all 5 stations!
This table shows the number of packets received per station, but it's a bit misleading because the stations down by San Diego were blocked by the earth until the balloon rose above ~26,000 meters. Additionally, KF6ZEO-H1 was a Horus GUI station and really only worked for the first few minutes after launch, and KF6ZEO-H3 was active only for the last 15 minutes before landing.
Horus Flight Results
The balloon was launched at 10:45am on Sunday Dec 15th 2024 (1845 UTC). A total of 907 packets were transmitted (every 10 seconds) from launch until last packet received, which was at 1:18:53 PST (2118 UTC) at 11,196 meters elevation above Yosemite National Park. A total of 801 Horus packets (88%) were received by at least one station, which is pretty amazing to me. The total flight distance was 115 mi (185 km), and the flight path went southeast from the launch location
Tracking of the balloon on the Sondehub Amateur page was great, as it fuses all of the receive and mobile tracking stations together on a single map.
The last packet received by a Horus receive station was at 11,196 meters, and it's really difficult to estimate the descent rate for the last few minutes of the flight. At 11,000 meters elevation it was falling at ~30 meters/second, but the air is much thinner, so it would have taken a lot longer than ~6 minutes to fall the final distance.
Meshtastic Flight Results
Additionally, the Meshtastic payload from Benjamin KO6CNT worked quite well until the balloon burst. Position data above 10k meters (~33k feet) was wrong, but the network did receive 242 packets from the balloon above 10k meters. The Seeedstudio Sensecap T1000e was heard all around the Bay Area, all the way up to Fairfield. The node transmitted every 30 seconds, and approximately 321 packets were transmitted in flight. Multiple stations heard each packet, so 431 packets were forwarded to the central MQTT server.
After balloon burst, the node was heard only once as it fell above the Sierras. The lack of received packets was probably due to the dearth of nodes in the Sierra foothills, and maybe the GPS not getting lock during the fall? Ben contacted another Meshtastic user on the Bay Area Meshtastic Discord server who was flying from the Bay Area to Denver on a commercial flight that evening, and agreed to put some radios in the window. He brought along a Meshtastic Mesh Device Station G2 and an WisMesh Pocket from Rak.
The hardware was on the correct side of the airplane, the radios were configured correctly, the balloon was not in a deep valley, the batteries weren't dead yet, and it seemed like the communication gods smiled on the harebrained scheme, because the Meshtastic node on the balloon was able to transmit several location packets to the airplane and the back to the Bay Area. Success, we knew where it landed!
The final landing location was only a half-mile from a dirt road along a creek. There was only ~2km (1.2 miles) of distance from the SondeHub predicted landing location to the actual landing location.
Recovery
After the final landing coordinates was obtained, the second call went out on the various Meshtastic discord groups: Who could go pick it up? The satellite images from that day showed no snow on the ground, and the weather for the next few days looked good.
Justin KM6CKK volunteered to drive out there the next day on Monday Dec 16th. He brought along some Meshtastic hardware, and was able to receive the payload when he got to the search area. The Sensecap T1000e battery was only at 53% after transmitting every 30 seconds for more than 24 hours. Plugging the coordinates into a Garmin GPS brought him directly to the landing site, although the bushes were quite thick and the terrain quite steep. Total door-to-door recovery time was 10 hours.
We were ecstatic that we got all of our hardware back, and we plan to fly again the near future.
Lessons Learned
There were many lessons learned during this flight, some of which I will repost here:
- Formalize balloon filling procedure, with a longer fill hose to get the balloon away from vehicles, a more easily accessible tank shutoff valve, and more people helping the process.
- Test all payloads the night before launch, and verify they are getting out to the various internet gateways.
- I needed to spend more time on my personal vehicle receiving station. It mostly worked, but the poor performance of Horus GUI needs to be debugged.
- Increase the transmit power of the RS41 tracker, and increase the beacon rate.
- Remove the all the National Weather Service stickers on the outside of the RS41 tracker. Justin though that it was an actual radiosonde and marked it as recovered on SondeHub.
- Verify that the APRS tracker is successfully getting packets out to the APRS-IS network before launch. Packets were heard locally, but not uploaded to be viewable on aprs.fi.
- Verify that the cross-band repeater is working at distance before the launch, and pick a different frequency for the cross-band repeater.
Acknowledgements
Special thanks for Martin W6MRR for organizing the launch, Mark VK5QI for continual improvements of the radiosonde_auto_rx and horus binary projects, Benjamin KO6CNT for providing the Meshtastic payload and interfacing with the various Mesh networking groups, and Justin KM6CKK for spending a day recovering the balloon.