LoRa Calling Channel and Auto-Tune

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"

Neat idea.

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!):


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.


The gateway shows the following screen when started:

d2Note that it says “Calling mode” at the top, next to the calling channel frequency.

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:

d4In this screenshot, it has received 13 such packets so far.  You may also notice that it has fine-tuned itself to the balloon main frequency, and now has a zero frequency error.



This entry was posted in Weather Balloon. Bookmark the permalink.

4 Responses to LoRa Calling Channel and Auto-Tune

  1. Kimmo Lepoaho says:

    Dear Dave Akerman

    You have nice webpages indeed.
    I am the student in JAMK university of applied science in Jyväskylä, Finland.
    I am making the final examination of LoRa and use of it in IoT.
    I have 2 Raspberry PI and HopeRF RFM96 (868MHz) on it.
    Now I am wondering what is the best way to test coverage,
    battery lifetime, bit rates and so on with this combination.
    Maybe I could also try balloons with testing.
    Have you any idea how to carry on?

    Br. Kimmo Lepoaho (OH6LDK)

    ps. I would mention your work in my final examination.
    pss. So I know also what RTTY, APRS means

    • dave says:

      Balloons have an advantage because they have line-of-sight to between the air and the ground; IOT does not always have that. So balloons are not a good way to test the range on the ground.

      You could set up a ground test with aerials a certain distance apart, with LOS or with buildings in the way, and test at different power and bandwidth and other settings.

      No doubt Semtec have lots of data about this. Also they have a calculator which shows power consumption which you could use to calculate batter life.

  2. Anonymous says:

    Has this been implemented in the PITS software?

    I see some references to it in some parts of the code, but I am not good enough at C to really understand if it is what I think it is!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.