Timeslot-API: how to minimize the effect of BLE

RE: Timeslot-API: how to minimize the effect of BLE

Edvin — Wed, 16 Mar 2022 11:34:05 GMT

There are examples that uses thread and zigbee only, without BLE. In those cases the softdevice is not flashed, and the timeslots are not required. I am not completely sure how it works if you run the BLE+thread/zigbee examples and don't start any BLE activity. I guess that the 802.15.4 stack would still request timeslots, but as the softdevice is not doing anything else, it will always accept them.

Best regards,

Edvin

RE: Timeslot-API: how to minimize the effect of BLE

rgrr2 — Wed, 16 Mar 2022 11:18:58 GMT

Hello Edvin,

thanks for the explanation. Is it possible, that the Softdevice is needing timeslots even if BLE is disabled? I mean despite for flashing.

Kind regards

Hardy

RE: Timeslot-API: how to minimize the effect of BLE

Edvin — Mon, 14 Mar 2022 14:41:57 GMT

Hello Hardy,

The softdevice will run on the highest priority, and the 802.15.4 will request timeslots in between the scheduled BLE activities. In reality, the 802.15.4 will run 100% of the time, except when the Bluetooth Low Energy (BLE) stack is actively using the radio. The "issue" is that packets that are not yet transmitted/received 100% will be interrupted when the BLE stack is taking over.

Since BLE is running on top priority, it is worth knowing that all BLE activity you add will take the time from the 802.15.4 stack. In other words, doubling the advertising interval will interrupt the 802.15.4 stack twice as much, and a short BLE connection interval instead of a long BLE interval (if you are using connections) will do the same

Best regards,

Edvin

RE: Timeslot-API: how to minimize the effect of BLE

rgrr2 — Fri, 11 Mar 2022 20:58:12 GMT

Hello Edvin,

I have to apologize for wasting your time. The fault was on my side: the function changing the advertise interval was immediately overridden by another function which sets the interval to 152.5ms, so I have measured always against a constant advertisement interval. To bad.

After correcting this, it "worked" as expected: timeslot misses are now somehow correlated with advertising interval.

So at least I can confirm, that advertising does influence the timeslots you can expect to get.

But still one question: does that mean, that advertisements have a high priority?

Thanks & kind regards

Hardy

RE: Timeslot-API: how to minimize the effect of BLE

rgrr2 — Fri, 11 Mar 2022 11:24:14 GMT

Hello Edvin,

the 802.15.4 protocol is requesting timeslots according to its schedule. Length of a single slot is 10ms, but the timeslot request algorithm tries to get longer ones with a multiple of 10ms. The 802.15.4 protocol is requesting around 10 slots / second (not evenly distributed), actually not that much.

The timeslot misses are determined by simple statistic counting: if the timeslot was successfully assigned (got NRF_RADIO_CALLBACK_SIGNAL_TYPE_START), a status bit is set.

The 802.15.4 routines then checking, if the timeslot is available for radio operation or not and do the statistic counting.

As said for BLE enable we get around 10% timeslot misses, without BLE there are around 2% misses.

BLE advertising interval can be changed from 300ms .. 3000ms without changes in this timeslot misses.

Connection parameters via sd_ble_gap_ppcp_set() can also be varied, no change in the timeslot misses as well.

Length of the advertise packet is 31 bytes.

As said already: the parallel operation BLE/802.15.4 works fine (but more fine, if BLE is disabled). To make it clear: radio connection works for both BLE on and off, but those timeslot misses are preventing the 802.15.4 protocol from receiving unacknowledged packets (broadcasts) too often.

Any suggestion are greatly appreciated.

Kind regards

Hardy

RE: Timeslot-API: how to minimize the effect of BLE

Edvin — Fri, 11 Mar 2022 09:26:15 GMT

Hello,

[quote user=""]the 802.15.4 protocol misses appr 10% of the slots it is requesting even if BLE is just advertising[/quote]

How do you determine this? (I am not doubting it, but I just want to know what observations you base this conclusion on). Does it also mean that it misses 10% of the radio time, or is it rescheduled?

And what are your advertising parameters? How often, and how much (approximate payload length) are you advertising?

Best regards,

Edvin