When used for tracking high altitude balloons, LoRa has the potential for a receiver to be set up unattended on a permanent basis, but only if it can automatically set itself to the correct frequency, bandwidth and other settings for each flight. Originally I intended these settings to be taken from a central database, but a rather neater solution was suggested yesterday on the #highaltitude IRC channel. During a discussion of how to solve this problem, Philip Heron of SSDV fame suggested that each balloon announce its own parameters on a standard calling channel:
[15:45] <fsphil> I'd like a channel for announcements [15:45] <fsphil> "I'm on xxx MHz with these parameters"
Fast-forward 24 hours to now, and I’ve coded this up in the LoRa section of my Pi In The Sky tracker software and also my LoRa gateway. It wasn’t difficult and took about 3 hours altogether.
The tracker is configured with 2 settings:
The first setting specifies a calling frequency on which the tracker will periodically transmit a message telling listeners the frequency and parameters of its normal transmissions. The second setting specifies how often this special message is sent (e.g. after every 5 normal messages). The other parameters of this special message (bandwidth, spreading factor etc.) are fixed at present (probably a good idea for a calling channel!):
EXPLICIT_MODE ERROR_CODING_4_8 BANDWIDTH_41K7 SPREADING_11;
The message itself is very simple, e.g.:
and contains the payload ID, frequency in MHz, implicit/explicit mode, error coding, bandwidth, spreading factor and low-data-rate optimisation.
Here’s a sample packet seen on an Airspy SDR. The calling packet is the one on the right (at 434.475MHz), followed by the start of a normal packet (on 434.400MHz):
The gateway has of course to be set to the calling frequency (434.475MHz in this case) and the correct set bandwidth etc. which are combined to together into a new “mode” of 5. I have also enabled AFC (Automatic Frequency Control) using code written by David Brooke (thanks David!) – you can see his version of my LoRa gateway here.
frequency_1=434.475 mode_1=5 AFC_1=Y
The gateway shows the following screen when started:
Now let’s see what happens when it receives a calling packet:
The final message in the log at the bottom states that the new frequency is 434.405MHz; why not 434.400MHz as requested by the tracker? The reason is that the receiver detected a frequency error of 4.6kHz (see the frequency error shown near the bottom of the blue section on the right). As we have AFC enabled, the software automatically applied this error when it switched to the balloon tracker’s main frequency. It’s better to do it now rather than later, especially if (as in this case) the balloon’s main transmission is using a narrower bandwidth where a large frequency error might prevent any packets being received.
So, now the gateway has tuned in to the balloon’s main frequency, and set the various LoRa parameters correctly, it should start receiving regular packets: