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?
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.
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 LoRaWAN gateways and concentrator boards - #37 by fandrit, 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.)
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.
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.
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)
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.
Is there any way to filter these CRC failed -unnecessary- packets on the gateway to lower the gateway traffic ? Are we able to add our devices something like devAddr or devEUI whitelist on gateway ?
If gateway does not send CRC failed packets LNS traffic will be lower. I think there is no need to send packets that LNS wont handle.
Typically yes depending on gw type and packet forwarder used…can you be specific.
Also, white listing generally frowned upon as breach of TTN Manifesto and fair use…you have no way of knowing which e.g. devaddr are valid and should be carried by the gw. Whilst the e.g. 26xxxxxx are obvious hold in mind fact TTN also support/allows use of experimental node (00/01xxxxxx), and with the advent of e.g PacketBroker or network roaming a ‘foreign node’ may also be legitimately handled as a valid device with its messages being passed on to the home network. If you wish to use the free TTN backend then the reciprocal arrangement is that you must allow the free passage of all messages irrespective of source or content and without technical limitations… if you wish to white list you need to set up own NS/AS/JS backend and associated integrations or move to another network. If you have a fleet of GW’s vs just one maintaining and updating a white list instance at each and every gw can be an administrative PITA…
Whitelisting and blocking “ ‘cause it’s my gateway” is a regular topic and we tell all the same… Forum Search…
Yes. The only gateways that is misconfigured out of the box in this regard that I am aware of are MikroTik devices. And those have a tickbox (not called CRC IIRC as that would be convenient) that needs to be unticked.
No. Not on you average gateway. Search the forum if you want to know why it is a bad idea anyway, discussions on that subject have been popping up every few months for years.
Hi,
