raw lora packets multiple of 5 bytes?
-
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 12If 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?
-
@robert-hh Unreal Rob! I'm used to artefacts (mainly missing events) on a DSO due aliasing but I haven't had a lot of experience with spectrum analysers. This experience of seeing frequencies that aren't really there is bothersome. But then any instrument beyond a ruler is probably measuring not what you are interested in but some other metric supposedly indicative of what you are interested in, so anomalies are only to be expected I guess. Really interesting that the artefacts vanish at zero IF.
I might get myself a HackRF1 as a Christmas present & see what it has to say about side lobes as a function of bytes sent from the SX1272/1276.
Regardless of lobes/no lobes lora is pretty impressive. I ran a swept frequency source over the top of a raw lora link here on the bench & the link ploughed on regardless. I'm sure if I fiddled the timing I could break the link but I don't much see the point.
Thnx to you & jcaron for your contributions these last few years, always constructive & enlightening.
-
@kjm So I made a few spectrum capures using the same set source but three different methods for capturing.
test source: LoPy4 in Lora raw mode, sending 4 bytes at 863 MHz, SF7BW125.
Capture 1: SDR receiver (SDRPlay1a) with spectrum analyzer software
Capture 2: SDR Receiver with GQRX software
Capture 3: Oscilloscope with FFT software.
Capture 1 show sides peaks at +/- 5 MHz. And other peaks from other sources, e.g. at 868 MHz. If the IF setting is changed to Zero-IF, the side peaks are not present.
Capture 2 does not show that, if the center frequency is at 863 MHz. When moving the center frequency to e.g. 860.5 MHz lower level echo appears at 858 MHz. That is typical for these receivers, that they mirror events at the center frequency.
Capture 3: Very low level side bands at +/- 7.4 MHz.Given that what we see varies with the test tools, I assume these side bands are artifacts created by the test instrument/method.
-
@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.
-
@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.
-
@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 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
Wonder why mine looks like this? Should I be ignoring the peak off to the right?
-
@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 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.
-
@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.
-
@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 IIRC in raw LoRa mode the modem is set to LBT (listen before talk), that could be the reason for the delay maybe?
-
@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.
-
@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 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.
-
See the topic Air Time calculation in (Micro)Python to easily calculate the airtime in MicroPython.
-
@jcaron Interesting. Am I right in thinking that pycom provide no way to modify H or DE?
-
@robert-hh tnx Rob, I hadn't realised lora.stats was reporting the air time for the previous transmission, that explains a lot!
-
@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
ceilwhich 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).
