NRF52 DK is missing 40% of advertising packets

[panda_noob_2000]

I am using the NRF52 DK with Keil IDE in Windows. I uploaded the ble_app_uart_c example (Examples > ble_central > ble_app_uart_c) and modified it so that it would print a message whenever it received data from a sensor with a specific MAC address.

It works wonderfully... 60% of the time. The packets it's dropping seem to be random. I do not know what could be causing this. I tried commenting out everything else in the function, but this did not help anything at all.

I have attached a screenshot of the changes I made to the file. Any help is greatly appreciated!

[panda_noob_2000]

Hi,

Karl Ylvisaker said:

It would be very helpful to see a sniffer trace of the on-air BLE traffic for both scenarios - one in which it successfully picks it up, and one of where the packets are dropped.

I'll try to implement the sniffer when I get home. 

Karl Ylvisaker said:

I still also would like to hear how you measured that 60% of the packets were dropped.

In the code, I check the MAC address and if it is the door sensor, I flash an LED. With the NRF52 DK, the LED flashed 60% of the time the door sensor sent a message. With the Particle device, the LED flashed 100% of the time the door sensor sent a message. I know the door sensor sends a message because there is a signal LED. With the NRF52 DK, I have also tried using print statements instead of an LED flash to indicate a message received, and the results also indicated that 40% of the packets were dropped.

Karl Ylvisaker said:

If every advertising packet that is picked up if forwarded to the application

My impression was that the BLE callback function ( on_ble_evt() ) was the first piece of code run when the NRF picks up a Bluetooth signal, and that a new thread running this function was created whenever a bluetooth signal was encountered. What is the application? Is it the code I am programming? Is there other code run on the NRF that I don't have access to that runs first?

I am very new to this so am still very unfamiliar with how the device reacts to signals.

Thank you!

Maria

[Karl Ylvisaker]

Hello Maria,

panda_noob_2000 said:

I'll try to implement the sniffer when I get home. 

Great! Please do not hesitate to open a ticket if you should encounter any issues or questions about the sniffer and its setup.

panda_noob_2000 said:

In the code, I check the MAC address and if it is the door sensor, I flash an LED. With the NRF52 DK, the LED flashed 60% of the time the door sensor sent a message. With the Particle device, the LED flashed 100% of the time the door sensor sent a message. I know the door sensor sends a message because there is a signal LED. With the NRF52 DK, I have also tried using print statements instead of an LED flash to indicate a message received, and the results also indicated that 40% of the packets were dropped.

Aha, I see. Thank you for elaborating!
This is unfortunately not a entirely accurate way of measuring the percentage of received advertisements, since the device likely is advertising multiple times in the given interval, etc. but this explanation gets your point very well across, and I suspect that this behavior might be caused by the device being busy sorting through all other advertisements being present, or similar. I suggest that we get the sniffer up and running so we may see the exact contents of the lock's advertisments, and then add a filter so that the application is only ever told of relevant advertisements.

panda_noob_2000 said:

My impression was that the BLE callback function ( on_ble_evt() ) was the first piece of code run when the NRF picks up a Bluetooth signal, and that a new thread running this function was created whenever a bluetooth signal was encountered. What is the application? Is it the code I am programming? Is there other code run on the NRF that I don't have access to that runs first?

This is not exactly correct, but I understand where the confusion comes from. The BLE callback will be the first part of your application that runs when a BLE event is passed to the application. However, the SoftDevice lies on top of the application, and takes control of the CPU whenever it needs to meet any of the timing-critical deadlines to uphold the BLE specification. The SoftDevice then uses the CPU and radio peripheral to receive and send messages, before it then generates the appropriate BLE events for the application. Then, after it finishes up its BLE event handling it gives control of the CPU back to the application, so that the application may proceed with whatever logic you have implemented.
The reason why the SoftDevice is implemented in this way is that the BLE Specification is very strict, and must be followed to the letter in order to get certified as a BLE device. Luckily, the SoftDevice takes care of all these things for the developer, so the only thing the developer needs to do instead is to account for the fact that their application may be interrupted at any time by the SoftDevice (for a short time each time).
Does this make sense? 

panda_noob_2000 said:

I am very new to this so am still very unfamiliar with how the device reacts to signals.

This is good for me to know so I can be more thorough in my explanations, great!
Please do not hesitate to let me know if any parts of my answer should be unclear :)

Best regards,
Karl