Dave Akerman

It’s now quite common for high altitude balloon flights to send down live images during the flight, as well as the usual telemetry.  However data rates from balloons are rather low, so each image can take several minutes to send even for rather low resolutions.

"It's currently a problem of access to gigabits through punybaud"

Maximum data rates are a function of several things – emitted power, receiver sensitivity, path loss, aerial gain, duty cycle (proportion of time that the transmitter is active), bandwidth (amount of the radio spectrum used by the signal) and the type of modulation – and these items have legal and practical limits.

For UK flights we use licence-exempt radio transmitters and so operate within the limits defined by IR2030,  For almost all flights, operators choose the band from 434.04-434.79MHz, because this range allows for continuous transmission (100% duty cycle) and is shared with the amateur radio 70cm band, meaning that receiving equipment is readily available.  Maximum power in this band is 10mW e.r.p. (effective radiated power), and the modulation scheme most often used is RTTY.  To allow reception by ham radios, the modulation has to fit within a frequency range that those radios will pass, which is about 4kHz.  Historically radio transmitters drift in frequency considerably, so if the modulation uses a large proportion of this bandwidth then receivers will need to re-tune almost continuously.  With this, and the increased packet loss at higher baud rates, 600 baud is a practical limit for transmission speeds with RTTY, and most flights with live imaging settle for 300 baud.  With modern temperature-compensated radio transmitters this could probably be pushed to 1200 baud with fair success.

LoRa Modulation

Anyone who follows this blog will be aware that I’ve been experimenting with LoRa modules, which use their own (patented, sadly) modulation scheme.  However LoRa modules are cheap and work well, so until something else comes along that is as good and open-source, then I’ll continue flying them.

LoRa chips offer bandwidths up to 250kHz, which is way beyond the practical limit with most ham radio receivers and indeed beyond that allowed in the 434MHz band that I mentioned.  Higher bandwidths can allow for higher throughput, though the receiver will then see more noise (as it has a wider frequency range to listen to) so the signal-to-noise ratio is worsened, meaning that range is compromised.

Some bands around 434MHz do allow for wider bandwidths, but only at limited duty cycles of 10% or less.  There’s not much point in using a bandwidth 10 times wider if you can only transmit for 10% of the time, as the throughput is back where you started!  However there’s a section of the 868MHz range that allows for both high bandwidth (300kHz) and continuous operation.  The downside (there is always a downside) is that transmitted power is even lower, at 5mW ERP.

LoRa devices operating within the 434MHz band mentioned above can use up to 20.8kHz bandwidth, giving a data rate equivalent to about 1400 baud RTTY.  Going from 20.8KHz to 250kHz gives nearly 17,000 baud equivalent.  This is still pathetically slow compared with 3G or home broadband, but it’s much, much faster than the 300 baud that we’re used to.  If, of course, it works.

Need For Speed

Higher data rates mean that, for example, instead of taking 5 minutes for a low resolution (about 600 x 300 pixels) image, we can send a 1280×640 image in about 70 seconds.  Here’s an example image being transferred with a bandwidth of 250kHz:

Packet Loss

As discussed, wideband modulation reduces the SNR seen by the receiver, so range is limited compared to narrowband modulation.  The lower tranmission power (5mW vs 10mW) makes SNR a little worse, as does the path loss of 868MHz vs 434MHz.  The end result will be increased packets loss as the signal level drops, through the balloon payload swinging around and as it gets further away.

We can mitigate these factors somewhat by using a Yagi aerial at the receiver and a filtered pre-amplifier.  Even so, and with error correction in the image packets, some packets will be lost resulting in blocks missing from the received images.  What can we do if that happens?

Play It Again

Another nice feature of LoRa modules is that they are transceivers, so we have the option of sending messages back up to the payload from the ground.  So, why not have a ground station take note of any missing packets, and then send a message to the payload asking for those packets to be sent again?  All we need is a way of spotting missing packets, and a scheme (e.g. TDM) that provides an uplink slot where the payload stops transmitting and starts listening for a short time.

It’s not difficult for a listening station (LoRa gateway) to build a list of missing image packets – it just needs to take note of which packets have been received.  However there may be several listening stations – this is a key feature of the UKHAS listening network – and there’s no point asking for a packet to be re-sent if it was already received by another station.  So, this logic needs to be done centrally.  With this in mind I spoke to Philip Heron who invented the SSDV (Slow Scan Digital Video) standard, wrote the encoding and decoding software that converts between JPEG and SSDV, and wrote the code on the SSDV server that accepts packets from listening stations and combines them into JPEG files which it displays on web pages.  Philip very kindly wrote a web API for the server, providing functions which a LoRa gateway can use to produce a list of missing image packets.

I had already written code in my LoRa gateway to produce this list locally, so I removed most of that code and instead created some new code that queries the SSDV server and produces a list of missing packets for the latest 2 SSDV images, for a particular payload.  I chose 2 because if the payload has recently started transmitting a new image, we need to know if it has to go back and re-transmit any missing packets from the previous image.

Test flight will happen when the weather is a bit better!