Softdevice Controller: TX with 100% duty cycle scanning in v2.3

After updating to the softdevice controller included with NCS v2.3.0 (nrfxlib 6d0f58448fae164cfa4d28c494d6bddf5d0d0224), I have noticed what appears to be a behaviour change.

Previously, when configuring Zephyr to scan on Bluetooth with 100% duty cycle (interval == window), extended advertising packets that were scheduled for transmission by my application would be received on a secondary device reliably. After updating, I am seeing approximately 0% of these packets (maybe 1 packet every minutes at 1Hz transmission). If I update my scanning window from 100% to 99%, the secondary device is again receiving the vast majority of the packets. In both cases, I receive no errors from the Bluetooth stack and all expected events are generated (TX done callback called with num_sent == 1).

Has there been some internal change to TX or RX scheduling in v2.3 that could account for this change in behaviour?
Perhaps related to the experimental PAwR or PAST support added?

  • The actual number of started advertising events is however reduced if the advertiser accepts a CONN_REQ/CONN_IND. The amount of packets that appear on air may also be affected if an advertising event is prematurely closed due to for instance an coexistence interface.

    This is obviously not what we are seeing here. No devices are connecting to the advertiser, there is no other interface that could be triggering co-existence. The sample application works until NCS v2.2.

    Advertising data is not intended to be used as a way of sending arbitrary data by design. It's more of sending repeated data or for establishing connection. You may have to deal with packet loss due to collision because they don't have any way to sync the communication. In addition, power consumption can be high because your device(s) has to scan all the time.

    We are well aware of the limitations of advertising data, and we do not use it expecting 100% packet throughput. It is a cheap mechanism to broadcast device state in an unstructured, mobile network that can also be observed by phones. I am unaware of any other Bluetooth mechanism that would allow receiving data from 100's of devices in a 1 second listen window.

    Bluetooth mesh appears to be a sinking ship (even ignoring provisioning hell).
    PAwR looks to be amazing for getting data back to a gateway device, but little help for peer-to-peer communication.

  • Hi Jordan, 
    We are getting deeper inspection about the issue and will get back to you when we have any update. There could be something wrong with the scheduling of larger adv packet on the first event. 

  • Hi again Jordan, 

    The team has confirmed that it's a bug in our controller. A fix will be implemented in the future release. But we afraid that it will not come in nRF Connect v2.4 as it's coming out very soon. 
    For now, our suggestion is to either use 2 events instead of 1 when you increase the length of the advertising set. Or use dummy data so that the length of the advertising data doesn't change. 

    I'm not so sure why you don't see the same issue when in SDK v2.2 as the information I got from the team is that this bug has been there for a long time. I did a test with your code (changing length of adv packets) in SDK v2.2 and saw the same issue.

  • Thank you for the update Hung. I will admit I didn't re-test v2.2 after I made the change to updating the advertising set instead of recreating it. I am quite confident that the single event mode worked fine on v1.9.4 when recreating the set each time, but I've had much less testing with any other configuration.

  • Hi Jordan, 

    Yes it's about right that the change/bug might have introduced in SDK v2.0. 
    Most likely the fix won't be able to make it to 2.4 but it will be fixed in 2.5. 

Related