Timeslot-API: how to minimize the effect of BLE

[rgrr2]

Hello,

in our device we use the Timeslot API to share a 802.15.4 based protocol with BLE, softdevice is S140 6.1.1.

Problem: the 802.15.4 protocol misses appr 10% of the slots it is requesting even if BLE is just advertising.  I assume that this is because the Softdevice is doing some internal tasks.

When BLE is switched off, this ratio is around 2.5%, which is not perfect but would be ok.

My goal is to have BLE and 802.15.4 in parallel, unfortunately the 10% slot misses are not acceptable.

So I started to play around with BLE parameters, esp. sd_ble_gap_ppcp_set() and the advertising rate via sd_ble_gap_adv_set_configure().  But actually there is no change in the slot misses, it's always around 10% if BLE is enabled.  No matter if the BLE intervals are reduced or increased.

I'm wondering if I'm missing a point and if there is a way to reduce the number of timeslots the Softdevice is requiring on its own.

Thanks for any suggestion.

Kind regards

Hardy

[Edvin]

Hello,

the 802.15.4 protocol misses appr 10% of the slots it is requesting even if BLE is just advertising

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

[rgrr2]

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

[rgrr2]

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

[Edvin]

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

[rgrr2]

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

[Edvin]

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