Garbage Uplink messages with IMST Lite Gateway

1

I don’t think following is a problem, but rather an observation.

I seem to receive a bit of garbage uplink messages on my INST Lite gateway running the newest Gateway OS.
I have witnessed similar behavior with MikroTik Gateways: They displayed/sent random garbage uplinks when CRC-check was disabled (which is the default setting).

So I guess that Gateway OS also forwards messages with faulty CRC (just like the MikroTik default setting does) ? If yes, can CRC-check be enforced so that messages with faulty CRCs will be discarded?

*EDIT *
added on 2-Sept-21:

Sorry , I was not specific enough.

I refered to the three UPLINK messages shown in the picture on line 3, line 4 and the last line.
These are garbage.
The status/heartbeat messages every 30s are fine.

image
image1426×564 44.2 KB

2

This is intentional - see setting, under Gateway-profiles, called “Stats interval (seconds) *” that normally recommend/defaults to 30 seconds - note that the time-stamp of your “garbage” messages is every 30 seconds :slight_smile: Exception to the ‘every 30 seconds’ are uplink packets, driven by sensors.

Current ChirpStack documentation doesn’t seem to discuss this particular setting (which could be improved). Only mentions are on HERE and in change log.

3

Sorry , I was not specific enough.

I refered to the three UPLINK messages shown in the picture on line 3, line 4 and the last line.
These are garbage.
The status/heartbeat messages every 30s are fine.

4

SNR & RSSI of these uplinks indicate they’re relatively far from your gateway(s) - did you see THIS?

This is a good reference on wonders of LoRaWAN that make this possible.

5

The Uplinks shown in my picture are erroneous messages produced by some 868MHz noise.

As I wrote earlier:
I have witnessed similar behavior with MikroTik Gateways: They displayed/sent random garbage uplinks when CRC-check was disabled (which is the default setting).

So the questions remains: Is there a CRC-check in Gateway OS?

6

I think we will agree to disagree: I find the idea of truly “spurious” uplink messages hard to believe. This is because LoRaWAN already supports (read notes at the link):

  • Message Integrity Code (MIC).
  • Fcnt to monitor that frames are not out of sequence/not missing.
    In my opinion, these are superior to CRC.

That said, there is a place for Forward Error Correction, which is a different animal than CRC, because you should expect 10% of your frames to be lost (worst case). I have not observed this in my “middle of nowhere” locality.

I am currently using Fcnt to check for missing and out-of-sequence frames, but only for more important process data.

7

Random garbage or beyond range LoRaWAN or other traffic triggering the preamble detector is a known reality. (It’s also pretty common when a node is so close that it overloads the gateway’s receiver)

To combat that, below the level of the “software” integrity checks you are speaking about, LoRa radio hardware also implements its own CRC.

Just about all packet forwarder software reads the CRC validity bit from the message buffer it extracts from the concentrator chip, has the capability to drop packets with CRC errors (but count them in a total of such) and most commonly is configured by default to do that dropping, though it can be disabled.

The asker wants to enable this very standard mode where CRC error packets are not forwarded.

Sure, those are essentially always going to fail software validation, too, and the uplink records have metadata including the fact that a hardware CRC error was present, so a network server wouldn’t naively accept them even if the MIC and frame count where somehow unluckily legal.

But there’s still benefit in keeping random noise off the backhaul feed - and the bad packets still get counted in the periodic gateway statistics reports.

2 Likes
8

Thanks for the detailed answer cstratton.

So I guess the question remains: Can CRC-check be enforced in Gateway-OS so that messages with faulty CRCs will be discarded?

9

Presumably, but I don’t know how, or even exactly what you’re running.

In classic packet forwarders this was a setting in the global_conf.json

     /* forward only valid packets */
    "forward_crc_valid": true,
    "forward_crc_error": false,
    "forward_crc_disabled": false,

If I look in the source for Chirpstack concentratord, to my unfamiliar eyes seems to have hardcoded logic to always drop CRC error packets.

Are your running an IMST image on the gateway?

10

Are your running an IMST image on the gateway?

Nope, running the newest Gateway OS, with packet forwarder set to TTN V3.