Has anyone used the auto-acknowledge and auto-retransmit features of the Nordic nRF24L01?
The Nordic Fob, transceiver, serial interface, etc, firmware disables auto-ack and auto-retransmit. I have my own firmware for FOBs and transceivers, with longer payloads, but otherwise have configured the Nordic just like the code samples.
Everything works really well, except when there is heavy Wi-Fi traffic. When there’s WiFi interference, FOB button pushes frequently get missed so that the button has to be pushed multiple times until the receiver finally gets the signal.
Wi-Fi uses the ame 2.4 Ghz RF channels, so the Auto-Retransmit feature seems like a really nice feature. If a FOB button push isn’t acknowledged by the receiver, the FOB would keep trying (programmable number of times) until it received the ack.
I figured I try it out by first just enabling auto-ack on the receiver but not auto-retransmit on the transmitter. I figured the receiver would still receive packets ok, but would just acknowledge them The transmitter wouldn’t be looking for the ack, but I didn’t think that would matter.
So, I just changed the code to write 0x01 to the EN_AA register ( instead of 0x0). When I do this, no packets are received.
Any ideas on what the issue might be? Has anyone used these features successfully?
I don’t know the nRF24L01, but with 802.15.4 (XBee and all the others), the signal in the 2.4GHz band is 2MHz wide on 5MHz channel centers. Since many/most people prudently set their WiFi to 802.11 channels 1, 6 or 11 (the only three numbers that don’t overlap), you can choose frequencies for 802.15.4 (and I’d guess, the nRF24L01) that fall on the edges of the WiF channels - so that the WiFi signals are weaker.
I’d also check the nRF24L01’s settings for clear channel assessment (CCA, listen before transmitting) - to reduce collisions with 802.11 packet times. In 802.15.4, the CCA signal level and time dwell are user defined.
I’d strongly suggest that you make a habit of using auto-ACK and auto-retransmit for reliable communications. Even with MAC layer error correction, you will see uncorrectable errors now and then, and CCA faults - if you monitor for them. When they happen, your application needs a strategy for error correcting retransmissions.
Of course, you would always want CRC checking enabled, in the MAC layer.
The channel numbering scheme for 802.11 and 802.15.4 is given by the IEEE standard. But the numbers are different. So choose based on channel centers in frequency, not channel numbers - for any kind of radio.
I’ll check the Nordic spec to get frequency versus channel number.
I did get the auto-Ack and auto-retransmit code working, but I need to test in a real environment before I’m comfortable with it. I definitely don’t want to make things worse.
The extra bits in the Enhanced Shockburst payload will increase the on-air time, so it’s just that more likely to get a collision. I guess the receiver won’t know whether his ack was recognized by the transmitter, so even if the FOB doesn’t receive all that well, doing the retries when ack’s aren’t received isn’t going to make things any worse.
I don’t see why listening before transmitting is better than just continuously retrying until the ack is received. The transmission needs to occur with a few hundred milliseconds of the button push regardless, so why not just set the number of retries to be consistent with the maximum acceptable delay between button push and transmit?
Do you have any insight as to what delay between retries would be optimal?
I wasn’t able to get significantly better performance using auto-ack that without in the application that I tried it. Maybe that’s not surprising, though.
I was using the Nordic FOB to transmit key depresses. I changed the payload size to one byte to minimize on-air time. If you use the auto-ack feature, more bits are transmitted so your “on-air” time is longer. That means there is a longer period of time when you’re susceptible to interference. So, I wasn’t sure I’d see any better performance (and I didn’t).
A dropped packet just meant the user had to push the button again, so I’m just living with users ocaisonally having to push the button again to see the desired update.
In another application where a missed packet is unnacceptable, I transmit on two different frequencies and have a receiver listening on each. I keep statistics on dropped packets and I’ve yet to see a packet dropped on both frequencies. Not a tremendous amount of data though, since only about 10 packets per minute are sent.
I’d also be interested in knowing if lower data rates help versus the retry feature.