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