当前位置:主页 > 其它软件 > 其它 > nRF24L01+调试笔记

nRF24L01+调试笔记

作者:断线的风筝  来源:未知  发布时间:2016-04-24 16:58   浏览次数:

前几天, 我做了个智能浇花器, 其中的无线模块还是用的我两年前的方案。结合智能传感课上关于无线通信的介绍, 我觉得, 这个方案可能传输比较不稳定、不安全, 所以决定研究一下新的廉价的无线传输方法。


无线传输, 我了解到的大概有如下几种:


315MHz/433MHz 无线传输(我用的芯片是调幅的)

WiFi, 工作在2.4GHz和/或5GHz

Bluetooth蓝牙, 2.4GHz

ZigBee, 2.4GHz

nRF24L01+类似的芯片, 2.4GHz

WiFi、蓝牙和ZigBee的能力比较强, 但是模块较贵(大约10~20元一个), 不适合我使用, 于是, 我选择尝试使用nRF24L01+, 它大概3元一个。


事实上, 几年前我就注意到有一种叫nRF24L01+的模块, 不过当时没有想玩它, 现在来玩一下子。


nRF24L01+相比于我之前用的315MHz/433MHz, 采用了SPI, 所以GPIO口要求增加, 由原来的1个(表示信号有无)增加到6个(SCK、MOSI、MISO、片选、使能、中断)。同时, 数据传输速率和一次性能够传输的数据包大小也大幅度增加。另外, nRF24L01+的调制方式是带高斯低通的频移键控(GFSK), 相比于调幅可能要稳定一些。


为了加快调试, 我使用了Arduino(实际上是只会用Arduino和MSP430, 然后Arduino比MSP430简单一些)。 对于其他单片机, 差别只有GPIO口读写以及SPI的实现。


参考Arduino以及nRF24L01+的数据手册之后, 我乱搞出来了一份测试收发的程序。


测试、调试的时候, 我发现了一些问题。


问题主要出现在能够发送并接收成功, 但是发送方怎么也接收不到ack信号。


收不到ack信号可能因为接收方没有发送ack信号, ack信号传输过程中出现问题, 发送方接收ack信号出现问题。


由于没有相关无线电设备(所以我想买一套HackRF), 所以一开始我一直以为是接收方没有发送ack信号。我阅读了好几个版本的数据手册, 尝试修复, 然而并没有什么实时性进展。经过搜索, 我发现这个问题和我设置的地址有关系, 我原来设置的地址是1(00000000000000000000000000000001), 修改为较复杂的233333233(00001101111010000110000111110001)后, 发送方便可以成功接收ack信号。


这个问题让我纠结了几个小时= =


然而, 数据手册中有这么一段话, 可能和这个问题相关:


Note: Addresses where the level shifts only one time (that is, 000FFFFFFF) can often be detected in

noise and can give a false detection, which may give a raised Packet Error Rate. Addresses

as a continuation of the preamble (hi-low toggling) also raises the Packet Error Rate.


能够接收到ack信号之后, 我又发现了第二个问题, 发送方有时还是无法接收到ack信号。这一次的问题是因为接收方确实没有成功接收数据。增大Arduino手动重发(相比于nRF24L01+的自动重发)的次数, 可以确保接收方收到信号, 并能够显示出丢包的情况。


起初, 我尝试修改信道使其不与WiFi的信道冲突, 然后发现效果不好, 丢包率还是很高, 远超一半。


经过这篇文章的指点, 我发现这实际上是电源的问题。换了几种电源(笔记本输出的USB电源、某手机充电器)之后, 丢包率大幅度降低, 几乎一次就能发送成功。那篇文章指出, 在电源和地间并联一个1uF的电容也可以改善这个问题。然而, 我手头并没有1uF的电容, 所以我只好使用104P瓷片电容(10*10^4pF=10^5pF=0.1uF, ±0.02%)。事实上, 效果也不错, 也是几乎一次就能发送成功。


这个地方, 如果以后要设计PCB的话, 需要记得并联一个电容还是很有必要的。


原文地址:https://twd2.me/archives/8374

友荐云推荐