Issue with dropped advertisements using SDK 17.0.2 (SoftDevice 7.2.0)

[Steven T.]

We experience a 15-20% rate of dropped advertisements from our nRF52840 device. We have used our own application on our device and the ble_app_att_mtu_throughput application on the nRF52840 DK to measure this loss. The devices are advertising once every 10 seconds. We are maxing out the packet size of the advertisements (31 bytes) with manufacturer specific data.

There is noise in our testing environment, and we suspect that may be part of the problem. However, we have performed the same tests outdoors with minimal interference and still continue to see a significant number of dropped advertisements.

We thought maybe using Periodic Advertisements would help us reduce dropped advertisements, but was unable to find support for this in the nRF SDK 17.0.2 (SoftDevice 7.2.0) release.

We also thought that using extended advertisements would reduce the amount of time on the primary channels, (37,38 and 39) and instead transmit the bulk of our data on a secondary channel.

Are Periodic Advertisements supported at this time? If not, when might we expect support? 

Do you have any suggestions that we might use to reduce the number of dropped advertisements, e.g. extended advertisements, periodic advertisements, etc.?

[Steven T.]

Hello Hung,

The devices are within a meter of each other, on my desk. The central does not connect to the peripheral. The central parses the advertisement packets sent by the peripheral. Adjusting the scanning rate to 100% duty cycle, i.e. interval == window, the receipt of advertising packets improved. We've tried 1ms, 100ms, 200ms, 1s and 4s and 10s intervals on the central device, but changing these values don't seem to affect the packet receipt rate much.

Increasing the advertisement broadcast rate to 5s helped. We are trying to conserve power, so we don't want to advertise much faster than that. 

I have a central device, running mBed OS 6 with a Nordic 52840 chip. I am just counting the number of missed advertisement packets. The central device is scanning for advertisements, and the peripheral device acts as a beacon, delivering sensor data in the manufacturer specific portion of the advertisement. The peripheral device has run our custom software, as well as the ble_app_att_mtu_throughput application on our peripheral device. We were trying to determine if porting our custom application from nRF SDK 13.5.1 (5.0.0.2-alpha softdevice) to 15.3.0 (6.1.0 sofdevice) to 17.0.2 (7.2.0 softdevice) would help us see more advertising packets. We've also tried 1MBPS and CODED phy as well. Seems like our hardware is going to experience a 10-15% drop rate.

We've run the ble_app_att_mtu_throughput on the nRF52840DK device to see if the peripheral app's power saving techniques were causing missed advertising packets, or if the antenna on our peripheral device was to blame. We didn't see any improvements.

I will put in some effort today to see what happens with the ble_app_att_mtu_throughput application running as both the central and peripheral device on the nRF52840DK. Hopefully, we will see an improved advertising rate. We could eliminate mBed OS/our central device as the reason for the dropped packets.

We have not tested these is a wired environment or an RF chamber. We will investigate these options as well.

Regards,
Steven Turgetto