Gateway Stats: rxPacketsReceived vs rxPacketsReceivedOK


#1

What is the specific difference between rxPacketsReceived and rxPacketsReceivedOK? What constitutes an “OK” packet vs one that was just “received”?


#2

The difference is the CRC status. rxPacketsReceived reflects the total number of received frames, rxPacketsReceivedOK reflects the number of frames with CRC OK status.


#3

So what is the root cause of a CRC error? Specifically, does a CRC error mean that the packet was otherwise “expected” (i.e. from a known device) but was corrupt, or can this also happen if a packet was received from an unknown device (i.e. one that may be registered to a different network in the same area, but was transmitting in the same frequency band)?


#4

This is on the LoRa PHY layer and is independent from the LoRaWAN protocol. The gateways only know about LoRa, the LoRaWAN protocol is provided by the network-server (LoRa Server). On my gateways, I (also) see a high number of invalid CRC errors. I would not worry too much about this.


#5

Hmmm. I’m concerned because I’m seeing a 60% failure rate on one of my gateways. Is there any way to diagnose this, to understand what’s going on?


#6

Not that I know, but please note that this could also be because of non LoRaWAN devices operating on the same spectrum (as the spectrum can be used by any kind of devices as it is unlicensed). E.g. the gateway thinks it sees a LoRa frame, but when performing the LoRa CRC check, the check fails. Or it could be because of LoRa(WAN) devices of which the signal can’t be correctly demodulated as there is too much noise / they are too far away. At least that is my theory.

I think the best thing to test is that your devices are working properly without (too much) packet loss.