# Phantom Packets **URL:** \ **Category:** End Devices (Nodes)\ **Created:** [June 2, 2018, 1:25pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763 "2018-06-02T13:25:52Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\ **Post date:** [June 2, 2018, 1:25pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/1 "2018-06-02T13:25:52Z")
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; > **[A LoRa Mystery – Phantom Packets.](https://stuartsprojects.github.io/2018/05/29/a-lora-mystery-phantom-packets.html)** > > I had noticed  while testing LoRa links at 868Mhz with different receiver types that I was seeing a number of ‘phantom’ packets that I did not recognise. I initally thought these were just LoRa packets from the surrounding environment. > **[A LoRa mystery – Phantom packets but deeper](https://stuartsprojects.github.io/2018/05/31/a-lora-mystery-phantom-packets-but-deeper.html)** > > Despite the shielding of my LoRa receivers being able to resist 50mW at 5cm it was possible that there could be a Megawatt LoRa transmitter somewhere close that was the cause of the phantom LoRa packets I was seeing at 868Mhz bandwidth 500khz... > **[Phantom Packets – Is this the reason ?](https://stuartsprojects.github.io/2018/06/02/phantom-packets-is-this-the-reason.html)** > > After consulting Semtech, the reason why these phantom packets are seen becomes clear. ---
**Author:** ![BoRRoZ](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/borroz/32/44234_2.png) [@BoRRoZ](https://www.thethingsnetwork.org/forum/u/BoRRoZ)\ **Post date:** [June 2, 2018, 1:39pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/2 "2018-06-02T13:39:48Z")
what library(s) did you see that happening ? is it LoRA/LoRa communication or do you also see those phantompackets in the TTN console ? ---
**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\ **Post date:** [June 2, 2018, 1:46pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/3 "2018-06-02T13:46:24Z")
It was spotted whilst testing point to point links, dont know which libraries might be affected. Although LMIC is affected I think. ---
**Author:** ![BoRRoZ](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/borroz/32/44234_2.png) [@BoRRoZ](https://www.thethingsnetwork.org/forum/u/BoRRoZ)\ **Post date:** [June 2, 2018, 1:50pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/4 "2018-06-02T13:50:07Z")
interesting _and difficult to reproduce_ ---
**Author:** ![pimn](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/pimn/32/25844_2.png) [@pimn](https://www.thethingsnetwork.org/forum/u/pimn)\ **Post date:** [June 12, 2018, 7:28pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/5 "2018-06-12T19:28:21Z")
> [@BoRRoZ](#): > > 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](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. ![image](https://www.thethingsnetwork.org/forum/uploads/default/original/2X/6/6192091c798bdb5a4dac4cf6183673d284590011.png) ---
**Author:** ![BoRRoZ](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/borroz/32/44234_2.png) [@BoRRoZ](https://www.thethingsnetwork.org/forum/u/BoRRoZ)\ **Post date:** [June 12, 2018, 8:04pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/6 "2018-06-12T20:04:19Z")
’ poor man’s Faraday cage ’ … love it 🕶 Can you conclude it’s a hardware bug on chiplevel ? ---
**Author:** ![pimn](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/pimn/32/25844_2.png) [@pimn](https://www.thethingsnetwork.org/forum/u/pimn)\ **Post date:** [June 12, 2018, 8:40pm UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/7 "2018-06-12T20:40:27Z")
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. ---
**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\ **Post date:** [June 13, 2018, 4:18am UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/8 "2018-06-13T04:18:22Z")
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. ---
**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\ **Post date:** [June 13, 2018, 4:23am UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/9 "2018-06-13T04:23:09Z")
> [@pimn](#): > > 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](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. 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. ---
**Author:** ![Linar](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/linar/32/35697_2.png) [@Linar](https://www.thethingsnetwork.org/forum/u/Linar)\ **Post date:** [June 13, 2018, 7:28am UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/10 "2018-06-13T07:28:55Z")
IMHO, Arduino-LMIC is **not** doing Lora CRC validation at all. Neither in [Matthijs Kooijman’s repo](https://github.com/matthijskooijman/arduino-lmic) nor in more recent [Terry Moore’s fork](https://github.com/mcci-catena/arduino-lmic) I had these “phantom” packets at rate of 1-3 per hour until I’ve developed [this fix](https://github.com/lyusupov/SoftRF/commit/ac7cd0b0666a0d5f2b44b72e0a128a2e41ec132c). ---
**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\ **Post date:** [June 13, 2018, 7:47am UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/11 "2018-06-13T07:47:52Z")
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. ---
**Author:** ![BoRRoZ](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/borroz/32/44234_2.png) [@BoRRoZ](https://www.thethingsnetwork.org/forum/u/BoRRoZ)\ **Post date:** [June 13, 2018, 7:51am UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/12 "2018-06-13T07:51:02Z")
I’m wondering… can the same occur inside a GW or will it be filtered before sending to backend. ---
**Author:** ![LoRaTracker](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/loratracker/32/48502_2.png) [@LoRaTracker](https://www.thethingsnetwork.org/forum/u/LoRaTracker)\ **Post date:** [June 13, 2018, 8:00am UTC](https://www.thethingsnetwork.org/forum/t/phantom-packets/14763/13 "2018-06-13T08:00:37Z")
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.