Measure nrf24l01+ RSSI

[Ashish]

Hey,

I have a product which is using nrf24l01+ for communication. There is packet loss in the communication which I am trying to figure out the reason for. Is it possible to build a sniffer which can measure the RSSI at the receiver side, with nrf52 or any other nordic device?

From what I have researched till now, the auto ack can not be disabled on the receiver side. So if I have two devices receiving, one with nrf52 and other with nrf24, one of them will autoack and the other will discard the packet, is this correct?

I have also checked SB protocol library for nrf52. From what I understood, it is possible to disable ack in that but then it doesn't measure RSSI.

My transmitters are already deployed, so it won't be possible to change firmware on those. Is there any way of measuring signal strength?

I can change the nrf24l01+ with nrf52 on the receiver side and program it as a simple loopback device. Is it recommended to do so? The transmitter will be sending data at 2mbps data rate and each transmission is around 30kb.

Thanks.

[Kenneth]

Hi,

It is not straight forward to make a pure sniffer RX no, but if you know the address and frequency, then you can setup for instance an nRF24L01+ in standard SB mode (clear FEATURE and EN_AA registers), set maximum payload length (32) and disable CRC. Then each time there is an address match, the data will be received by the nRF24L01+, and the payload can be read out by MCU. However, the received payload will then include the 9bit PID field in the beginning of the packet, and actual data is shifted thereby 9bits, also CRC will not be checked in any way, so you will need to check the data entirely by the application firmware on the MCU, data may be erroneous, and random demodulated noise will be at the end of the packet if the payload is shorter than maximum length (32).

I highly doubt measure RSSI will help, I think it will help you can describe a bit more when you experience packet loss. Does it happen independent of distance, is there other 2.4GHz noise in near proximity, what amount of packet loss do you experience, are you using ack payloads, if yes what is the size of the ack payload and retransmit delay? Have you measured the output power on an spectrum analyzer? Have you followed the reference layout carefully and the PCB guidelines in the datasheet?

Best regards,
Kenneth

[Ashish]

Hi Keneth,

Thanks for your reply.

I understand making a pure sniffer will be difficult, so I have dropped that idea.

Regarding the packet losses, they appear to be random. The transmitter while sending 500+ packets may miss 1 or 2 packets in between. It doesn't happen always though.

Also, the transmitter misses ack packets. I am not using ack payloads, so I guess there will be a ack packet with the PID only. The transmitter sometimes just misses that ack packet and as it is depending upon the ack packet to know whether the receiver has succesfully received the packet or not, it sometimes gets into a stage where the transmitter feels like there were packet drops however the receiver has received all the packets. I have a packet retransmit mechanism on the application side too, but it is dependent on the hardware level ack which are missing for some reason. Right now I am trying to change this, I have implemented a simple ack mechanism on the software side but the results will take some time.

From my initial testings, more the distance, more are the packet loss but it surely happens sometimes with nearby sensor too. I get that there might be interference due to other devices running on same band, so I am still looking into this.

Regarding the PCB layout, we have checked the reference layout and the PCB guidelines and tried to follow them.

If you have any idea on why am I loosing the hardware ack packets, please let me know.

Thanks.

[Kenneth]

What retransmit count and retransmit delay are you using here? Are you changing frequency? Do you on the PRX keep CE high at all times, or do you cycle the CE at any time? Have you tried using 1Mbps instead?

Best regards,
Kenneth

[Ashish]

Retransmit count is set to 15 and retransmit delay is at max. The frequencies once set are not changed. On the PRX side, I am using RF24 library (https://tmrh20.github.io/RF24/RPi.html) with raspberry pi, so that handles the PRX pin status. I have tried once with the 1Mbps rate, but that became very slow so didn't test that much.

[Kenneth]

I don't understand why 1Mbps is very slow either, because the turn around time is not a big difference, e.g.:

TX 2Mbps 32byte payload with ack: 130us+160us+130us+40us = 460us
TX 1Mbps 32byte payload with ack: 130us+320us+130us+80us = 660us

I do not see any advantage of setting retransmit delay to max (4000), set it to 500us should be fine. It should also increase the speed.

Best regards,
Kenneth

[Ashish]

Thanks for your reply Kenneth.

I will try your suggestions and will let you know.