0xfeed

A tracker device is responsible for transmitting telemetry data, including balloon location and sensor readings, so that the balloon can be tracked and the payload can be collected once it falls back on the ground. The transmissions may optionally include images or video captured by the tracker.

A typical tracker device contains:

Currently, there is no practical way to reliably transmit large amounts of data over a long-distance radio link (using battery-powered consumer devices), so in order to get access to the full-resolution images/video recorded by the tracker, the payload must be found and recovered. The tracker isn’t necessarily a cheap device, so you probably want to find it anyway. Besides, it can be used again. One or multiple receiver devices need to be set up to receive and decode the tracker device transmissions. A receiver device can visualize the location of the balloon on a map and it may also display low-quality images sent by the tracker.

There is some slightly older documentation of balloon launches in Finland (where I live), mostly related to project Ilmari, but the most useful HAB resources I’ve found are the UKHAS website and Dave Akerman’s blog. There is actually an excellent blog post called High Altitude Ballooning, From The Ground Up (and back again) that summarizes almost all details and steps required to perform a successful balloon launch. The balloons and other equipment needed to physically launch a balloon have also been documented on many sites, although I will visit these topics in this blog later.

The most important part of the tracker is the radio communication module. It needs to transmit a signal that is strong enough to be received tens or even hundreds of kilometers away. While 2G/3G networks may have the required range in low altitudes, there is no coverage in upper parts of the atmosphere. Receiving signal from such distance would most likely not be possible at all on the surface of the earth when using a relatively weak, battery-powered transmitter, because the signal is blocked by terrain and buildings. However, with balloons it is possible to achieve line-of-sight (LOS) conditions, since a balloon is up in the air and antennas can be pointed in the direction of the balloon.

Balloon telemetry is usually transmitted in unlicensed ISM or amateur radio frequency bands using radioteletype (RTTY) with simple frequency-shift keying (FSK) modulation. UKHAS have even developed a simple standard protocol for telemetry data, which can be used to send the data to Habitat server to follow the balloon position on map. As an alternative to RTTY, Automatic Packet Reporting System (APRS) has features similar to the UKHAS protocol for transmitting telemetry data, but transmitting APRS signals on the commonly used 2-meter frequency band (~144 MHz) requires an amateur radio license.

When searching for a suitable radio module for Raspberry Pi, I came across the Pi In The Sky (PITS) project, which provides several add-on boards (HATs) for Raspberry Pi that are suitable for building a balloon tracker and a receiver device. They also provide software for the tracker and the gateway (receiver). The main PITS board contains a UBlox MAX-M8Q GPS receiver, which is supposed to be a good choice for high-altitude experiments, and a Radiometrix MTX2 transmitter for sending telemetry using RTTY. However, what is more interesting is that the PITS project also offers a more modern alternative for radio communication: a LoRa (Long-Range) Expansion Board based on HopeRF RFM95W/RFM98W LoRa chips. The chips are clones of Semtech SX127x LoRa modules so they can be used interchangeably.

LoRa(tm) is an emerging modulation intended to be used in IoT applications. The modulation offers good immunity to radio interference (see comparison to FSK) and, as the name suggests, very long range of optimally tens of kilometers for transmissions. The chips have a high-level SPI interface, they are highly configurable, relatively easy to program and they can be used for both transmission and reception. The only downside is probably the fact that LoRa is a proprietary modulation, so it cannot be reliably received with ordinary radio equipment. However, that is most likely going to change, since the modulation has been almost completely reverse-engineered and there are proof-of-concept implementations along with research documentation available for receiving LoRa transmissions using ordinary SDR dongles.

It seems that GitHub user rpp0’s LoRa implementation is being actively developed and it supports most of the configuration options for the modulation and it provides tools for real-time demodulation and decoding of LoRa signals. Out of curiosity, I briefly tested reception of LoRa packets with rpp0’s gr-lora on my simple RTL-SDR USB-dongle setup and while I was able to successfully receive some data, larger packets were corrupted and some packets were completely lost. Nevertheless, it was a promising result and it will be soon possible to receive LoRa transmissions without specialized LoRa chips.

For the tracker device, I chose to use the LoRa board for radio communication and get the UBlox MAX-M8Q on a separate board, since I thought I would not be using RTTY transmissions for anything.

To make the tracker more interesting and useful, I wanted to include more sensors in it (in addition to the plain GPS) so that it can collect and transmit this data during the flight. My original idea was to add a sensor for measuring temperature and barometric pressure, such as the BME280, but I found that the Sense HAT for Raspberry Pi actually offers that in addition to gyroscope, accelerometer, magnetometer and air humidity, and there is driver software available for all of the sensors.

Before buying any of the add-on boards, or HATs, it is useful to check that there are no conflicts with Raspberry Pi peripheral buses and the boards. The I²C bus can be shared between devices as long as each device has a unique address. The SPI bus can also be shared, but it requires a separate chip enable pin for each device to enable one device at a time and keep others disabled while transferring data. The serial port can naturally be used by one device only.

All of the Sense HAT sensors (along with the unused LED matrix and joystick) use I²C interface, the GPS board sends data through serial port (UART) and the LoRa board is controlled via SPI, so the boards should work together as expected.

Raspberry Pis and its accessories are sold by many online stores (even in Finland), but I found the cheapest prices and widest collections of add-ons and accessories from UK (where Raspberry Pi originates from):

The tracker device is made of the following parts:

As can be seen in the photo, it is very easy to stack Raspberry Pi HATs (Hardware Attached on Top) when there are no I/O conflicts. The boards are (from top to bottom): Sense HAT, GPS HAT (with external antenna, not visible in the photo) and LoRa Expansion Board (with the "stubby" antenna). The HATs have holes for the wide camera cable, but with three HATs stacked, it was easier to just bend it sideways.

The receiver device could basically be any computer with equipment and software capable of receiving and decoding the transmissions of the tracker device. In the case of LoRa transmissions, however, I had to use a Raspberry Pi also as the receiver device so that I could use the same LoRa add-on board for reception, because LoRa reception is not yet reliable without proprietary LoRa hardware. The LoRa board has SMA antenna connectors so a more powerful external antenna can be connected to the device to improve reception. To make the receiver device a bit more fun to use, I added a Display-o-Tron HAT LCD display module with some extra LEDs and buttons to show real-time information about signal strength and telemetry data.

The receiver device has the following parts:

The information displayed on the screen in the photo is just one of my early tests with the gateway, but it includes already the signal strength (RSSI) both as numbers and using the LED bar graph, and some counters for transferred LoRa packets.

The Display-o-Tron HAT is connected with a custom pinout via wires, because I was not careful enough when checking for conflicts between the boards. Both the LoRa chips and the LCD screen are controlled via SPI bus and having two LoRa chips (for possibility of simultaneous transmit and reception) in the LoRa Expansion Board creates a conflict with the SPI pins used by the display, because the chip in slot named CE0 uses the Chip Enable 0 pin for SPI0 bus. Fortunately, Raspberry Pi has multiple SPI buses, which can be enabled using the built-in device tree overlays of Raspbian. The configuration change is simple: just add dtoverlay=spi1-1cs to /boot/config.txt on the Raspbian SD card, reboot and another SPI device /dev/spidev1.0 appears. Then the SPI-related pins of DoT HAT need to be connected to SPI1 interface pins of Raspberry Pi instead of the usual SPI0.

The most important responsibility of the tracker software is to transmit telemetry data reliably to the receiver(s). Since wireless communication is inherently unreliable and prone to transmission errors, I decided to implement a protocol that provides more reliable data transmission. The LoRa radio chip supports packet-based data transfer with a maximum packet size of 255 bytes and bit-level error correction, but it does not offer a way to recover a packet that has not been received correctly or that has not been received at all. It’s like working with IP packets over an unreliable transport medium, except that there is no addressing, so designing a protocol that has features similar to TCP made sense for this purpose.

The protocol I have designed provides:

I left out source and destination addresses on purpose, since I’m dealing with one device at a time and it’s possible to use different transmission frequency for each device if multiple devices are in use, but it should be fairly easy to implement addressing in the protocol.

The node application runs two routines, which both are responsible for collecting and transmitting data.

The gateway application receives data transmitted by the node application. The application:

The gateway application provides an HTTP API for reading the telemetry data history and downloading the received images, and a WebSocket API for receiving real-time telemetry data updates.

As mentioned above, the application also displays selected details of signal quality and telemetry data also on the LCD screen.