A group of balloon enthusiasts at South Side Hackerspace: Chicago (SSH:C) are doing a series of launches studying the effects of solar maximum. These launches are a continuation of the Nationwide Eclipse Ballooning Project, a NASA funded program which is operated by Montana State University. The folks at SSH:C have launched balloons for the last few solar eclipses with NEBP and have also joined this project in the first half of 2025. It just so happens that for my fourth flight, Adam Kadzban from SSH:C took me up on the open invite to join the launch and we’ve kept needing about balloon launches since then (despite losing the payload!)
Launch track
This is my first HAB flight where I wasn’t responsible for the flight track! I knew roughly where we would be heading, but the overall payload weight and gas fill volume were someone else’s job. We launched from Willowhaven Park in Kankakee, IL – barely a tree in sight and a good launch location unless you are looking for a wind break to control the balloon while you fill (queue ominous music).
Our original flight track had us landing just north of the Michigan border somewhere between Dowagiac and Three Rivers. The flight path was expected to be long, the highways weren’t perfectly aligned so it would be about a 2.5 hour drive and a flight of about the same time.
It turns out we under-filled the balloon, due to a combination of missing a couple of weight measurements and likely due to the ground wind which was about 10mph. The balloon was moving around with the breeze and presumably we were getting some lift from the breeze. Instead of a typical 5m/s ascent we achieved about 3m/s which lengthened the flight path considerably. At one point the projection had us landing in Flint (I thought it was a joke!).
Burst was just over 30,900m and the landing was just north of Battle Creek, MI. The drive was about 3 hours and the flight was about 3.5 hours long; about an hour longer than expected. But – we made it!
SSH:C payloads
On board were a Stratotrack APRS tracker, a Spot satellite position beacon as a last resort, a DFM sonde running RS41ng with Horus 4FSK which performed brilliantly again, and an Insta360 camera. I got to add to the payload train – a first flight of a Wenet payload, and another Meshtastic node.
The best tracker on board was definitely the DFM with 4FSK. It was received by my home station at just over 1000m altitude from >50 miles away, and between my home station, my brothers station in Kalamazoo which we flew over, and my laptop, we had continuous high resolution telemetry throughout to just before landing.
The Stratotrack is cool as it’s APRS and there’s a variety of ground stations picking it up along the track. But the refresh rate naturally has to be rather low.
Tracking data:
The Insta360 camera footage is a blast to watch; unfortunately we only got ~1h of data as the secondary battery pack failed yet again…
Wenet payload
This is a new tracker, running a Wenet tracker that I threw together using a spare RFM98W from Uputronics that I bought years ago to build a LoRa / PITS SSDV tracker. I’m not happy with the GPS on USB-serial and I spent a few hours trying to get both of the Pi’s distinct UARTs presented mapped alternate GPIO pins, but that didn’t work out – and I didn’t have time to work on an I2C implementation. So I flew this mess, and it worked!
The whole thing, duct tape and batteries included, weighs about 140g.
Post-flight thoughts:
- Live flight photos really are exciting. It’s less exciting the next day, but in the moment, it makes the flight day way more fun.
- Wenet itself worked great. I lost signal from my tracking station at 8km altitude / 56km across land – before we’d even left the launch site. Should’ve left earlier, but I likely would not have kept up with it anyway – the payload horizontal speed hit 138mph – and we were not able to drive exactly along the path of the balloon.
- I could have used home stations to track this payload; worth a try next time depending on the launch track.
- The tracker stayed online and capturing photos the entire flight – which are beautiful.
- I could put ground plane radials on the wenet payload and maybe get a bit more transmission efficiency
- This payload is going to require a decent yagi ground station to maintain good reception throughout flight…could use a good community to work with me on receiving :)
- It would be interesting – since this pinout can run either Wenet or LoRa/PITS – to script the payload to run both! Alternating each protocol each minute, and see which one wins?
- I think the battery pack bumped on landing and caused a reboot. Classic, despite this battery pack having a screwed-on lid.
Data links:
Meshtastic Payload “redd”
This is something I’ve wanted to try again after September’s beautiful mess of a payload, but I haven’t had the energy to even start. That payload is full of beautiful data on a Raspberry Pi SD Card, up in a tree still…
A month or two ago, a local ham got me back interested in Meshtastic, so I bought this incredibly energy efficient little RAK Wisblock mini starter kit and a GPS chip (RAK12500). I’ve been tinkering with it as I drive around but did zero prep to launch it, other than that I stuffed it into a DFM17 sonde case! It came out to about 70 grams give or take a few bits of duct tape.
The results were both fantastic (in terms of feedback from people on the ground) and disappointing. Meshtastic nodes do very little recording on-board; the phone app keeps historical data but it also is continuously overwritten while the node is online (say, when you’re driving home.) Now 6 days after the launch, the nodes I made contact with have all rotated out of my node database because the mesh ’round here is so busy.
Here’s a little map of some of the notable position reports I was able to salvage from the Meshtastic app (note that anyone in the Chicago area I excluded because I received tons of data from y’all’s nodes on my drive home and I can’t say for sure if the data came from the flight or from simply driving by)
You can poke at the data here if you’re curious. It’s not much! The one good thing I’ve found in the data is enough data points which tell me that the payload survived the frigid cold and ran continuously throughout the flight. I don’t think it died at any point; the LiPo battery it was running on was sufficient.
There’s a lot of data you can’t get out of the app, so here are some screenshots. I had another node, “BLUE” on the ground in my car during the flight and it kept seeing the node “redd” throughout the flight (ok, I was driving, so I was not looking at it continuously). The downlinked Device Metrics log is odd – almost entirely blank during the flight which was from 12:00 CDT to 15:00 CDT:
The Signal Metrics Log is also interesting:
Basically we launched at ~12:00, lost metrics at 12:13, and re-gained them at 2:54. I did stop during the drive to move my Meshtastic antenna onto a roof mag mount – perhaps I did this at 2:54? And maybe this is 2:54 Eastern time, not Central time? Signal log that I typed up from the screenshots (no, you can’t export it)
Time | Signal Quality | Events |
16:15:26 | Good | |
16:08:56 | Good | <– recovery |
15:13:19 | Bad | |
15:12:51 | Fair | |
15:12:25 | Fair | |
15:12:06 | Bad | |
15:11:54 | Bad | |
15:11:04 | Bad | |
14:54:49 | Bad |
<– +1 time change
|
12:13:30 | Good | |
12:13:14 | Good | |
12:12:49 | Good | <— launch |
It’s hard to piece much data together…
Thinking forward…
What I’d like to see with Meshtastic on a balloon is if we can somehow – safely without killing everyone’s local mesh – push exact position telemetry out that gets fed into MQTT. From there it would be rather straightforward to feed it into Sondehub.
It’d also be great to fly this with some data logging onboard like I flew on the last flight.
Stuff to do for a future Meshtastic payload:
- Data log all kinds of telemetry from the device itself, the current nodes connected, and their coordinates.
- Proactively exchange positions with other nodes on the mesh as they are discovered so I get their coords?
- Find a way to send my position coordinates in a way that gets fed into MQTT but is not intentionally imprecise like Meshtastic now expects.
- Hack the GPS chip so that it gets set into some kind of flight mode and works at altitude; I think this is a uBlox chip; it’s a case of actually hacking the Meshtastic firmware.
- Consider: How can I configure my payload so it’s not jamming up airtime utilization too much? Reduce max hops, disable store & forward, etc?
Looking forward to feedback from the Meshtastic community on this – you can find me as “trickv” on the chimesh.org #balloon-talk Discord.
See you next time from 30,900m…