Multiprotocol device acting as BLE Peripheral and Thread SSED at the same time

[whyeye]

Hi, as the title states, we are exploring the possibility of building a product that utilises dynamic multiprotocol to be a BLE Peripheral as well as a Thread SSED concurrently. Reading the documentation, it sounds that this should be possible. However, my concern is that since both protocols rely on accurate timings to function properly, wouldn't it be inevitable that there will be timing conflicts? Is this handled automatically by the MPSL or do we need to manage it in application code?

Thanks.

[Jørgen Holmefjord]

Hi,

The BLE stack will have higher priority than Thread, and Thread will run in MPSL timeslots. As described in Time-multiplexed radio access:

"In this solution, Bluetooth Low Energy has always priority over 802.15.4 protocols. Because of the nature of the Bluetooth Low Energy protocol (TDMA), the Bluetooth packet error rate should be 0% in absence of any external interference."

Handling of the protocols will happen automatically, and there is not much you can do in the application to control this. You might want to avoid BLE connection interval and synchronization interval for SSED that may frequently overlap.

We had some probability numbers for a set of BLE parameters in the older nRF5 SDK for Thread and Zigbee that you may have a look at: Dynamic multiprotocol performance.

Best regards,
Jørgen

[whyeye]

Thank you Jørgen. That makes perfect sense.