A few locals (mostly part of the SecKC crew) have been chasing weather balloons for the past few months. It's an interesting way to get out of the house and go do something. We are also trying to reverse engineer the guts of these weather balloon payloads, but that's a story for another post.
Weather Balloons and Radiosondes
In the US, a number of National Weather Service offices (I'm guessing about a third to half of them) deploy weather balloons every day at about 0:00 and 12:00 UTC, give or take an hour either way. They often launch at about 45 minutes ahead of time, but they can be delayed by severe weather. That's over 700 weather balloons per year from each of the dozens of stations that launch them!
The weather balloons carry something called a radiosonde into the stratosphere. This package contains a battery, radio transmitter, GPS, and weather sensors. The radio transmissions include position information, humidity, temperature and other metrics, once per second. Position information is used to determine wind speed and elevation to correlate with the other metrics. This data is shared internationally and is used for local forecasts and models, and worldwide climate trends.
Close up of the bottom panel of a 400 MHz Lockheed-Martin Sippican LMS-6 Radiosonde.
The air gets thinner and the pressure lowers as the balloon climbs past 100,000 feet, and it eventually bursts. The package, weighing less than a pound, falls back to the ground under a small parachute so that it doesn't hurt anyone or anything when it lands.
Here's a video I shot through a telescope, of a weather balloon bursting at about 130,000 feet. You can faintly see the radiosonde swinging beneath the balloon. When it bursts, the parachute expands as the package falls.
A recovered weather balloon, after untangling all of the rope.
The National Weather Service does not recover these devices from the field. Some of them have a mailing bag and shipping label attached so that folks who find them can return them to be refurbished. The radiosondes that we've been finding have no instructions aside from "dispose safely". That is to say, once they have fulfilled their mission and landed, these radiosondes are very much "finders keepers" and are no longer government property. They can land more than a hundred miles away from the launch site, depending on jet streams and wind conditions closer to the surface.
Tracking
To facilitate the tracking of these devices, a number of software tools have been created to make use of software-defined radio receivers (such as the RTL-SDR or HackRF One) or simple audio-decoding from a computer sound card. My favorite tools are radiosonde_auto_rx and chasemapper, both part of Project Horus, an amateur radio high-altitude-ballooning project in Australia. The tools to monitor amateur balloons happens to work just fine for tracking weather balloons, and folks have added code to help decode the payload data for weather balloons.
radiosonde_auto_rx scans a small range of frequencies you define, looking for a signal that's likely to be a radiosonde. It then tunes to that frequency and tries to decode the location data. Once it's locked on, it continuously tracks the location of the balloon. It can also upload balloon location data to websites like sondehub (radiosonde tracking) and habhub (high-altitude balloon tracking), so folks can share data about these balloons' trajectories with a world-wide audience.
Screen shot from sondehub.org showing multiple weather balloons in flight, and locations of auto_rx sites:
Chasemapper acquires the balloon location data from radiosonde_auto_rx, and your location from local GPS data, then draws a map of your location and the payload's location, in a browser session. This is a nice visual aid when you're planning on recovering a radiosonde. Here's a screen shot showing my vehicle's track and a radiosonde payload location on a recent balloon chase. The payload location doesn't have a track following it because I rebooted my setup to move it to my car. The movement was from me hiking toward my car while unplugging the battery.
Building the mobile tracker
I decided I'd like to build a semi-mobile balloon tracker that I could leave running at home most of the time, but also quickly toss into my car or even carry with me if a radiosonde was going to be landing nearby, to help me recover it from some corn field or woods or an 8-foot tall patch of thistles and prairie grass out in the middle of nowhere. These things never seem to land anywhere convenient, like in the ditch of a dirt road.
I decided to make do with stuff I already had laying around. You may recognize some pieces from previous articles. The below links are Amazon affiliate links to the parts I used if you wish to reproduce my exact setup, and purchasing from these links supports this site).
- Raspberry Pi 3 with an AdaFruit 3.5" TFT
- RTL-SDR v3 receiver kit or NooElec NESDR Nano Three kit (you only need one SDR, both of these models work in this setup)
- Inseego MiFi 8800L WiFi Hot-Spot
- Rii wireless mini keyboard/trackpad
- 26800mAh USB battery pack
The MiFi 8800L not only offers 4G wireless connectivity so radiosonde_auto_rx can upload location data and chasemapper can download map data, but it also has a GPSd server integrated so other devices (like the Raspberry Pi) can use the GPS location of the hotspot. You must log in to the MiFi admin page to activate the GPS Service. By default, it runs on port 11010, and it's recommended to leave that default set.
Actually getting chasemapper to use that GPS data turned out to be more trouble than I had bargained for. You may be better-off connecting a USB GPS to your Raspberry Pi. I'll cover how I managed to cobble everything together as I go through this post.
The first order of business was installing the latest RasPiOS to a fresh 16GB SD Card. There is more than enough documentation on raspberrypi.org to get you started. The Rii keyboard works both with a nano-receiver or via Bluetooth. Pick your poison. I chose to use the nano-receiver because bluetooth seems to not like to auto-reconnect on reboot some of the time. Feel free to use whatever kind-of-portable human-interface device you like.
Next, I had to get the display working.
I had really good luck with the fbcp-ili3941 driver on this Raspberry Pi with Kali Linux, and the instructions I wrote about setting up fbcp worked fine on the latest RasPiOS. You can follow most of the instructions in that article to get the AdaFruit TFT working, just keep in mind the touch screen won't work with the fbcp driver. The digitizer on my display actually broke a few years ago, so I don't miss it.
For my setup, I uncommented the following lines in config.h. Note that these lines need the # at the beginning of the line. I removed the // from these two lines to uncomment them:
#define DISPLAY_ROTATE_180_DEGREES
#define DISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING
I used the following options to build fbcp:
cmake -DADAFRUIT_HX8357D_PITFT=ON -DSPI_BUS_CLOCK_DIVISOR=30 ..
As per the Kali instructions, I put the call to /usr/local/bin/fbcp near the top of /etc/rc.local so that it runs on boot.
I set my display up to run in 480p mode since the display is so tiny. The entirety of my /boot/config.txt file is:
hdmi_force_hotplug=1
dtparam=audio=on
hdmi_group=1
hdmi_mode=3
dtoverlay=pwm,pin=18,func=2
Reboot and make sure the TFT display works.
Now for Radiosonde_auto_rx. The setup instructions mostly work. You'll need to install a bunch of dependencies. They recommend installing rtl-sdr from source. I just added it via apt, and it supported the bias-tee option. Make sure you install the udev rules and module blacklist options per the instructions.
Keep following the instructions. Maybe, if you're lucky it'll just work. For me, though, I had to do some hacky garbage to get it to compile. If build.sh fails, you can try these tricks:
I had to tell the compiler use the c11 standard for compiling fsk_demod by adding “-std=c11” to line 50 of auto_rx/build.sh, which now looks like this:
gcc -std=c11 fsk_demod.c fsk.c modem_stats.c kiss_fftr.c kiss_fft.c -lm -o fsk_demod
I had to tell the compiler to use the built-in alloca() for some reason, and the real baffler was having to define the meaning of freaking Pi, twice.
In utils/fsk.c, I added these lines to the "includes" block near the top:
#define alloca(x) __builtin_alloca(x)
#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif
And I added the following to utils/modem_stats.c, also near the top.
#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif
With all that out of the way, the instructions for setting up Radiosonde_auto_rx work just fine. Make sure to edit station.cfg. You probably want to specify a name, callsign or handle for uploading to HabHub (and enable uploads), and you should specify your latitude and longitude. You could, in theory, also use gpsd for radiosonde_auto_rx as well. I didn't set up auto_rx to use gpsd, so even when I'm mobile, the reports appear to come from the hard-coded location in auto_rx. I'm fine with that.
It seems that the National Weather Service relies mostly on radiosondes made by Lockheed Martin Sippican. The LMS-6 Radiosonde comes in two "flavors", one operating between 400 and 406 MHz and the other one operating around 1680 MHz. The Vaisala RS41 is a newer radiosonde model used at some locations, and it also operates around 400 MHz. You should ensure the proper frequency range for your location is enabled. The 1680 MHz radiosondes also work best with a circular-polarized antenna, similar to those you might use for certain FPV drone video.
Setting up Chasemapper
The instructions for Chasemapper mostly work out of the box, with the exception of GPSd in my case. The version of GPSd on the MiFi 8800L doesn't support JSON output which Chasemapper requires, so I ended up running a modern version of GPSd on RasPiOS, pointing it at the GPSd on the hot-spot. Details on that toward the end of the article. I also had some trouble running GPSd on the default port of 2947, so of course I ran it on port 1337.
For horusmapper.cfg, I changed only the following lines:
car_source_type = gpsd
gpsd_port = 1337
habitat_call = [my amateur radio callsign]
Tying it all together
I didn't set up systemd services for anything, but you may want to follow the instructions in the git repositories to enable systemd services if you plan on building a dedicated tracker. I run gpsd, auto_rx and chasemapper on-demand with a simple shell script that I call "loon.sh":
#!/bin/sh
gpsd -S 1337 gpsd://192.168.1.1:11010
cd ~/radiosonde_auto_rx/auto_rx
python auto_rx.py&
cd ~/chasemapper/
python horusmapper.py&
Everything runs in the background, and the terminal will fill up with logs about both chasemapper and auto_rx status. You can fire up your Raspberry Pi's web browser and hit localhost:5001 for ChaseMapper, and localhost:5000 for the auto_rx status page.