Feature: Handle CRC errors

[morganrallen]

At present, when a CRC error is reported from the device the packet is silently dropped. It would be extremely helpful to report this error to the user for a number of reasons. Firstly, just to know there is an issue, maybe radio settings can be adjusted to improve reception. Secondly, as per page 40 of the SX127x datasheet...

At the end of the payload, the RxDone interrupt is generated together with the interrupt PayloadCrcError if the payload CRC is not valid. However, even when the CRC is not valid, the data are written in the FIFO data buffer for post processing. Following the RxDone interrupt the radio goes to Standby mode.

This means if the packet has some other layer of validation it might be recoverable, or in the case of human readable text, can just be pass to the user for big brain processing.

Suggestions for handling. In sync mode via parsePacket we are currently not using error codes of any sort as that function returns int packetSize. We could utilize <0 to signify error states. Alternatively we could add an error flag to the LoRa object to be checked if parsePacket returns 0. Could look something like...

if(LoRa.parsePacket() == 0) {
  if(LoRa.parseError & LORA_ERR_CRC) {
   while(LoRa.available()) ... // do stuff with malformed packet
  }
}

For async methods (using onReceive) it makes sense to add an error handling callback. Error codes can be shared with those above and would be passed to a callback handler specifically for errors. This would require registering a handler with onError similarly to how onReceive and the new onTxDone handlers work.

[IoTThinks]

Agree.
Currently we can not tell why the packets are "missing"

Sometimes even if we can receive the packets but we can tell they are corrupted from naked eyes.

A CRC flag will be helpful.

[artemen]

Currently if we are in a receive mode we have onReceive callback registered, and if we register onError at the same time as far as I understand we won't be able to diffentiate between the two, or we would have to use another DIO pin?

[morganrallen]

There is no interrupt for an error, the internal receiver interrupt would be triggered as normal but when the CRC_ERROR_MASK is detected onError would be called instead of onReceive

See https://github.com/sandeepmistry/arduino-LoRa/blob/master/src/LoRa.cpp#L663

[artemen]

Great! Would we still be able to read the sync word of the partial packet, thanks!

[morganrallen]

Right, additionally you can still read the corrupt packet. In some cases it might still be useful.

[artemen]

Thanks for the reply, i understood from your original post that even crc failed packet is still available in FIFO, what concerns me the most is if there is a way to make sure that the corrupted packet was intended to us ie it had the correct pairing code. Thanks again!

[SoothingMist]

Have used in-message CRC when feedback on drops is needed. In this case, on-chip CRC is disabled. Example code is found under this GitHub project under the directories CRC and ErrorDetection.