LoRa LoRa Packets

One of the reasons for me experimenting with LoRa modules was that they are transceivers and should allow uplinks from the ground to a balloon, or communications between balloons.  Uplinks I will try on another flight, but for now I’m working on inter-balloon communications.  The eventual aim for this is to fly a series of balloons across Europe, with data passing from balloon to balloon, thus considerably extending the radio range which would otherwise be limited by the Earth’s curvature:


On previous flights my LoRa trackers have transmitted continuously, but this obviously won’t work if they are meant to listen to other trackers.  I opted for a very simple and widely used technique called TDMA (Time Division Multiple Access), with all trackers taking turns to transmit on the same frequency.  Timing was taken from the GPS which every tracker has anyway.  Time slots are static and written into the code for each tracker; during non-Tx periods, each tracker listens for packets from other trackers.

I set the frame time to 20 seconds, which conveniently divides exactly into 1 minute, making it much simpler to mentally convert from a time to a slot number.  Within those 20 seconds there are 10 usable 1-second slots and 10 1-second guard periods (to prevent transmissions from overlapping).  The frame begins on the minute, and there are 3 frames per minute.

I programmed 3 trackers for the flights, with each tracker having 1 slot to transmit its own position, and 2 slots to re-transmit packets from the other 2 trackers.  So together they can use up to 9 slots (3 direct, 6 repeats) out of the 10 available.


Here’s an SDR screenshot showing packets being transmitted every 2 seconds; the packets occupy a bit less than 1 second so there is slightly more than 1 second between packets:


On my previous LoRa flights the packets have taken rather more than 1 second.  This time I opted for a wider bandwidth (62.5kHz instead of my usual 20.8kHz) to reduce the packet time to about 1/3rd.

There’s another reason for going to 62.5kHz.  The LoRa modules that I’ve used have been offset from each other up to 4kHz which, if using a 20.8kHz bandwidth, is enough to stop packets being received.  Since the allowed offset is a proportion of the bandwidth, then using a wider bandwidth reduces or eliminates the problem.

The downside of using any bandwidth > 20.8kHz, on the 434MHz band in the UK at least, is that transmissions must be limited to a duty cycle of 10%; at least it is according to my reading of IR2030.  I measured the Tx time of my tracker’s transmissions and, with 3 slots in 20 seconds, it works out at a duty cycle of just over 8%, so comfortably the right side of legality.

Another downside is that the available power is now spread across a wider bandwidth, so reducing the S/N ratio at the receiver, and thus the link budget.  Whether this is an issue or not would become clear during the flights.

For the flights, I programmed 3 trackers provided by Anthony Stirk.  Each has an ATmega 328P, UBlox MAX M8Q, HopeRF RFM98W,  and cutdown circuitry (not used this time).


Each ran the same code but with different settings for payload ID, primary slot number, and secondary (repeater) slot numbers.  Each went into a Hobbycraft foam egg, total weight with a plastic Estes 18″ parachute was about 70 grams.

LORA1 went up with a 500g balloon.  I then watched the incoming packets and saw that is was still happily repeating LORA2/3.  At about 4km altitude the first of the other ground stations (Phil Crump‘s LoRa gateway at his WebSDR site) started to receive LORA1 directly, and LORA2/3 indirectly; in fact the first packet received there was LORA2 –> LORA1 –> Phil’s gateway:

11:52:31 $$LORA2,161,11:52:27,51.95024,-2.54456,00141,0,0,12*C46E
11:52:35 $$LORA3,161,11:52:33,51.95029,-2.54451,00142,0,0,11*9985
11:52:41 $$LORA1,164,11:52:41,51.96063,-2.57614,03953,7,0,12*99C2

Next up was LORA2 under a 350g balloon.  Very impressively, this was received by Phil’s gateway when at just over 1.1km altitude, which is rather below his radio horizon:

12:23:47 $$LORA2,255,12:23:47,51.94375,-2.53650,01190,1,0,12*2AA3

I think that pretty much puts to bed any worries about LoRa range at this bandwidth.

I then checked my LCARS LoRa receiver, which was happily showing the position of both airborne trackers as well as LORA3 (still on the bench):


Finally, I launched LORA3, again under a 350g balloon.  The planned burst altitude for this one was about 28.5km but, as sometimes Chinese latex completely ignores specifications and goes rather higher.  Usually that’s just an extra 2km or so, but this time it was 10km higher than calculated!


After the flight I received several receiver log files, and so far I’ve only had time to do some analysis on Phil’s.  From that file, the following chart shows the altitude plots for LORA1 and 2 (100 on the chart = max altitude for LORA1) and fraction of packets received (10 on the chart = 100%) directly from LORA1, or indirectly via LORA2:


During the portion of the flight where both LORA1 and LORA2 were high enough to be in range of Phil’s gateway, 82% of LORA1’s packets were received directly, and 58% were received indirectly via LORA2.

LORA1 was heading for a field as it came into land.  Now, normally the actual landing position isn’t known because the range of a landed tracker is typically about 1 mile.  There have been exceptions, where either the chase car is close or the payload lands in a tree or on the side of a hill, but for the vast majority of flights the actual landing position is not known till later when the chase car arrives (and then only if the car receiver is uploading via GSM).  One of my aims, or at least hopes, for these flights was for one or both of the still-flying trackers to continue to repeat packets from the remaining tracker after it has landed.

So as LORA1 approached that field, all eyes were on the telemetry to see “how low can we go?”.  As the flight gets lower, static receiving stations start to drop out because the tracker is below their line-of-sight, till finally the closest station gets the last packet when the flight altitude is at maybe 500 metres or so (LORA3 for example was lost at 998m).  Of course this time we also had 2 mobile repeater stations in the form of LORA2 and LORA2, in good position to relay LORA1’s telemetry.  Here’s part of the conversation on our IRC channel which, to me at least, felt like waiting for Apollo 13 to come out of radio blackout!

[15:14] <daveake> 861 repeated 
[15:15] <daveake> 639m repeated 
[15:15] <daveake> suspense is killing me lol
[15:17] <daveake> 344m repeated 
[15:17] <fsphil> .... 
[15:17] <Upu> go on :) 
[15:17] <fsphil> *tension* 
[15:17] Action: fsphil puts on dramatic music 
[15:17] <Upu> jcoxon - LORA1 is about to get repeated
              on the ground from a flying balloon 
[15:17] <daveake> this is like watching apollo 13 re-enter 
[15:17] <daveake> we hope 
[15:17] <daveake> 146m 
[15:17] <Upu> haha 
[15:17] <Upu> nice 
[15:17] <Laurenceb__> woot 
[15:18] <jcoxon> Upu oooo thats amazing 
[15:18] <Upu> nice one daveake 
[15:18] <Upu> have a beer :) 
[15:18] <craag> 80 
[15:18] <daveake> 80m WOOOO 
[15:18] <fsphil> lol 
[15:18] <craag> next one will be ground 
[15:18] <craag> 46!!! 
[15:18] <Laurenceb__> yes 
[15:18] <daveake> Exccellent :) 
[15:20] <craag> and another to confirm! awesome work 
[15:20] <jcoxon> the dream of hunting payloads with other payloads
[15:20] <fsphil> hah, that was definitly on the ground 
[15:20] <DL1SGP> Lora1 still being rxed 
[15:20] <craag> getting repeated by both too it seems 
[15:21] <daveake> hah 
[15:21] <daveake> Wow, this is great :) 
[15:21] <daveake> Can anyone confirm defintely repeated by both ? 
[15:22] <craag> I've received two copies of the same sentence... 
[15:22] <dbrooke> me too 
[15:22] <daveake> excellent 

And just to prove it, here’s a screenshot from the tracking map, showing a large list of receivers all receiving LORA1 after the latter has landed:


Back to Phil’s gateway’s log, here’s the section before and after LORA1 (altitude in red) lands.  The direct packets (yellow) stop before landing, but the repeated packets (blue) continue until shortly before LORA2 lands (green):



Not shown here, but LORA3 also repeated the landing position.  An excellent result.  And even better, the same happened when LORA2 landed – it was repeated by LORA3.

Well, I say “landed”, but LORA2 managed to stop on the edge of an office roof, where it currently remains until I can organise recovery:

LORA3 landed without airborne support of course, but was easily picked up from the chase car from over a mile away – a similar result to that which I’m used to with RTTY.

LORA1 however is missing – no signal and no payload at the landing position.  Hopefully whoever found it will get in touch.

UPDATE 1: LORA2 now recovered.  The payload was exactly where the GPS reported (see satellite image above), with the line/chute/balloon dangling down to about head height.  Thanks to helpful people at the site it was recovered in minutes.

UPDATE 2: LORA1 now recovered.  I received a phone call several weeks after the flight, from the landowner who found the payload in a field.  I think a sheep must have been holding it hostage when I looked for it, as the aerial had obviously been chewed!

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

3 Responses to LoRa LoRa Packets

  1. Gur Lavie says:

    Hi David,

    Fantastic read for me. I am looking to use this method for floating west of Israel.
    Our wind conditions, means that most of the year I can’t get a HAB land in the country.

    So, instead of just waiting around, I was dreaming on relaying with multiple balloons. Then Anthony pointed out this experiment. Amazing performance and experiment planning !

    Did you investigated it further ? Mainly, how far can you wait between balloon launch.
    For example – I guess that on the ground, just from your APRS station, you have several 10’th of kilometers range ? but once in the air – how far can two balloons be and still relay ?

    What TX power did you use ?
    Did you use the same antennas for TX and RX ? which type ?

    Sorry to dump all of this at once.

  2. Pingback: LoRa / LoraWAN; noch ein neuer Funkstandard - Merkbar.

  3. Pingback: Pi in the Sky: LoRa Tracker und Gateway - Merkbar.

Leave a Reply

Your email address will not be published.