Deafness times for S130 and S132

[Elm]

UPDATE: Corrected language.

Hi, While experimenting with BLE mesh networking using S130 on nRF51 devices and S132 on nRF52 devices, we have a problem with deafness while receiving. We set the devices for continuous scanning, and intermittent advertising using the S130/S132 API.

This deafness seems to result from two interlinked reasons.

1. The BLE scheduler in the SoftDevice seems to split time into time slots of Scan Interval size. For each slot, the node can either scan OR advertise. If you set the Scan Interval to 100ms, then sending one advertisement message means that the receiver is switched off for 100ms. During this time, the receiver misses all messages sent to it. In order to limit this deafness, one would like to decrease the Scan Interval.
2. A short Scan Interval means that the receiver switches advertising channels often. During the channel switching, the node is deaf as well.

We are using S130 v2.0.1 on nRF51 devices and S132 v3.0.0 on nRF52 devices, all from the nRF5 SDK 12.2.0.

I would like to decrease this deafness time. I can see two solutions, please correct me if I am wrong.

1. Switch to using the Timeslot API for transmitting, and keep the Scan Interval so long that the channel switching time becomes relatively short. This is a long term solution for us.
2. I HOPE that other SoftDevices or newer versions of the same SoftDevice behaves in a better way, so it does not use a whole Scan Interval for sending one Advertisement Event. Is that so?

I would appreciate an answer especially to my HOPE in item 2 above.

regards, Elm

[thst]

Elm,

I see that you have made quite a bit of progress. Have you looked at the Mesh SDK?

• It solves this deafness issue by using timeslot API
• It is built on top of the S130/S132
• It is open source, so you can use what you want as long as it is on an nRF device
• http://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF5-SDK-for-Mesh

-Tom

[Elm]

Tom,

Thanks for your expedited reply!

Your answer is essentially the same as my "solution 1." Yes, we have looked at the Mesh SDK, and we believe that this is the best way forward.

However, I specifically wondered if there were changes to the scheduler in later/newer versions of the SDK which could help us, as in my (hoped-for) "solution 2". Also, not all implementations of BLE controllers in the world can benefit from using a Timeslot API-type of interface.

From you avoiding discussion the matter, can I assume that there are no such improvements?

regards, Elm

[Hung Bui]

Hi Elm,

Your observation was correct. The scheduler on the softdevice, with limitation on the complexity, doesn't have much flexibility when it come to arranging timeslot.

The long switching time (around 800us) was the limitation of the softdevice, not of the chip (40us)

As far as I know, even though the scheduler was re-written from S132 v4.0, the way it works is unchanged. We reduced some housekeeping time but that's it.

Keep in mind that the softdevices were not designed for mesh.

As Tom already suggest, you can either use our mesh solution or implement your own solution either using timeslot, or not using softdevice at all.

Another suggestion is to use Zephyr, you have access all the way to the controller and can use HCI to command.

[Elm]

Thanks, that was the answer I was looking for.

regards, Elm