【LoRa】打开硬件CRC校验功能，但没有起作用？

1 前言

在使用LoRa模式（非FSK）时，可能遇到明明RX端已经打开CRC校验了，为什么payload错误了，没有报CRC error中断？本章就这个问题展开讲讲，如何正确使用芯片的硬件CRC校验，并延申到CR和payload length的使用。

2 解析

确实存在前言中的现象，前提是使用的explicit header模式，即有header模式，这样的话RX端的CRC有没有被打开取决于TX端的配置，而不是RX的配置。要讲清这个问题，还是需要先将LoRa的物理协议贴出来分析，如下图。


在LoRa协议组成中，有一部分为header，其中header由四部分组成：

1. length指本包payload的长度，不包含其他的。
2. CR指本包对payload和payload CRC部分所采用的编码值，由代码配置。
3. Has CRC指本包是否启用硬件CRC校验。
4. Header Checksum指header中三部分几个symbol的CRC校验值，由于header传输的都是重要并不允许出错的值，所以header单独校验，并使用最严编码CR=4/8。

重点来了，TX端发LoRa包，RX端接收到header时，会读出length、CR和Has CRC，并且RX会按照读出来的结果去使用，不管RX端在代码中如何配置的，所以说这三个值取决于TX端。

3 结论

1. 出现前言中提到的问题的原因是在TX端关闭了CRC校验，在RX端打开了CRC校验，认为应该有CRC校验，但实际上CRC校验是去决于TX端的配置。
2. 同理，CR和payload length的配置也是取决于TX端。
3. 如果是implicit header，也就是无header，那就是取决于RX端自己的配置了。

总而言之，其实这个问题很好避免，就是写代码的时候遵循代码规范，TX端和RX端配置参数都使用一样的即可。

3.1 延申

在网关芯片SX1302中，对multi-channels(0-7)也没有CR的配置，因为它的CR值也是取决于发送端的header中的配置。