If your using some of the standard LoRa libraries for Arduino for instance, you may want to check your not being impacted by phantom packets, see here for an explanation and possible solution;
2 Likes
what library(s) did you see that happening ? is it LoRA/LoRa communication or do you also see those phantompackets in the TTN console ?
It was spotted whilst testing point to point links, dont know which libraries might be affected.
Although LMIC is affected I think.
interesting and difficult to reproduce
No it’s not difficult to reproduce. Take a “Bare” LoRa module and put a 50 Ohm (SMD) resistor directly over it’s antenna connector. Hook it up to a controller with a SD card, wrap it in plastic- and aluminum foil and then dump it with a battery in the tin-plated cookie jar to act as a kind of poor man’s Faraday cage. That, and patience , is all it takes. By using various carrier frequencies, different controllers at different clock-rates I made sure I was not seeing MMI.
At the chips default (Bw125 kHz, cr 4/5, sf 128) you get about 2 stray packets/hour. Varying bandwidth varies the occurrence rate and, no surprise, the reported RSSI. See the graphs below.
There is a bit of noise in the data, most likely due to the 24 hour sample period not being long enough yet.
Varying the other parameters and logging what’s happening is taking time and on-going. Preliminary result is that with increasing cr and sf the occurrence rate is dropping. And that makes sense.
The RadioHead library for RF95’s is affected. It’s easy to modify as per the write-up in http://www.loratracker.uk/?p=782. Since then I’ve not seen any stray decodes anymore which did not got flagged as bad. But testing is ongoing.
1 Like
’ poor man’s Faraday cage ’ … love it 
Can you conclude it’s a hardware bug on chiplevel ?
No I can and will not conclude it’s a hardware bug at chiplevel.
Granted, decoding LoRa packets originating from noise is not the first thing what jumps to mind if you observe stray packets. But if you look at the sensitivity numbers specified by Semtech it’s, in hindsight, no big surprise.
After-all it’s not a Nitrogen or Liquid Helium cooled front-end, just a consumer chip at room temperature.
The CRC handling for the payload is described in the datasheet of the SX127x chips.
The description of the CRC protection implementation for the header is also there but the length of the CRC used is missing. Jumping to conclusions was to assume that it’s also a CRC16.
However it’s all overhead and not much data so the choice for a CRC6 for the header is understandable.
I needed to read those sections of the datasheet a few times but observations from the received stray packets so far match what’s described. It just takes the proper code to handle it.
Now is that my understanding of datasheets or the clarity of them? I’m not going to take a vote for it.
Well as @pimn has noted, its a very easy problem to reproduce. Once you have accepted the effect by eliminating the possibility of LoRa packets from the outside world, you will see it on any receiver you have just listening.
I dont think its an issue that was expected, and its perhaps rare enough that its simply gone un-noticed before.
If the CRC flag was a flag that indicated a valid CRC, and was only activated when the packet had indeed passed a CRC check, the the issue would be reduced by a factor of approximately 65536, so one phantom packet ever 7 years or so.
I ran a couple of seperate receivers over a few days, with the appropriate modifications to the software, all of the many phantom packets received were rejected.
I did take a brief look at some of the devices that use Micro Python code, it did look like they were affected too.
IMHO, Arduino-LMIC is not doing Lora CRC validation at all.
Neither in Matthijs Kooijman’s repo nor in more recent Terry Moore’s fork
I had these “phantom” packets at rate of 1-3 per hour until I’ve developed this fix.
1 Like
Interesting, although its not RF noise in the sense of stuff coming in from the outside, but noise from the receivers own silicon.
I would say that when I first started looking for the cause there were those that made an assumption it was just external interference.
I’m wondering… can the same occur inside a GW or will it be filtered before sending to backend.
It could, depending on the Gateway software.
If the software was writtten in the style that allowed for both CRC checked packets and non-CRC checked packets, then the routines will already be working around the problem (probably without realising it) since you need to check the CRC enabled flag in the header to know whether to check the CRC or not.
If the library makes an assumption that its always going to use CRC checked packets, and with so little overhead to using CRC that is a natural assumption, then its likley the CRC enabled bit in the header is not checked. So when the CRC error flag remains low (due to noise producing a false header) you further assume that the packet is good.
Encrypted packets should not suffer from this problem, they might be received but would fail de-crypt.
1 Like