The SF-HAB group got together on Sunday 8 Feb 2025 and flew a bursting high-altitude balloon. This was a quick follow-on to Launch 3, which happened just before Christmas 2024.

Preflight Planning Meeting

The team got together on Zoom before the launch, to discuss what payloads we wanted to fly and find available dates. We targeted a Jan 25th launch. However, the weather wasn't looking good, and also that weekend was Winter Field Day, so it was decided to push the launch back by a two weeks.

The week before the launch I kept running flight predictions for Sat Feb 8th. The early week predictions weren't good, but by Thursday the upper-atmosphere winds had slowed considerably and the predictions showed the balloon landing about 12 miles east of Stockton. Not great, but not bad either. We decided to launch.

We flew seven payloads on this flight. From the balloon (top) end:

• Parachute
• Two 900 MHz Meshtastic Nodes
• 431.05 MHz Reprogrammed Vaisala RS41 Radiosonde
• 433.775 MHz LoRa Tracker
• 144.39 MHz APRS Tracker
• GoPro Camera
• VHF/UHF Cross-band Repeater

Balloon Assembly, Filling, and Launch

The team arrived at Cesar Chavez Park in the Berkeley Marina at 9:30am and immediately started turning on the payloads and assembling the flight train. The sunny and windless day was a great respite from the previous stormy week.

Unfortunately, most of the payloads had problems when we turned them on:

• My Horus tracking laptop kept going to sleep and dropping network connections. The balloon payload was transmitting normally.
• The LoRa ground stations were out of range of their local internet hotspot. This caused them not to report the location of the balloon to the internet, which was interpreted as an RF problem. The ground station receivers were reprogrammed several times.
• The cross-band repeater was programmed for different downlink frequency that we had advertised. Instead of changing the repeater, we reprogrammed all of our ground radios to accommodate this new frequency.
• The secondary camera reported that the SD card wasn't formatted properly. We reformatted the SD card several times, but it still didn't work. We removed this payload.
• The two Meshtastic payloads worked well.

After debugging all of these problems for about an hour, we started unrolling and filling up the 1500-gram Kaymont balloon.

Using the Sondehub Burst Calculator, we calculated that we would need ~3.2 kg of neck lift for the balloon to burst at 33k meters. We didn't want to underfill the balloon and have it burst much higher than 33k meters, because the predictions showed that the higher we went, the further east we would fly. Going further east would push us away from the farmland and into the Sierra Nevada foothills, where it's more difficult to recover the payload. We used a analog scale to measure the neck lift.

We had a K-sized 200 cubic foot cylinder of hydrogen. The burst calculator showed we should fill the balloon with 163 cubic ft of gas, which is almost the entire tank. Unfortunately, the calculation above was made with helium as the lifting gas. Using hydrogen in the calculation, we should have filled the balloon to a neck lift of 3.6 kg.

Unlike the previous launch, the actual filling of the balloon went very smoothly. Robert K6RGG was the safety tank shutoff person, ready to turn the valve if another hose disconnect occurred.

After tying the balloon onto the (already assembled and tested) flight line, we walked away from trees, gently raised the train, and released.

Launch happened at 1841 UTC, with landing at 2058 UTC, for a flight time of 137 minutes.

Robert K6RGG took a (silent) video of the balloon filling and launch:

Mobile Tracking Station

After the previous launch, I upgraded my mobile tracking station with a Raspberry Pi.

However, I didn't thoroughly test the new system at home before the launch. I found a Linux networking misconfiguration where after 5 minutes the routes would change and the direct ethernet cable between the Raspberry Pi and the laptop would stop. Later I learned that this networking misconfiguration also prevented Horus and APRS packets from being uploaded to Amateur Sondehub.

Tracking the Balloon

This balloon had 3 tracker payloads:

• KF6ZEO was the reprogrammed RS41 tracker, being received by my chase vehicle (but not uploaded to Sondehub Amateur). This tracker was also being received by my home station in San Francisco, and these packets were uploaded directly to Amateur Sondehub.
• AG6NS-11 was the APRS tracker. It was being received by many terrestrial IGates, with packets being uploaded to the APRS servers then being scraped by the Sondehub APRS gateway for posting on Sondehub Amateur.
• K6ATV-7 was the LoRa tracker. Terrestrial receivers upload packets to APRS-IS, which then gets scraped by the Sondehub APRS gateway service and posted to Sondehub Amateur.

All three of these payloads were being shown on the Sondehub Amateur website, which made it seem like there was three separate balloons flying very close to each other.

The live Horus Binary telemetry from my mobile tracking station showed real-time predictions of where it was going to land. This was much more up-to-date than the Sondehub Amateur webpage. This screenshot here is from Chasemapper, showing the last packet being received 10 seconds ago, the car position update 0.5 seconds ago, the last (offline) prediction was run 4.5 seconds ago, with 22 minutes until predicted landing.

Interestingly enough, both the Sondehub Amateur webpage and Chasemapper had extremely accurate predicted landing locations (within 2 miles) soon after balloon burst. So I guess the lesson learned here is just head to the predicted landing location as fast as possible and try to watch it fall!

Landing

The balloon landed in a field about 500 meters west of a prison at 2059 UTC. Walter K6ATV and Ben KO6CNT arrived there a few minutes after it had landed, entirely based on the Sondehub Amateur predictions. I was only 10 minutes behind Walter, and Martin W6MRR arrived shortly thereafter.

The field was a bit muddy from the rains the previous week. Interestingly, most of the latex balloon was still attached and wrapped up in the payload train. The parachute was closed and tangled in the balloon. I should have realized something was wrong as the payloads were falling to the ground much faster than anticipated with a parachute. After arriving home, Martin measured that ~1 kg of of the 1.2 kg of latex was still attached.

The recovery team consisted of Martin W6MRR, Walter K6ATV, Ben KO6CNT, Taz Kano, and Bryan KF6ZEO. Afterwards recovery, we met at a local pizza restaurant, viewed the GoPro video, and planned the next launch.

Reprogrammed RS41 Flight Results (KF6ZEO)

I made several changes to the RS41ng payload that I flew on the last launch. Randy KQ6RS recommended lengthening the stock RS41 antenna to 16.3 centimeters for a better match at 430 MHz.

I also increased the transmit power in the config.h file to 6, which is 17dBm or about 50 mW. I set the transmit period to "continuous," which is about every 10 seconds.

The RS41 transmitter was the most reliable, transmitting ~805 packets during the flight. 760 of those packets (94%) were received by my mobile tracking station KF6ZEO-H3, with just a 1/4 wave mag mount on the trunk. However, only 131 of these packets (17%) were uploaded to Sondehub Amateur due to the networking misconfiguration in the car.

Starting at 131 meters altitude (only 2 packets after launch), my home station KF6ZEO-H2 started receiving the balloon. This station has a Diamond X-50NA 5/8 wave antenna, ~40 ft of LMR-400, and a RTL-SDR Blog v3. This station kept receiving until the tracker fell below 2,127 meters on the way down (Mountain height and trigonometry calculated I should have seen the transmitter down to 1,379 meters altitude). My home station received a total of 652 packets, which was 83% of the packets transmitted during this period.

Once again, the Horus Binary receivers near San Diego started picking up the balloon when it rose above 29,112 meters. A total of 51 packets were uploaded by these stations to the Sondehub Amateur database, but most of these packets were duplicates of packets received in the Bay Area.

This Sondehub Amateur grafana dashboard has more RF information from this RS41 tracker. I screenshotted a few graphs here for posterity:

Maximum altitude as reported by this tracker was 32,942 meters (~108k feet) at 20:19 UTC.

Zooming in on just the ascent rate, there does appear to be a noticeable reduction in rate by at least 1 meter/second at 1909 UTC around 11,000 meters altitude. I have no idea what this could be.

As far as I know, all of the Horus Binary receivers are using the "official" RTL-SDR Blog v3 dongles. Maximum frequency difference between all of the receivers is about 1.5 kHz, which over 431 MHz is approximatley 3.5 PPM. Not quite the 1 PPM they advertise! The biggest outlier was my home station KF6ZEO-H2.

Payload speed was maximum 171 kph (~106 MPH) at 11,600 meters altitude.

APRS Flight Results (AG6NS-11)

Packed in a styrofoam RS41 case, Kazu AG6NS flew his Raspberry Pi RP2040 tracker again. While this can do HF WSPR transmissions, this one was programmed for 144.390 MHz APRS. Three Energizer lithium batteries provided the power source.

This tracker transmitted every 2 minutes, for a total of ~68 packets transmitted. A total of 56 packets (82%) were received by the APRS-IS ground network, but that included 15 packets when the balloon was on the ground before launch.

The highest packet received was 31,835 meters (~104k feet).

Interestingly, for the first 10 minutes (5 packets) of flight, the altitude reported by this tracker was a decreasing negative number. Negative altitudes are perfectly normal within the GPS world, this just signifies that the GPS receiver is below the WGS84 ellipsoid.

This happens all the time, as the WGS84 ellipsoid is an approximation of the earth's surface, not the geoid (mean sea level). Here in the Bay Area, the WGS84 ellipsoid is about 33 meters above the geoid, which means that raw GPS altitude is -33 meters on the beach. Most receivers nowadays apply another correction to raw GPS altitude to give you a more accurate altitude.

If you look at these negative altitudes a bit deeper and take an absolute value of the reported altitude, you see that the GPS receiver was probably providing good altitude. But whatever code the RP2040 uses was still applying a negative sign to the altitude.

It does appear that the GPS got stuck for frames 24 and 25, as the lat/long/alt were all the same as frame 23. By frame 26, whatever the problem was had fixed itself, and the position reports for the rest of the flight were accurate. Only 5 packets were received after balloon burst, with the last packet received at 4,200 meters altitude. Check out this Sondehub Amateur grafana dashboard for more data from this payload.

LoRa Flight Results (K6ATV-7)

Also packaged in a styrofoam RS41 case, Walter K6ATV provided a Ebyte E77 module, which has a Semtech SX1262 LoRa chip in the STM microcontroller. He modified the firmware to put the ublox GPS in dynamic mode, which allows lock up to 50k meters.

The LoRa tracker transmitted +22 dBm (~150 mW) at 433.775 MHz into a 1/4 wave ground plane antenna. Transmission period was every 2 minutes, for a total of ~68 packets transmitted. A total of 35 packets (51%) were received on the ground. In the Bay Area, there were only 5 stations on the ground that received this balloon, including one station at Walter's house and two stations in his car.

The furthest LoRa packet received was by the "BALLPT-10" station in Klamath Falls, Oregon. The balloon was 315 mi (~500 km) away from the receiver up at 26,966 meters altitude. Interestingly, only one packet was received by this station.

Check out this Sondehub Amateur grafana dashboard for more information about this payload. You can also see the active LoRa receive stations on this map

The highest packet received was 32,706 meters (107.3k feet).

Meshtastic Flight Results

Ben KO6CNT flew two meshtastic payloads. The same Sensecap T1000e that flew on Flight 3 was flown again, with the 10k meter elevation limit on the GPS. This unit provided packet forwarding among the Bay Area and Sacramento mesh nodes.

To transmit valid position reports above 10k meters, a new Rak wireless 4631 with modified fimrware was also flown. This Meshtastic node is based around the same Semtech SX1262 chip as in the LoRa transmitter payload, with +22 dBm (~150 mW) transmit power at 915 MHz. This GPS was tested with a GPS simulator and a HackRF up to 50k meters altitude before flight.

The beacon transmitted every 30 seconds, for a total of ~274 packets transmitted during flight. A total of 151 packets (55%) were received by ground nodes and uploaded to the Meshtastic MQTT servers, plus an additional 121 packets that were duplicates. The highest Meshtastic packet received was 32,893 meters (~107.9k feet), which was only 49 meters lower than the highest Horus Binary packet received.

GoPro Camera Results

We had enough lift this time to fly the GoPro camera. The second camera's SD card had problems and was not being read by the camera after it was reformatted several times just before launch, so we decided to remove this payload from the flight.

This camera captured ~115 Gbytes of video from the 2.5 hour flight. We got good images of the launch site and the East Bay on the way up. Looking closely at the the cross-band antennas just after release, one can see a dangling coax cable. It's not clear which antenna it's from, but regardless, this was probably the cause of the poor cross-band repeater performance.

Unfortunately, the GoPro camera was set to auto-focus. For most of the flight, it was focused on the payload string or the cross-band repeater antennas, not the earth below. So most of the pics were out of focus! This pic was taken at around 32,900 meters (~108k feet) only a few seconds before balloon burst. The San Francisco Bay is visible on the far right side, with Suisun Bay on the bottom.

After the balloon burst, we could clearly see the VHF and UHF cross-band repeater antennas flailing around as everything quickly fell to the earth.

Here's a highlights video from the GoPro that Benjamin KO6CNT put together:

Crossband Repeater Flight Results

On our previous flight, the custom cross-band repeater didn't really work. Testing on the ground before launch was fine, but as the balloon ascended higher, the TX power kept dropping out after a second or two, with no audio being passed.

Based on this result and benchtop testing done after the flight, Martin W6MRR suspected that the transmitting NiceRF SA828 was desensing the receiver module due to insufficient filtering. Martin added a Minicircuits RLP-137+ low-pass filter on the output of the 145 MHz transmitter. This filter was physically located on the cross-band repeater.

Additionally, he added a Minicircuits BHP-400+ high-pass filter on the UHF receive side. This filter was physically located on the 440 MHz antenna, and can be seen on the pics below. Martin also separated out the antennas on the flight line, with about 4 ft of separation between the 1/4 wave ground plane antennas.

For this flight, the cross-band repeater worked better than the first time. We were able to have good comms through the repeater for 20 minutes or so, before the signal became too weak to hear. Several other non-chase amateur radio operators were able to use the repeater, and we didn't have any of the audio quality issues from the first flight.

After landing, we saw that the coaxial cables feeding the antennas had become disconnected from the antennas. Looking at the (blurry) GoPro video, we were able to determine that the coax cables pulled away from the antenna connectors during launch. The green flight line was taped to the coax cables without any slack at the connector, so holding the flight line/coax during balloon release probably pulled the coax out of the connector.

So this was probably the reason for the repeater failing early in the flight. It was surprising that it even worked at all after launch! For future flights, we will look at using different antenna, adding more slack to the coax cables, and increasing the TX power to 1.5 watts from 0.5 watts.

Lessons Learned

After recovering the payload, we had pizza nearby and discussed improvements for next time:

• We spent a lot of time getting all the payloads working. One hour was burned before we even started filling the balloon, and most of the frustrations could have been avoided if we had more thouroughly test our payloads and receive stations before the flight.
• Once we got the trackers working, it only took 10 minutes to fill, tie, and release the balloon. Great job team!
• I need to double-check all of the inputs on the Sondehub Burst Calculator webpage. The default is Helium for the lifting gas, but we were using Hydrogen. The neck lift difference was small, but every ounce counts!
• It took 10+ minutes to clean up the launch site after balloon release. Next time, some people could be cleaning up and packing as other people are preparing to release the balloon. Getting on the road quickly is important to get to the landing area as early as possible.
• The cross-band repeater electronics and coax/antennas need a bit more work to function reliably. It seems like we are very close to a good working solution. Maybe fly a J-pole or other more streamlined antenna.
• The GoPro camera was focused on the flight line, not the ground. Next time, either tilt the GoPro camera away from the flight line, somehow manually focus the camera at infinity, or put it on the bottom of the flight train. 115 GBytes of out-of-focus video is disappointing. Also consider reducing the video quality and/or frame rate to reduce file sizes.
• We had advertised a backup terrestrial repeater in case the cross-band repeater didn't work. But the terrestrial repeater didn't work either! After the launch, I found out that the transmit power was only 5 mW due to Pave Paws radar restrictions. Next time we can select another higher-power repeater, or change bands to 2 meters (although this would negate all the physical 440 MHz filters I had built). 446.5 MHz was a good alternative that we used at the launch and landing site.
• Ben KO6CNT also set up a voice channel on the Bay Area Meshtastic Discord server, allowing people not nearby to follow along with the launch. Consider doing this next launch. This voice channel is for the navigators (secondary person in the car), not for the drivers.