nRF52840 Dongle Not Responding after receiving CONNECT_IND

[Rudhir]

Hi,

I am seeing a strange issue with nRF52840 Dongle when I run a custom BLE connection test repeatedly. Below is my configuration:

FW in nRF52840 was programmed using nRF Connect for Desktop v5.0.2

nRF52840 Dongle is configured as Peripheral with 2 custom GATT services.

Another custom HW board is configured as Central.

Pytest is used for test framework i.e. it configures the dongle and custom board. 

Test case is to start nRF52840 Dongle to advertise and custom board to connect to the dongle and discover available GATT services.

The test case fails 1 out of 20 iterations, or sometimes even sooner. The problem seems like nRF52840 Dongle does not respond after receiving CONNECT_IND packet. The dongle still remains in ADVertising state which means it didn't process the CONNECT_IND for some reason. I can clearly see CONNECT_IND in the BLE sniffer logs so there is nothing wrong with this. I don't know how to check on the dongle side what went wrong. Can anyone please give me some pointers? I have the wireshark sniffer logs and can share it if required. 

FYI, I ran this test in RF chamber(with zero noise/interference). The test seems to pass. It only fails when I do it outside the RF chamber.

Regards,

Rudhir

[Kenneth]

Hello,

This is quite normal. In real world there are significant noise from other 2.4GHz source as Wi-Fi, BT, USB3.0 and other protocols. Unfortunately this will sometimes cause a packet to fail CRC check, and hence the packet is discarded. In such cases the peripheral will continue to advertise as normal and central device should try again. I am not sure what BLE sniffer you have there, but if you are using a professional sniffer from Ellisys and Frontline my impression they are better at filtering out noise due to the signal processing, but even they sometimes report invalid BLE packets due to CRC failure. My impression is that what you see occurs in about 2-3-4-5% of the connection attempts, but it it really depends on the environment, so difficult to say. I would like to mention that the CONNECT_IND packet is actually a relative long packet also, which doesn't help since it make it more prone to noise.

Kenneth

[Rudhir]

Hi Kenneth,

Thanks for answering my question.

The sniffer I used was another nRF52840 dongle and I programmed sniffer firmware to it. Thats why I found it suspicious because both the Peripheral and sniffer is same device. Is it possible that CRC error happened only on peripheral device but not on sniffer? I also tried with Ellisys sniffer, and it gives the same result i.e. no response after CONNECT_IND. 

I understand in real world with noise, it's possible to see some packet discards due to CRC error. I am just trying to make sure our custom HW(initiator) is sending correct packet and nRF dongle is not discarding because of something it didn't like in the packet(sniffer says packet is good from CRC perspective)? Can we be 100% certain that issue is due to CRC error on receiving side? Is there an easy way to confirm this? Does nRF dongle print any error message(like packet discards etc) over serial? If not, what is the best way to see such errors?

Regards,

Rudhir

[Kenneth]

Hi Rudhir,

Unfortunately there is no way of detecting this no, even the nRF52840 USB dongle sometimes miss a packet. Though, I assume you have verified the hardware of your own dongle by running radio test to confirm output power and frequency by measuring on a spectrum analyzer, possible DTM for instance meet BLE requirements, and that the antenna have been properly tuned? If not, I suggest you open a private case here on Devzone and ask for someone to help with review and tune your dongle.

Kenneth

[Rudhir]

Hi Kenneth,

My understanding is that our hardware dongle is already verified for power and frequency, but I can follow up with my team. If required, I will open a private case as you suggested. Thanks again for these pointers.

Regards,

Rudhir