How do I use the nRF5 Connect SDK for dynamic multi-protocol development

[Lipeng Yang]

Dear all and Nordic Staff:

I am learning about dynamic multiprotocols and found examples of dynamic multiprotocols for Thread and BLE in the "nRF5 SDK for Thread and Zigbee". But I want to finish this case in nRF5 Connect SDK.

My question is whether I can implement such a port, or whether there are already dynamic multi-protocol implementations in the nRF5 Connect SDK.

Thank you for your help.

Best regards.

[Marte Myrvold]

Hi,

There is already support for dynamic multiprotocol in nRF Connect SDK. The Zigbee Light Switch and Thread CoAP Client samples support multiprotocol out of the box, and all you need to do is enable the multiprotocol extension. How to do this is explained in each of the sample's documentation.

The Multi-Protocol Service Layer (MPSL) handles many of the tasks involved in multiprotocol applications in the nRF Connect SDK, so implementing a multiprotocol Zigbee + BLE or Thread + BLE application is even more straightforward in the nRF Connect SDK than it was in the nRF5 SDK.

If you want to know more, I recommend reading Multiprotocol support in our documentation and checking out the two samples I mentioned.

Best regards,
Marte

[Lipeng Yang]

Hi,

First of all, thanks for your reply. I had been looking for examples in the nRF5 SDK for Thread and Zigbee, but none of them were a good fit. I've spent months looking for dynamic multiprotocol cases in order to learn dynamic multiprotocol. Your reply saved me a lot of time.

Secondly, the cases mentioned in your reply are very good, which is exactly what I need. I will carefully study the case you recommend, although it will take a little time.

Finally, could you give me some advice on how to learn dynamic multi-protocol, because I feel like my learning progress is too slow.

Thank you for your reply.

Best regards,

Lipeng

[Lipeng Yang]

Hi,

Marte Myrvold said:

What specifically is it you want to learn?

My current plan is to apply dynamic multi-protocol technology to wireless sensors, using local area networks to send data. I don't know the details yet. My current job is to tease out the dynamic multi-protocol workflow, from the RF module to the application layer.

Looking forward to your reply.

Best regards,

Lipeng

[Marte Myrvold]

Hi Lipeng,

Lipeng Yang said:

My current job is to tease out the dynamic multi-protocol workflow, from the RF module to the application layer.

Then I recommend reading the links in my previous post, as they explain how MPSL handles this. The main thing is that MPSL allows for the radio drivers to negotiate for transmission timeslots.

Best regards,
Marte

[Lipeng Yang]

Hi Marte,

Marte Myrvold said:

Then I recommend reading the links in my previous post, as they explain how MPSL handles this. The main thing is that MPSL allows for the radio drivers to negotiate for transmission timeslots.

Okay, I've got some ideas. And I have one more question. Why didn't Nordic continue to use the previous radio scheduler and instead use the current MPSL? Both are time slicing, so what are the advantages of the latter?

Best regards,

Lipeng

[Marte Myrvold]

Hi Lipeng,

One main reason is that the nRF Connect SDK integrates the Zephyr RTOS, compared to the bare-metal nRF5 SDK.

The SoftDevice controller in the nRF Connect SDK still provides the multi-protocol support used in the SoftDevices in the nRF5 SDK, but the overlaying API is different. The MPSL also provides multiple additional features other than multiprotocol support and timeslots, such as TX power control, clock control, as well as IEEE 802.15.4 and Bluetooth external radio coexistence.

Best regards,
Marte

[Lipeng Yang]

Hi Marte,

Thank you for your help. This is very useful for me to learn dynamic multi-protocol.

Best regards,

Lipeng