Disclaimer: I work on a vaguely similar project (LoRaMaDoR).
Even using the native LoRa FEC, the occasional corrupted octet shows up from time to time, even under the best of conditions and even if you max out the redundancy. LoRa FEC is very simple, good for hardware, but we can to way better in software. Compounding this with LoRa native CRC, too many packets are lost due to single-bit errors.
In my tests, the best results were obtained by disabling LoRa CRC and using Reed-Solomon FEC in software. No packet is lost to trivial errors, there is palpable coding gain in marginal RX, and (depending on the RS redundancy level) it has much stronger error detection (for uncorrectable packets) than CRC-16, guaranteeing the higher layers won't have to deal with corrupted data.
Using CRC-16 was a major mistake in vanilla APRS, which it is being corrected with FX.25.
Disclaimer: I work on a vaguely similar project (LoRaMaDoR).
Even using the native LoRa FEC, the occasional corrupted octet shows up from time to time, even under the best of conditions and even if you max out the redundancy. LoRa FEC is very simple, good for hardware, but we can to way better in software. Compounding this with LoRa native CRC, too many packets are lost due to single-bit errors.
In my tests, the best results were obtained by disabling LoRa CRC and using Reed-Solomon FEC in software. No packet is lost to trivial errors, there is palpable coding gain in marginal RX, and (depending on the RS redundancy level) it has much stronger error detection (for uncorrectable packets) than CRC-16, guaranteeing the higher layers won't have to deal with corrupted data.
Using CRC-16 was a major mistake in vanilla APRS, which it is being corrected with FX.25.