• State Not Answered
  • Replies 4 replies
  • Subscribers 87 subscribers
  • Views 977 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 271014
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.?

  • 0

    Hi, 

    I would suggest to increase the advertising rate to measure the drop rate. 

    Could you give some more info about the central ? Do you have full control over the central ? There could be a chance that the central doesn't scan at 100% duty cycle (this applied for most phones)

    Sending a longer (max size of payload) would give more chance that the packet may collide with other advertiser's packets. 

    Periodic Advertising is in the NRF Connect SDK (Zephyr) but not the Softdevice. The softdevice will no longer receives new features, only bug fixes. 

  • 0

    We're now testing an advertisement sent every 5 seconds. The central is running mBedOS 6.11 and setting the scan to 100% duty cycle did offer some improvements to the performance. But, we are still consistently seeing a 15% drop rate.

    We didn't see much improvement between extended and legacy advertisements in our tests.

    Please let me know if you have any other suggestions on proving the drop rate.

  • 0 in reply to Steven T.

    Hi Steven, 

    Please give us some description about your test. 
    You mentioned about ble_app_att_mtu_throughput application but I assume you only count the number of advertising packets you receive, not when they are in a connection ?

    What's the distance between the 2 devices ? 
    Have you tuned the antenna of your custom board ? 
    Could you try to test using 2 DKs instead of your device + our DK. Just so we can compare if it the antenna tunning issue on your board ? 

    For best result, please try to test using a RF chamber or use a antenna cable to connect the 2 devices. 
    I would also suggest to test with short advertising interval (100ms for example) so that we can have more sample and get better statistics. 

  • 0

    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

Related
Terms of service