本文主要是介绍【LoRa】打开硬件CRC校验功能,但没有起作用?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
- 1 前言
- 2 解析
- 3 结论
1 前言
在使用LoRa模式(非FSK)时,可能遇到明明RX端已经打开CRC校验了,为什么payload错误了,没有报CRC error中断?本章就这个问题展开讲讲,如何正确使用芯片的硬件CRC校验,并延申到CR和payload length的使用。
2 解析
确实存在前言中的现象,前提是使用的explicit header模式,即有header模式,这样的话RX端的CRC有没有被打开取决于TX端的配置,而不是RX的配置。要讲清这个问题,还是需要先将LoRa的物理协议贴出来分析,如下图。
在LoRa协议组成中,有一部分为header,其中header由四部分组成:
- length指本包payload的长度,不包含其他的。
- CR指本包对payload和payload CRC部分所采用的编码值,由代码配置。
- Has CRC指本包是否启用硬件CRC校验。
- Header Checksum指header中三部分几个symbol的CRC校验值,由于header传输的都是重要并不允许出错的值,所以header单独校验,并使用最严编码CR=4/8。
重点来了,TX端发LoRa包,RX端接收到header时,会读出length、CR和Has CRC,并且RX会按照读出来的结果去使用,不管RX端在代码中如何配置的,所以说这三个值取决于TX端。
3 结论
- 出现前言中提到的问题的原因是在TX端关闭了CRC校验,在RX端打开了CRC校验,认为应该有CRC校验,但实际上CRC校验是去决于TX端的配置。
- 同理,CR和payload length的配置也是取决于TX端。
- 如果是implicit header,也就是无header,那就是取决于RX端自己的配置了。
总而言之,其实这个问题很好避免,就是写代码的时候遵循代码规范,TX端和RX端配置参数都使用一样的即可。
这篇关于【LoRa】打开硬件CRC校验功能,但没有起作用?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!