terrillmoore
commented
4 years ago @manuelbl what a great test tool! Thanks for the careful work!
I assume the LoRa device you are testing is using an ESP32 or some other device with a 100 ppm or better system clock, rather than the Murata module (which has a 4000ppm system clock).
No errors that I can see; I came to the same conclusions about timing by analysis, and by my somewhat different approach using rwc_nst_test. I can also tell that you are testing with HEAD (3.0.99.10 or later), based on the timing.
You have experimentally confirmed exactly the timing that I designed after finding the results summarized at https://github.com/mcci-catena/arduino-lmic/issues/483#issuecomment-568632897. The key finding was that, with noisy environments, the packet loss rate was much higher if I delayed the start-of-RX by several symbols into the transmit preamble, for example:
https://user-images.githubusercontent.com/19333103/71427763-f7eb7600-2689-11ea-8cab-390b06a7601f.png
This doesn't reproduce, by the way, with pristine environments, but was pretty reproducible in an unintentionally noisy environment.
The comments in the mbed code referenced in #438 (https://github.com/ARMmbed/mbed-os/pull/8822/files) suggest that Semtech was having problems with similar things; they effectively moved their low-speed window into one of the nulls of the picture above.
Based on this, and the observed data integrity problems, I moved the window earlier than Semtech.
Keeping the window short (in terms of RX syms) is generally good if you can get away with it; the reason Semtech makes it longer is because of the inaccuracy in the millisecond timer you mention. (You have to open up the window if you don't know when it's happening). It's a power thing.
However, we have to also take into account clock accuracy. 100 ppm clocks are typical, but 4000ppm clocks are not uncommon (stm32l0 HSI clocks, for example). This complicates join accept timing, which may be delayed six seconds.
I did calculations with a 100 ppm clock, and I found that my nominal calculations worked out (I hope someone will double check) but wiht a 4000 ppm clock, the timing blows out (even on the lmic) exactly as described. Please try using LMIC_setClockError() to set a 4000 ppm error, and you'll see that the rxwindows at high speed blow up exactly as you show.
If you open the window too late, you won't get enough preamble. I experimentally verified that, using an SX1276 to transmit, the window closes hard 4 symbols after the start of transmit. But the SX1276 is documented as transmitting 10 symbols of preamble by default; and other places state that it requires 6 symbols of preamble to sync up. (So this matches.) Here's a picture:
The documentation available is confusing and contradictory, and I couldn't get a good timing reference from the RWC5020, but I believe that the gateways transmit either 8 or 10 symbols of preamble. (I assume that for downlink they'd reduce this if they could since downlink time is relatively precious.) So my formulas assume that the window is only 8 symbols, and that means we need to land somewhere in the first two symbols. In fact, because of my experiments, I determined that the radios I have performed the best if the RX windows was already open when the preamble appeared, possibly because the PLLs have stabilized. That biased me to the beginning of the window. I also subtracted 2 ms because it takes 2 ms for the power amps and analog circuits to turn on (again, this isn't well documented, but I found lots of anecdotal evidence; and in the picture above, you can see that integrity starts to go down as you get close to the right hand side of the window (as a starting time).
Another relevant fact: it actually doesn't matter much if you're a little early, because the hard stop is the end of the preamble. If the SX1276 starts seeing a preamble during the RXSYMS timeout period, it will say "I have a preamble" and will go on to receive the packet. I didn't experimentally measure how many symbols of overlap you have to have, but I believe it is 4 symbols.
If you aim to land at time t, and the absolute value of your clock error is e (0 being perfect), then you might land at t_late = (1 + e)*t. To avoid this, you need to choose t_adj = t/(1 + e). (The LMIC approximates this as t_adj_lmic = (1-e)*t.) But, in fact, your clock might be fast. In this case t_early = (1 - e) * t_adj, which is (1-e)/(1+e) * t. (The LMIC approximates this as (1-2e)*t.)
So the LMIC, on the assumption that it might be slow moves up t to t_adj.
Then, on the assumption that it might be fast, it extends the rx window (in units of rxsyms) until it is sure that there is an overlap.
The Semtech and mbed formulas try to "reduce power" by opening the rx window as late as they can (so as to waste less power during preamble time). The fact is, however, that RX downlinks for Class A devices are rare; so it doesn't matter how late you open the window for a successful rx, it matters how long you open the windows for failed rx.
manuelbl
cyberman54
I finally had time to complete the SX127x Probe, run sufficient tests, compare LMIC and Semtech code and come up with some findings.
Probe
The SX127x probe is a STM32 MCU that I can connect to a SX127x chip/board in parallel to the MCU that controls it. It observes the SPI communication (MCU to SX127x only) and the DIO0 and DIO1 pins. Based on the observations, it can measure and analyze many timing parameters – in particular the RX windows that are so essential for joining and downlink packets. The output (on a UART TX pin) looks something like this:
The interesting parameters are the computed margin at the start and at the end. It's a measure by how many µs the MCU (or the the gateway) could be early or late and the transmitted packet would still be successfully received. Except for power consumption, the bigger the margin, the better. For the best robustness, the margins at the start and end should be equally long. The conceptual model is described in more detail in the README.
Findings
Timing accuracy
The first finding was that the LMIC code is very repeatable in executing an action at a certain time, within about 2µs. The SemTech code (https://github.com/Lora-net/LoRaMac-node) is only accurate within 1ms, about 500 times worse. This is not surprising as all time values are rounded to 1ms internally. As it turns out, it's still sufficiently precise.
RX window offset and length
LMIC and SemTech use two different formulas to determine when the RX window should start and how long it should be. I've simplified the formulas somewhat (no rounding, no drift). At the core they are:
tSymbol is the length of a symbol. It depends on the data rate.
tWakeUp is the time the SX127x needs to wake up (process the command to start receiving, stabilize the frequency etc.). It is set to 1ms. According to my observations, the wake up time is about 300µs.
The SemTech window is obviously much longer. Independent of the data rate, they have a total margin of about 40ms while LMIC has only 2ms.
The purpose of the SemTech formula for the window offset isn't obvious at first sight. It has been chosen such that the margins at the start and at the end are equally long. So it seems that SemTech's timing is based on the same conceptual model.
The effective values for the different data rates (for EU868) are shown below. They use the more complex formulas with rounding. And they match what I have observed by hooking up the probe to a circuit running with the respective software.
SemTech
The slight difference between the length of the start and end margin is due to rounding and due the a more precise model regarding wake up. But given the 1ms resolution of SemTech's code and the 20ms margin, it's not relevant.
LMIC
The LMIC margins are asymmetric and differ considerably depending on the data rate. For higher data rates, the margin at the end is low.
Conclusions
Even though the LMIC margins are narrow, it still worked. But it could make sense to adopt a formula similar to SemTech's, i.e. a more or less fixed and symmetric margin independent of the data rate. It would probably increase robustness without sacrificing low power consumption.
@terrillmoore I'm interested in your feedback. Is the analysis understandable? Do you see an obvious errors?