FCS errors only in last bit of CRC and not the rest of the packet

[Chris J]

I am using the esb_tx example on an nRF51 DK board modified to send BLE advertising packets at 1 KHz.

I am receiving the packets on a BlueTooth sniffer. The contents of packets is fine, but about 5% of the time there is an FCS error in the sniffed packet. The signal level is -40dBm at the sniffer and there are no other BlueTooth devices in the area. I am using a TI CC2540 USB dongle for the sniffer, but it seems more likely that the problem is transmit related.

I configured the code to do one retry after not receiving an ACK in order to have it send each packet twice (since there are no ACKs). I can see that in cases where there is an FCS error, the valid instance of the packet and the error instance of the packet only differ in the CRC bits. The error only seems to affect the MS bit of the last byte of the CRC, so that seems to indicate that perhaps the transmitter is turning off one bit too soon.

Any other thoughts on what might be causing the CRC only FCS errors and how to fix them? Is there any way that the transmitter configuration and/or code or interrupt timing could cause the last bit of the packet to get messed up?

[run_ar]

Are you sure you configured the BLE advertisements correctly? Please see this for an example: https://github.com/NordicSemiconductor/nRF51-multi-role-conn-observer-advertiser

[Chris J]

I have the esb_tx code modified so that it uses a 4 byte fixed address that is set to the advertising address, then a fixed length packet hard coded in advertising format, followed by a 3 byte CRC, calculated by the chip. 95% of the time it works. 5% of the time the last bit of the CRC is wrong. In fact, looking more closely at the errors, the correct state of the last bit of the CRC is zero, but in the error packets it always goes to 1. Is there some way to misconfigure things so that there is an error only in the last bit of the packet?