Missing advertisements in Android version of nRF Connect

[adam.schneider]

I've created a peripheral that is advertising about every 320ms but am seeing less than half of those packets in nRF Connect on my Android mobile (configured to run in low latency mode; Galaxy S20+, nRF Connect v4.24.3).  I've attached two screenshots showing a 10 second plot filtered on my device.  In the first screenshot below I've got the advertised payload configured to update each advertisement (different colors).  In the second screenshot it is a static advertising payload (same color).  In both cases you can see that a significant number of advertisements are missed despite the peripheral only being a couple feet away. (about 10 of 30 successfully received in #1; 18 of 30 successfully received in #2)

Can anyone help me understand what is happening or what I can do to improve the number seen within nRF?

[Hung Bui]

Hi Adam, 
Could you explain a little bit more on the "Low latency mode" you used ? If you turn that off would the performance get better ? 
I would suggest to verify that the device actually advertises with the expected interval using a sniffer.

Did you advertise in all three channels ? 

Have you checked with other phones  ?  I suspect that the phone may not scanning in 100% duty cycle. 

[adam.schneider]

"low latency mode" is the scanning mode option that nRF Connect has under the Scanner settings (along with enable continuous scan). It's my understanding that these settings will allow the app to put the device in scanning mode at or near 100%.

Yes, I've confirmed the device is advertising at the expected rate.

Yes, all 3 channels and sniffer confirms this.

I've seen it on multiple phones. Is there a way to log or check to see when the phone enters/exits scanning?

[Hung Bui]

Hi Adam, 
Sorry that I didn't know about this latency mode. It's the default mode on the nRF Connect. 
It could be that the phone doesn't allow BLE scanning at 100% duty cycle to save power. You can also try to test turn off Wifi if it can improve the performance. 
Interference could also be an issue as well. Please try to test in a RF chamber ( e.g your home microwave oven). I did a test in my microwave and the phone captured 30/30 packets in 10s compare to only 15-20 packets in 10s when testing outside. 

[adam.schneider]

Is there a way to know if the phone/OS don't allow BLE scanning at 100% duty cycle?  I'm not well versed in Android OS options regarding BLE. 

I'll see if I can get access to an RF chamber with my prototype peripheral.

[Hung Bui]

Hi,
I think the easiest way is to advertise in short interval (7.5ms) and check if there is any period that you don't see any advertising packet, don't forget to test it in a RF chamber. 

[adam.schneider]

Hung,

I did some testing in an RF chamber with WiFi off with two different phones, Galaxy S30+ and Pixel 3a and the results were better but still nowhere near 90+%.  It's not super easy to tell with the nRF app how many packets were received (enhancement request for the mobile app team!?) but I'd guess around 50-60%.  I'm hoping this isn't indicative of Android and mobiles overall...

[adam.schneider]

Hung (or other forum readers),

I guess one of my questions is whether nRF Connect on Android has been optimized to try and capture every single advertisement possible? I've been assuming that nRF Connect is representative of a best case mobile app on Android with respect to capturing as many advertisements as possible and want to make sure that is true. 

I'm struggling to believe that over a 30s period, the Android OS and/or mobile radio itself is missing 50% of advertisements (or not letting them get to the application layer)... 

[Aleksander Nowakowski]

Hello adam.schneider,

With "Low latency" scanning mode the app indeed using highest duty cycle. It's described here:
ScanSettings  |  Android Developers

You may compare how the different modes work. In balanced, the app scans for 2 sec every 5 sec window. With low battery mode it's 0.5 sec every 5 sec. You may see it here: What to keep in mind when developing your BLE Android app - Blogs - Nordic Blog - Nordic DevZone (nordicsemi.com) in chapter 2.2.1 of the PDF document (which is very old, but still recommend).

nRF Connect logs all packets it receives, so it's the Android OS or the controller that skips some. Perhaps you have other devices advertising, or Wi-Fi that create 2.4 GHz noise. When I test it with a DFU (which advertises with 7.5 ms), the app was receiving I'd say ~90+%.

[adam.schneider]

Thank you for the comments Aleksander.  Here is an example I captured from inside an RF chamber, with WiFi off on the mobile. In the 20 seconds previous to this, 5-6 packets were missed in each of the 10 second (30 advertisements) segments. 70-80% is much better, but in an RF chamber I'd expect much closer to 100%.

I am fairly confident the peripheral i was observing was advertising during the big gap shown from testing I've done with a commercial BLE protocol analyzer before using the same peripheral/code (i didn't have it running for this test though). With the commercial analyzer, it has been able to capture 99% of all advertisements on all advertising channels.

[Aleksander Nowakowski]

Did you try a different phone? I imagine it may vary depending on controller manufacturer, as a result of e.g. battery optimization.

[adam.schneider]

I've seen similar results on both Galaxy S20+ and Pixel 3a...so Samsung and Google mobiles.  Where is the best place to learn about different manufacturer battery optimizations?