nRF24L01+ addressing issues

[gacekky1]

Hey everybody, I'm having 'intermittent' issues with device addresses on the nRF24L01+. I've read the documentation on what you're not supposed to do as far as device addressing goes (i.e. 0xAA and 0x55 are preamble bytes and 0x00 and 0xFF can cause packet loss).

When I use all 0's for the 5 byte address the PTX device transmits and the PRX reads the packet, but the transmission fails on no ACK received. This makes sense following the documentation. However, it works just fine if I use all 0xFF. More strange though is when I use [0x01,0x00,0x00,0x00,0x00] (LSB first), as a device address the transmission fails but, [0x00,0x00,0x00,0x00,0x01] works consistently. Also, other addresses work fine as well, such as the default [0xE7,0xE7,0xE7,0xE7,0xE7].

The obvious solution is to just not use those addresses, but now I'm wondering how many other addresses will cause this issue since I was going to set the last four bytes of the address from the serial number of the device.

Has anyone else had this problem? I don't think it's a software issue since I can send and receive a packet, it just doesn't send the ACK, as well as it working perfectly on all other addresses I've tried.

Thanks!

[ovrebekk]

Hi

In general you should avoid addresses with very few bit shifts, such as the ones you include here, but I wouldn't expect communication to fail completely. I will try to reproduce the issue on my end, and get back to you when I get some results.

[ovrebekk]

Hi

Probably our address generation guide lines should be a bit more demanding. Having very few bit shifts in the address is sure to cause issues, as is addresses starting with 0x55 or 0xAA (since it matches the preamble).

I ran som tests on the addresses you mention, and my results were comparable to yours:

All 0xFF: ~5% packet loss
All 0x00: ~50% packet loss
0100000000: ~40% packet loss
0000000001: ~1.2% packet loss

If the first byte of the address is good I think you can choose the remaining bytes freely without risking massive packet loss. I did some testing on my own and found that there were plenty of options for the first byte that would yield good results even if the remaining bytes were all 0's or all 0xFF's. As an example 0x21,0x00, 0x00, 0x00, 0x00 showed 0% packet loss across the board (100 packets on 3 different frequencies, 2Mbps bitrate and the default retransmission setting of 3).

I am not able to explain why some of the poor addresses are better than others. I will check with one of the analog designers in case they have some theories.

Best regards
Torbjørn

[ovrebekk]

Hi again

On closer inspection my test was a bit flawed. I was just measuring received packet loss, not the loss of ACK. When measuring the received ACK's (not just the received packets) I also got 100% packet loss on the worst addresses:

Lost ACK percentage: FFFFFFFFFF: 4.5% 0000000000: 100% 0100000000: 100% 0000000001: 1.4%

With the modified test I got better results when setting byte 1 to 0x4D, compared to 0x21 (< 0.5% packet loss).

[gacekky1]

Hmmm... That's unfortunate. But thank you for replicating the test! Now I can say for sure to avoid these addresses.

I have each TX Pipe set up like so: Default for pairing: 0xD2, 0xD2, 0xD2, 0xD2, 0xD2 PIPE0: 0x0A, 0x01, 0x01, 0x01, 0x01 PIPE1: 0x0B, 0x01, 0x01, 0x01, 0x01 PIPE2: 0x0C, 0x01, 0x01, 0x01, 0x01 ... And so on. This seems to work fine.

[ovrebekk]

Those addresses look much better. In our older address generation guide lines (for the nRF24L01) we recommended to avoid repeating the same byte over and over, but if you don't notice any higher packet loss it's probably fine.