Lots of CRC status errors in a new Gateway - normal?

png Hi,
I just came down from the roof, where I installed a new Mikrotik Gateway with a RN11e Lora card.

In the lokal gateway traffic I see a lot of CRC errors, related to unknown, week nodes. My own node is received correctly (not in the picture).

I assume the signals are fake, because I live I a steep mountain valley and suppose to be the first lora user here. Or can this really be week lora signals, reflected on the mountains ans therefore produce a faulty signal?
A friend of mine started with the same gateway in another place and has the same errors.
Is this a normal behavior? Hoe to proceed further to debug?

Happy Christmas!
Martin

Maybe some other devices like garage doors may use some LoRa(like) signal are not intended for this LoRaWan.

It’s unclear which messages are showing CRC errors, but examining all available details for the erroneous ones would help narrow things down. For example if they are labelled proprietary you could look at he raw contents (likely you’ll need to base64 decode them) and see if there seems to be any sort of pattern.

Generally speaking though they aren’t something to worry about, unless they represent recognizable traffic that you feel you should be able to receive without frequent error.

Not sure about everyone else, but I have no idea what you mean by ‘lots’ of CRC errors.

I’m seeing the same thing. I’m picking up roughly 10 packets in 10 minutes. Message types are from all different types, from join requests and accepts to data up/downs. I tried decoding some of the Proprietary messages, with no luck.
For instance this payload: //7/+BDhweUNFy+evHjxQ8aNfBRo0KBBgAECBNURk0SEHDj3LsZeSUB4i1Loz3s5p0lkobwHMqQ/edwKBjIV77qWfmZW1/esRaHMPgTymuDLCRgQfIB7Tbqh/4mF6n5vi5xlrBqDSYQScgxnV2M2jAfpgCFU4Emtd/yg3J/xhWTXOWf5ATKO7Dude3rJ0mL16V9Q9syYMWLVmge4i7BpkqRIkSJVmwU4UqVKlTt1qVOnTg==
Results in this ASCII ÿþÿøáÁå /ž¼xñCƍ|hÐ A€Õ“D„8÷.Æ^I@x‹RèÏ{9§Id¡¼a2¤?yÜ 2ﺖ~fV×÷¬E¡Ì>òšàË |€{Mº¡ÿ‰…ê~o‹œe¬ƒI„rgWc6Œaé€!TàI­wü ܟñ…d×9gù2Žì;{zÉÒbõé_Pö̘1b՚a¸‹°i’¤H‘"U›8R¥J•;u©S§N

This seems to only affect Mikrotik gateways. I have not seen anything like this with TTIG nor Lorank8

image

How many good packets are you seeing in 10 minutes ?

None, at the moment. I have no real LoRa devices in the vicinity.

Individual loRa devices, SX1276 etc, do produce a number of false packets from internal noise. How they are dealt with depends on the software, but typically will show up as packets with CRC errors. For a single device, maybe 10 false packets (phantoms) an hour is not unusual.

Whether multichannel gateways are affected by the same issue, I do not know.

A similar case was seen in Mikrotik R11e-LoRa8EU & wAP LoRa8 kit, also for unknown sources. Though it was assumed that LoRaWAN devices were around, once new nearby LoRaWAN devices were actually added, their traffic was received just fine.

So, I’d say, no worries so far!

And an aside:

I guess you know that it would be bad practice to send text. That’s not only true for LoRaWAN, but also for plain LoRa. Also, that Base64 encoded representation decodes to a whopping 178 bytes. Though supported on low SFs, I still feel that’s much more than a typical LoRaWAN packet would/should be.

And of course: as the CRC failed, there’s not much use in trying to decode it. So, the web interface is also giving you false information like “Confirmed Data Up”, “Rejoin-request” and all. (And even for valid LoRa packets, which might still not be LoRaWAN, the web interface might give you the wrong details as it just assumes everything is LoRaWAN.)

Ah, I remember your nice write-up about that: Phantom Packets. A teaser quote and image:

If that is the case how can it be that the CRC is valid for about 70% of the phantom packets?

tunnel

Thats the point, the lack of the CRC flag not being set to ‘not valid’ does not mean the packet has a valid CRC, it can mean there is no CRC sent with the packet.

If a random packet arrives, that has the no CRC flag set in the header, the CRC is not checked and the CRC not valid flag is not set.

If you leave a SX1276 running on continuous RX, it will detect ‘packets’. The give away is that they are normally right on the reception RSSI and SNR limits.

1 Like

That’s not necessarily true. A packet could have only a few errors and still be generally recognizable, especially as a pattern.

The real mistake was in trying to decode it to ASCII, not so much because ASCII is a bad payload format (though it is) but because the framing information that would help indicate a pattern of traffic is not ASCII.

If someone wants to analyze these, base 64 decode them, hex dump them, let that accumulate for an hour and then sort the lines which will match things that start similarly (a sort isn’t a great algorithm for that, but it is an available one)

If that yields bunches of packets that start with some similarity, its probably more than noise.

1 Like

I’m also getting some CRC errors on my lora8 kit. (I only have one device in range. And that one works correctly. So don’t know anything about those other devices)

Type Time Gateway ID Message Type Dev Addr Freq (MHz) Modulation Bandwidth Datarate Coderate CRC Status RSSI (dB) SNR (dB)
Rx Jun/26/2020 16:01:25 3133303747002A00 Unconfirmed Data Up 26 01 2F 34 867.500 LoRa 125 kHz SF 12 4/5 Ok -103.00 -18.00
Rx Jun/26/2020 16:01:37 3133303747002A00 Join-accept 66 87 F3 00 868.300 LoRa 250 kHz SF 7 4/5 Error -104.00 -10.50
Rx Jun/26/2020 16:01:41 3133303747002A00 Confirmed Data Up 4D 9C 12 F7 867.100 LoRa 125 kHz SF 7 - Error -109.00 -11.50
Rx Jun/26/2020 16:02:04 3133303747002A00 Confirmed Data Down E6 D7 17 58 867.500 LoRa 125 kHz SF 7 4/6 Error -103.00 -12.25
Rx Jun/26/2020 16:04:37 3133303747002A00 Join-request 868.500 LoRa 125 kHz SF 7 4/7 Error -107.00 -12.00
Rx Jun/26/2020 16:06:25 3133303747002A00 Unconfirmed Data Up 26 01 2F 34 868.500 LoRa 125 kHz SF 12 4/5 Ok -107.00 -6.25
Rx Jun/26/2020 16:06:51 3133303747002A00 Confirmed Data Down A8 9D 6B 9A 868.300 LoRa 250 kHz SF 7 4/6 Error -104.00 -11.50
Rx Jun/26/2020 16:08:45 3133303747002A00 Confirmed Data Down 1B BC BF 7E 868.300 LoRa 125 kHz SF 7 4/8 Error -105.00 -11.25
Rx Jun/26/2020 16:10:58 3133303747002A00 Unconfirmed Data Down 62 F5 34 B7 867.100 LoRa 125 kHz SF 7 - Error -109.00 -11.50
Rx Jun/26/2020 16:11:25 3133303747002A00 Unconfirmed Data Up 26 01 2F 34 868.300 LoRa 125 kHz SF 12 4/5 Ok -107.00 -8.75
Rx Jun/26/2020 16:12:26 3133303747002A00 Join-request 867.300 LoRa 125 kHz SF 7 4/7 Error -105.00 -12.00
Rx Jun/26/2020 16:19:53 3133303747002A00 Proprietary 867.300 LoRa 125 kHz SF 7 4/7 Error -107.00 -12.25
Rx Jun/26/2020 16:21:25 3133303747002A00 Unconfirmed Data Up 26 01 2F 34 867.900 LoRa 125 kHz SF 12 4/5 Ok -107.00 -13.75
Rx Jun/26/2020 16:22:25 3133303747002A00 Proprietary 868.500 LoRa 125 kHz SF 7 4/7 Error -107.00 -12.00
Rx Jun/26/2020 16:26:25 3133303747002A00 Unconfirmed Data Up 26 01 2F 34 867.100 LoRa 125 kHz SF 12 4/5 Ok -110.00 -7.00
Rx Jun/26/2020 16:27:44 3133303747002A00 Rejoin-request 867.500 LoRa 125 kHz SF 7 4/7 Error -105.00 -10.75
Rx Jun/26/2020 16:31:11 3133303747002A00 Join-accept C3 23 32 60 868.300 LoRa 250 kHz SF 7 - Error -103.00 -12.00
Rx Jun/26/2020 16:31:25 3133303747002A00 Unconfirmed Data Up 26 01 2F 34 868.300 LoRa 125 kHz SF 12 4/5 Ok -105.00 -9.50
Rx Jun/26/2020 16:33:02 3133303747002A00 Rejoin-request 867.500 LoRa 125 kHz SF 7 4/6 Error -104.00 -12.00
Rx Jun/26/2020 16:36:25 3133303747002A00 Unconfirmed Data Up 26 01 2F 34 868.300 LoRa 125 kHz SF 12 4/5 Ok -104.00 -10.00
Rx Jun/26/2020 16:38:25 3133303747002A00 Join-accept 0F A3 E1 74 868.300 LoRa 125 kHz SF 7 4/8 Error -102.00 -10.75
Rx Jun/26/2020 16:38:44 3133303747002A00 Rejoin-request 868.500 LoRa 125 kHz SF 7 4/8 Error -101.00 -12.00

If packets from your device are still getting through, then there’s probably no issue, these other signals may be from things using different air settings, or may not actually be LoRa at all.

However do make sure your device is not extremely close to the gateway - especially if the CRC error packets correlate in time with the good packets from your device.

There does appear to be a way for the chip in a concentrator to get “stuck” in a bad mode where it reports CRC errors constantly and no good packets, until the packet forwarder software (or entire gateway) is restarted. My guess would be that this happens due to a glitch on the SPI mis-setting a register, but thermal issues have also been proposed but there doesn’t seem to be evidence in favor of that.