Testing HAB Telemetry Protocols

On Saturday Mark and I had a pleasant day bench testing High Altitude Balloon (HAB) Telemetry protocols and demodulators.

Project Horus HAB flights use a low power transmitter to send regular updates of the balloons position and status. To date, this has been sent using RTTY, and demodulated using Fldigi, or a special version modified for HAB work called dl-Fldigi.

Lora is becoming common in HAB circles, however I am confident we can do better using a custom protocol and well engineered, and most importantly – open source – modems. While very well designed and conveniently packaged, Lora is not magic – modem performance is defined by physics.

A few year ago, Mark and I developed and flight tested a binary protocol (Horus Binary) for HAB flights. We have dusted this off, and I’ve written a C callable API (horus_api.c) to make Horus RTTY and Binary easy to use. The plan is to release a cross platform GUI application that supports Horus Binary, so anyone with a SSB receiver can join in the fun of tracking Horus flights using Horus Binary.

A good HAB telemetry protocol works at low SNRs, and has fast updates to allow accurate positioning of the payload during the final decent. A way of measuring the performance is Packet Error Rate (PER) – how many telemetry packets get through at a given Signal to Noise Ratio (SNR).

So we generated some synthetic Horus RTTY and Binary packets at calibrated SNRs using GNU Octave simulation code (fsk_horus.m), then played the wave files through several modems.

Here are the results (click for a larger version):

The X-axis is in Eb/No, which is proportional to SNR:

  SNR = EBNodB + 10log10(Rb/BW)

where Rb is the bit rate and BW is the noise bandwidth you want to measure SNR in. Eb/No is handy as it normalises for the effect of bit rate and noise bandwidth, making modem comparison easier.

Protocol dl-Fldigi
RTTY
Fldigi
RTTY
Horus
RTTY
Horus
Binary
Eb/No
(50% PER)
13.0 12.0 11.5 4.5
Rb 100 100 100 200
SNR (3000Hz) -1.7 -2.7 -3.2 -7.2
Packet
Duration
6 6 6 1.6
Wave File Listen Listen Listen Listen

Discussion

The older dl-Fldigi is a few dB behind the more modern Fldigi. Our Horus RTTY and especially Binary protocols are doing very well. At the same bit rate (Eb/No curve), Horus Binary is 9dB ahead of dl-Fldigi, which is a very useful gain; at least double the Line of Site (LOS) range, and equivalent to having nearly 10x the transmit power. The Binary packets are fast as well, allowing for rapid position updates in the final descent.

Trade offs are possible, for example if we slowed Horus Binary to 50 bits/s, it’s packet duration would be 6.4s (about the same as RTTY) however 50% PER would occur at a SNR of -13dB, a 15dB improvement over dl-Fldigi.

Reading Further

Project Horus
Binary Telemetry Protocol
All Your Modem are Belong To Us
SNR and Eb/No Worked Example

5 thoughts on “Testing HAB Telemetry Protocols”

  1. I was testing a local version with your binary audio. Is the following output decoding correct? Just curious…

    586F110C265DC7538A16FF44C9B4C58BA0323FCAEBC6
    7B2F100FC419BD5B9796FF40C920558D1F842813DA8D
    7B2F104CC55DC85BB81BF766CDB425A75F381C91BA85

    73/steve

    1. Using horus_demod, I get:

      ~/codec2-dev/build_linux/src$ sox ~/Desktop/blogs/HAB_modem_tests/binary_ebno_4.5db.wav -r 48000 -t raw – | ./horus_demod -m binary -c – –
      0112000000230000000000000000000000001C9A9545 CRC OK
      266548A2EB3C960E62156D114BD97BD285C7041D2C19 CRC BAD
      0112000000230000000000000000000000001C9A9545 CRC OK

      Note the wave files posted above are 8 kHz sample rate, horus_demod uses 48 kHz.

  2. Dave, we really have to talk as we seem to be working along many of the same lines. I’m also very interested in developing and test-flying an effective telemetry modem for high altitude balloons. My thinking is to just use some of the CCSDS deep-space standards and see how they work.

    The big question is channel fading; can I use coherent BPSK? My satellite designs (AO-40/73 and ARISSat-1) both used noncoherent DBPSK (losing 3-4 dB) because AMSAT’s satellites are seldom stabilized by anything more sophisticated than a bar magnet so deep spin fading is the norm. (The carrier phase also flips 180 degrees through a fade). But a high altitude balloon can freely rotate only in the yaw axis, so a good omnidirectional antenna should not exhibit spin fading. Multipath reflections from the ground may still be significant but they might be suppressed with circular polarization.

    Anyway, I’m thinking of a flight where I could directly compare coherent BPSK (or QSPK) with noncoherent DBPSK or DQPSK.

    1. Hi Phil,

      Sure happy to talk any time, just email me directly david_at_rowetel.com for contact details.

      We have found non-coherent demodulated 4FSK quite useful, it’s only 2dB off PSK and it’s easy to get ideal performance from the demod, unlike PSK modems which often have some implementation loss. Easy to buy and fly simple FSK modulators, and our demod tracks the frequency offsets due to temperature changes OK.

      We get a little fading on landing as the payload could be spinning, but the SNR is high has it’s near the chase cars. What’s more important when landing is fast update rates so you know where the payload is landing.

      But in general fading is not a problem – in fact it’s a near perfect line of sight AWGN channel. Not hard to get telemetry ranges that are limited by the horizon (which may be several hundred km at HAB altitudes).

      When we tested our Horus Binary protocol, we measured 30dB excess on our link margin, so decided to up the data rate by a factor of 1000 … which lead to high speed FSK adventures; 100km range at 100 kbit/s on 50mW tx power:

      https://www.rowetel.com/?p=5344

  3. Another possibility is to not try to send any data at all, but to fly a simple channel sounder transmitting a known high rate PN sequence with BPSK. A correlator on the receiver will show all the multipath components that can be resolved with the selected chip rate. We did this a lot in the early days of Qualcomm CDMA.

Leave a Reply

Your email address will not be published. Required fields are marked *