raw lora packets multiple of 5 bytes?

[kjm]

I was tinkering with an application to synchronise RTCs over raw lora setup as

>>> lora.bandwidth(); lora.coding_rate(); lora.preamble(); lora.sf()
0
1
8
12

If I send an epoch to a remote the remote needs to know how long the transmission took in order to synchronise the local RTC to the sender RTC. Fortunately lora.stats() provides a tx_time_on_air. In the course of this investigation I couldn't help notice the unusual connection between tx_time_on_air and the number of bytes sent
tx_time..bytes
0828.......00-05
0992.......06-10
1156.......11-15
Looks like the raw lora train leaves the station with a fixed 764ms overhead locomotive followed by any number of 64ms carriages with seats for 5 bytes each. Kinda weird?

[jcaron]

@kjm in theory it should go up by 5 bits for each 4 of payload due to the coding rate (coding rate 1 is 5/4). See page 7 of the LoRa modem design guide. Not sure if that’s supposed to be rounded to entire bytes, I would have thought not.

IIRC the airtime returned by lora.stats is not measured but computed, so it’s not impossible it’s not correct, one would have to check the sources.

[robert-hh]

@kjm testing the length of the actual radio transmission with an oscilloscope, it shows indeed that the duration of the RF signal increases in steps. Using LoRaWan messages at DR=5 (SF7BW125), here are some results for increasing payload sizes. Only the values are shown at which the time changes. So the value for 3 - 6 bytes is the same.

Size   DR5 (ms)  Size DR0 (ms)
  1       46,4     1    1155
  3       51,8     3    1315
  7       56,8     8    1480
 10       61,6    13    1646
 14       66,8    18    1815
 17       72,0    23    1970
 21       77,4    28    2135
 24       82,3    33    2300

That may be related to the coding.
Edit: I repeated that for DR0. There, the Tx times increases at steps of 5 bytes.
Edit2: lora.stats() after a send seems to tell the airtime of the previous send. So repeating sending the same size twice tells you the time on air. That matches down to 1 ms what I see in the oscilloscope.

[jcaron]

@robert-hh @kjm Was on my phone earlier so it was difficult to include full details, but here's what Semtech's LoRa modem design guide says:

So obviously it's the ceil which causes the steps. At SF12, no header, with low data rate optimisation, CR=1 (5/4), that results in:

payloadSymbNb = 8 + max(ceil((8*bytes - 24)/40)*5,0)

Which does indeed step every 5 bytes (40 / 8).

At SF7 without low data rate optimisation it would be:

payloadSymbNb = 8 + max(ceil((8*bytes - 4)/28)*5,0)

Which steps every 3.5 bytes (28/8), which matches the alternating 3-byte and 4-byte intervals (except the first one, not quite sure why).

[kjm]

@robert-hh tnx Rob, I hadn't realised lora.stats was reporting the air time for the previous transmission, that explains a lot!

[kjm]

@jcaron Interesting. Am I right in thinking that pycom provide no way to modify H or DE?

[rcolistete]

See the topic Air Time calculation in (Micro)Python to easily calculate the airtime in MicroPython.

[robert-hh]

@kjm That's what I have seen. With some probability it's a problem of the API. The more important result was, that the value reported by lora.stats() matches the physical event.
Another minor topic: There is a small delay between calling lora.send() and the message going into the air. Increasing with the packet size, it is 2.5 - 4.5 ms at DR5 with slight variations. I did not test other data rates, but expect it to be not related to the data rate.

[kjm]

@robert-hh 3-4ms I can live with Rob. It's surprising how these ms intervals vary. Yesterday I ran a test to see how long my 300 sample A/D read took, 44ms. Today, on a different lopy4 with the same firmware, it's 48ms, a ~10% variation from one chip to the next.

[kjm]

@jcaron Is there a formula that will tell the range of frequencies the lopy4 raw lora will use for a given bw, sf, etc.? It looks like ~3MHz on my cheapie little hand held RF spectrum analyser.

[jcaron]

@robert-hh IIRC in raw LoRa mode the modem is set to LBT (listen before talk), that could be the reason for the delay maybe?

[jcaron]

@kjm in theory it should be the bandwidth setting, that’s what determines the allowed frequency range, so 125 or 250 or 500 kHz, centred on the nominal frequency.

I’m a bit surprised you could find 3 MHz, that seems like a lot.

[robert-hh]

@jcaron said in raw lora packets multiple of 5 bytes?:

IRC in raw LoRa mode the modem is set to LBT (listen before talk), that could be the reason for the delay maybe?

I used LoraWAN mode for testing. I could repeat that for Raw mode.

[robert-hh]

@kjm said in raw lora packets multiple of 5 bytes?:

It looks like ~3MHz on my cheapie little hand held RF spectrum analyser.

What I see in the SDR receiver is about 125 kHz. See the attached picture with 3 packets in the waterfall diagram. Setting DR0, BW125.

[robert-hh]

@jcaron said in raw lora packets multiple of 5 bytes?:

IIRC in raw LoRa mode the modem is set to LBT (listen before talk), that could be the reason for the delay maybe?

Similar times for Raw Lora mode.

[kjm]

@robert-hh Wonder why mine looks like this? Should I be ignoring the peak off to the right?

[jcaron]

@kjm does the peak at 924 MHz appear and disappear at the same time as the one at 921.5 MHz, or is not correlated?

If the latter it could simply be another user of the band.

[robert-hh]

@jcaron For me it looks too just like a transmission on a separate channel, or something else. If I run the spectrum analysis with either tool (SDR or Oscilloscope in FFT mode) in peak hold mode, It shows clearly three different bands of 128kHz width. Sample picture of SDR below.

P.S.: The signal level is low because I run the LoPy for desk tests with a 50 Ohm terminator instead of an antenna. The stray radiation is still strong enough for functional testing.

[kjm]

@jcaron I've got a raw lora base interrogating raw lora remotes sequentially with a 2 byte poll, they reply with 3 bytes. The annoying little peak 3MHz above the centre frequency is due the 3 bytes transmissions. If I depower the remotes it goes away, if I rejig the base to transmit 3 bytes instead of 2 it comes back. Most peculiar!

The longer I run it the worse it gets, after three or four 3 byte transmissions I have little peaks at + and - 1.5MHz from the centre frequency too.

[robert-hh]

@kjm said in raw lora packets multiple of 5 bytes?:

The longer I run it the worse it gets, after three or four 3 byte transmissions I have little peaks at + and - 1.5MHz from the centre frequency too.

Since your Spectrum analyzer device seems to be set to max hold, it will accumulate every event it detects. That's why you see more peaks the longer you test. Can you determine the level at which the side peaks occur. I see -50dB for the main peak, but the other levels are hard to see. Could be ~-80 db for the peak at 924 MHz.
If I run my test with the SDR for raw lora with a 20MHz instead 2 MHz span, I see side bands at 863 +/- 5 MHz. Most likely these are artifacts caused by the kind of measuring.