Open morganrallen opened 4 years ago
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.
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?
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
Great! Would we still be able to read the sync word of the partial packet, thanks!
Right, additionally you can still read the corrupt packet. In some cases it might still be useful.
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!
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...
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 returnsint packetSize
. We could utilize<0
to signify error states. Alternatively we could add an error flag to theLoRa
object to be checked ifparsePacket
returns0
. Could look something like...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 withonError
similarly to howonReceive
and the newonTxDone
handlers work.