How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Hung Bui — Thu, 25 Jan 2018 08:48:52 GMT

You are welcome Mathias :)

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Mathias — Wed, 24 Jan 2018 17:14:14 GMT

Okay, I think I understand it better now. Thank you again for all your help. I really applaud the DevZone community for all the effort in helping me out with all my questions all the time!

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Hung Bui — Wed, 24 Jan 2018 16:18:55 GMT

Yes, you can ignore the timeout mechanism as it's handled by the Mesh stack already and is transparent to the application.

Only on the first call to advertise the random delay will be calculated of something bordered by advertising interval. Think about it as a consequence advertising packet, when the previous advertising packet happened some time in the past (the random delay) instead of happens at the time of calling. This to avoid a long wait for the first packet if the advertising interval is big.

If you have a look at the timeout_event() you can find the call setup_next_timeout() will calculate the next advertising event with the normal random delay as normal Bluetooth advertising.

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Mathias — Wed, 24 Jan 2018 14:56:31 GMT

It's just that in the bearer layer libraries, specifically in the advertiser.h file, I can see the method "schedule_first_time" being used by the light_switch_example. And in there, I see that a kind of offset value (after which sending starts?) is calculated randomly, bordered by the advertisement interval? But I don't understand how this compares to normal BLE advertising?

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Mathias — Wed, 24 Jan 2018 14:46:10 GMT

Ok, I understand.
Aha, so if I understand correctly, I can actually "forget" that the concept of timeslots is being used underlying as long as I only do mesh operation, because then the timeslots will always be granted and for the longest period (10 seconds then as you say)? And then just view the mesh communication like advertising & scanning in normal BLE (thus with advertising interval, scanning interval and scan window) but then with the scheduler prioritizing advertising over scanning if they should collide and advertising should take place in that advertising event?

Thank you!

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Hung Bui — Tue, 23 Jan 2018 15:10:49 GMT

1 . Yes, correct. However in our beacon example in the Mesh SDK, we also don't use the Softdevice advertising function, but advertise directly using the Radio, inside timeslot.

2 . Yes the mesh stack use those interval. You can think of timeslot is the normal state, and the mesh stack running inside that state 99% (maximum timeslot can be extended to is 10seconds I believe, then the Mesh will request another timeslot right after). I don't know how exactly the scheduler works with Mesh SDK but my understanding is that the scheduler will prioritize advertising over scanning and scheduler will not schedule scanner period if it collides with advertising period.

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Mathias — Mon, 22 Jan 2018 13:42:45 GMT

Sorry, I meant non-BLE mesh applications or thus normal BLE applications. For example being able to be both a BLE beacon and a node in a mesh at the same time.
For normal BLE this is indeed needed, as I understand. But does the mesh stack also use these intervals? Or is it just via timeslots? And thus scanning being done at 100 % as long as timeslot is not done? And advertising being done as soon as a timeslot is allocated to advertise the message?

Thank you for your time!

RE: How does the Mesh SDK use the Timeslot API through advertising & scanning interval?

Hung Bui — Mon, 22 Jan 2018 13:07:55 GMT

Hi Mathias,

1 . Currently Mesh stack requires the Timeslot mechanism from softdevice to work. However, there is no BLE function from the softdevice is needed or used. So actually requesting and staying in timeslot is the main state (99% if not 100% of the time) of the Mesh device.

The main purpose of using timeslot is to support GATT bearer in the future as well as other applications that requires BLE. I don't think supporting "non-BLE devices while also being able to support Mesh SDK" is the main purpose, even though it's possible. Could you point me to the documentation you got that information ?

Mesh SDK doesn't use any BLE feature from the softdevice for advertising and scanning.

2 .Why do you think advertising interval is not needed ? This interval decide how often a node broadcast a message. By spec there shouldn't be more than 100 messages per 10 seconds.

Same with scan interval and scan windows. By default scan window = scan interval (continuous scanning, except when advertising), however it's possible to change that using the configuration so that we can do something else with the radio or to save power consumption.

If the timeslot can't be guaranted at 100% (because we have normal BLE application for example) I believe the scheduler will simply won't schedule the scan window for that period.