LORA communication latency

For CircuitPython issues, ask in the Adafruit CircuitPython forum.

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
albertovalero
 
Posts: 3
Joined: Fri Jan 13, 2023 9:04 am

LORA communication latency

Post by albertovalero »

Hello,
we are doing measurements of the transmission time for a fixed size package between two RFM96W LORA modules.
The transmitter is controlled from an FPGA in order to have better control of when the package is transmitted.
Then, we measure the time from the moment we finish the SPI TX command from the FPGA until the LORA receiver module raises the rx interruption.
We would expect that all the packages have the same transmission time but we have variations of some microseconds. The attached figure shows a histogram with the latency distribution for multiple packages with the same size and same distance between transmitter and receiver.
Both the TX and RX LORA modules are configured for continuous operation so we are sure they do not go to IDLE at any moment.
We would like to understand if this is expected and where this uncertainty could be coming from.

Thanks,
Alberto
Attachments
Figure_script_A.png
Figure_script_A.png (36.05 KiB) Viewed 201 times

User avatar
sj_remington
 
Posts: 997
Joined: Mon Jul 27, 2020 4:51 pm

Re: LORA communication latency

Post by sj_remington »

Radio communication is inherently noisy and unreliable, and I can think of lots of possible ways to explain that small variation in latency, even under the very best of conditions. One possibility might be the time it takes the receiver to recognize the preamble and sync word. It is interesting that the variation is so accurately described by a Gaussian curve, suggesting that there are no systematic outside influences.

Consider providing useful details about your setup, like test environment (Faraday shielded?), antenna construction and orientation, separation of modules, radio parameter settings, data packet details, etc.

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: LORA communication latency

Post by adafruit_support_mike »

Stepping back, the first concern is to make sure you have a reliable timebase. Unless you're using a very good clock external to the microcontrollers, it's overwhelmingly likely that your histogram is a map of CPU clock jitter.

A typical crystal oscillator has a tolerance of 30ppm, or 30 microseconds per second. That figure is typically a measure of frequency drift relative to temperature which follows a roughly parabolic curve from -10C to 60C, centered at 25C. The range where you can expect 1ppm of drift ranges from 19C to 31C. 4ppm of drift is expected over the range from 14C to 36C.

Our SAMD21 Feather's don't actually use a crystal oscillator to generate the clock. They have an internal Phase-Locked Loop (PLL) that oscillates at a nominal 96MHz and is divided down to a 48MHz CPU clock. The clock system then counts CPU clock ticks between ticks of an external 32,768Hz crystal clock, and uses the variation in counts to tune the PLL frequency. Basically, the crystal oscillator tunes the PLL frequency every 30.5 microseconds.

Under those conditions, the SAMD21 datasheet lists a typical 48MHz clock jitter of 1.5% and a maximum jitter of 2%.

The internal 8MHz oscillator is spec'd for +/-1% drift relative to temperature and +/-2% drift relative to the supply voltage. The PLL is made from the same kind of components, so its raw drift (corrected out by the crystal) should be roughly the same.

Bottom line, the CPU clock on a Feather isn't suitable for measuring time at the microsecond level.

As an aside, the standard assumption is that any value has at least 10x coarser granularity than the device that measured it. The value "4066.568ns" implies the existence of a clock (and measuring system) stable to +/-100 femtoseconds. For reference, a photon moves 3 nanometers in 100fs.. about 1% the wavelength of UVB light.

If you have a good 100MHz reference clock, truncate your values at a tenth of a microsecond. Any digits beyond that are meaningless and misleading. The ideal-value math taught through the first couple years of college, along with calculators, have done terrible things to numeric honesty.

User avatar
albertovalero
 
Posts: 3
Joined: Fri Jan 13, 2023 9:04 am

Re: LORA communication latency

Post by albertovalero »

Thanks for the replies.
You are right, the value "4066.568 ns" is the raw measurement obtained in the fit and of course it is not real.
We are using a 125 MHz clock with a tolerance of 50ppm in the FPGA to measure those times. Thus, as you mentioned, we cannot measure anything below 8 ns.
Anyway, we are far from that value since the point is that we observe variations of 4 us for the same transmission (same conditions, antenna orientation, temperature and package data).
I

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: LORA communication latency

Post by adafruit_support_mike »

albertovalero wrote: Tue Jan 17, 2023 6:48 am We are using a 125 MHz clock with a tolerance of 50ppm in the FPGA to measure those times.
According to the histogram, your average transmission is about 26.6ms. A 50ppm tolerance on 26.6ms is +/-1.33us.. maybe a third of the calculated standard deviation.

It's also unsafe to assume 50ppm will be evenly distributed across a 125MHz clock as 8ns cycles with an offset of +/-400ps that stays reasonably constant over periods of a few seconds. The clocks in digital processors make sure one thing happens after another with adequate clearance for setup and hold times, but little more. Check your FPGA datasheet to see if there's a spec for clock jitter.

Try benchmarking your system by having the microcontroller generate pulses at 40Hz and having the FPGA measure those. That will take the whole radio link out of the loop. You can also use a signal generator putting out a 40Hz square wave to get rid of the second CPU clock. That should have good enough short-term frequency stability to give you useful measurements.


Even assigning all the variation to the radio link though, it's important to remember that you're using a software-defined radio protocol. Those are much more complex than just picking up a carrier wave. Among the techniques are randomized keying and frequency hopping, which pay for themselves by allowing hundreds or thousands of devices to operate in the same radio footprint without interfering with each other. LoRa is proprietary, so I don't know the exact set of techniques they use, but in addition to the standard wideband tricks it offers long distance at low power. That strongly suggests some amount of error checking and self-correcting encoding.

You might find it useful to put a pair of SDR modules near the transmitter and receiver to get a better look at the actual signals.

Also, remember that the nominal bitrate of the packet radio modules is 19.2kbps. That comes to about 52us per bit, putting the variation you've measured at about 1/10th of a bit. From a design standpoint, that's a reasonable value. If the variation was much higher, transmission would be less reliable. If the variation was significantly lower, the radios could transmit at a significantly higher rate.

User avatar
albertovalero
 
Posts: 3
Joined: Fri Jan 13, 2023 9:04 am

Re: LORA communication latency

Post by albertovalero »

We have certified the time measurement in the FPGA with an external signal generator and we are able to measure times between pulses edges in steps of 8 ns as expected.

I understand that there are components in the communication protocol of this SDR module that are not under control and they could be the source of the indeterminism in the propagation time.

Do you know which other wireless protocol could we use to obtain more consistent propagation times?
We don't need shorter propagation times but we do need that the time is always the same with variations below 1 us or better.

Thanks a lot for your help

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: LORA communication latency

Post by adafruit_support_mike »

You'll probably have to give up on anything that uses broadband. Too many of the techniques in that realm use some kind of time modulation, and I don't know any that consider uniform latency a design goal.

For the sake of eliminating complications, it would probably be best to find a transmitter/receiver set that uses plain old On-Off Keying (OOK). The other options are Amplitude-Shift Keying (ASK), Frequency-Shift Keying (FSK), and Phase-Shift Keying (PSK). FSK is popular because it has higher immunity to noise and interference, but it takes a certain amount of time to identify a frequency shift. OOK is probably the most bulletproof in terms of fast and reliable detection.

Locked
Please be positive and constructive with your questions and comments.

Return to “Wireless: WiFi and Bluetooth”