BLE performance when using Multiprotocol with Thread.

[Brosnan]

Hi,

We have been working with nRF52832 and using BLE Mesh in our product. The product is an Access control reader which scans for nearby smartphones over BLE and sends data to other reader nodes over BLE mesh. For decent user experience, we make the BLE scan for phone advertisements and also allows phones to connect to it if and when needed.

Presently we are thinking to develop on Thread Mesh, and we know BLE/Thread multiprotocol is supported. So the plan is to allow communication with smartphones over BLE (Advertisements & Connections) and send data to other nodes over thread mesh. We plan to use the nRF52833. Is this the correct SoC to go for?

Our main worry is the BLE performance, since the radio is common and 2 protocols will be time sliced with each other. Will there be delay experienced by the user when performing normal access events.

If yes, is there a way to mitigate that effect. Please propose some ideas. Straight forward one is to run 2 SoCs which will run both protocol independently and communicate over an interface, is what we were thinking. Is there more elegant solution?

Thanks

[Marjeris Romero]

Hi,

Will there be delay experienced by the user when performing normal access events.

No, it shouldn't, it will take less than a millisecond to switch between protocols. Any latency the user may experience will be more affected by the stack configuration (for instance the BLE connection interval).

Both radio protocols will run simultaneously in our multiprotocol solution, this means they will run without the time-expensive unitialization and initialization in-between the switching. Switching between portocols requires only a reinitialization of the radio peripheral, less than a millisecond.

You can read more about how the arbiters work here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/nrf_802154/doc/multiprotocol_support.html#rd-multiprotocol-support-implemented-mpsl-arbiter

Best regards,

Marjeris

[Brosnan]

Hi Marjeris,

I understood the dynamic multiprotocol.

In our current application we have BLE transmissions happening every 500ms, which are connectable and for the remaining time in between the beacons we do continuous scan to receive packets from smartphone.

So if we go with dynamic multiprotocol now, in the time between BLE beacon transmissions, there will be thread activity going on. So when can the BLE scan take place.

Also do we get to modify the thread and BLE timeslot durations?

[Marjeris Romero]

Hi,

So you are doing connectable advertising? Who is doing that - the phone or the device using the MPSL?

Brosnan said:

do continuous scan to receive packets

 If you are doing continuous scanning then (almost) all the radio time is used by that, so there is no time to transmit any other packets (until you stop scanning). It's not clear how much and what the device using the MPSL is suppose to do. I will need more details in order to advise you about which alternative will suit your application the best.

Brosnan said:

Also do we get to modify the thread and BLE timeslot durations?

For BLE the timeslot duration is determined by the packet length (short packets and long intervals means more tie for other things) or the scan window. Thread will take whatever time is left after BLE is done, but BLE will always have priority over 802.15.4, so for using this method it requires that the scanning interval and scanning period must be set as small as possible, to ensure the Thread data traffic is not blocked.

Best regards,

Marjeris