nrf52840 Bluetooth and 802.15.4 multiprotocol example project

[Liam]

Hi,

 For a number of upcoming projects we require 802.15.4 and BLE dynamic multiprotocol support. We need to select a SoC to implement this.

 We like the look of the nrf52840 and see multiprotocol  should be possible using the nRF-IEEE-802.15.4-radio-driver. 

 A number of people have already asked about this but is there an example showing this working yet? Or if someone has got it working would firstly say they've done it and then, maybe, let us have the code ( or even binary ) please?

 We have just had Silicon Labs pull 802.15.4 support from their modules that we were just about to design in so time is critical for us. We don't have the time to learn an API and get to grips with new hardware/software and the inevitable debugging to get to the point deciding to use the nrf52840. If we can prove multiprotocol works we will almost certainly use the nrf52840.

kind regards

Liam

[Edvin]

Hello Liam,

I don't think we have any examples using the "pure" 802.15.4 driver with BLE, but we have several examples in our Thread and Zigbee SDK using multiprotocol BLE and Thread or ZigBee (which uses the 802.15.4 driver), so yes. It is possible to use the BLE stack (softdevice) together with the softdevice. I know you are not looking for API right now, but we have something called the TimeSlot API, which requests timeslots where you can use the radio as you like, in between the BLE radio events. 

Thread/ZigBee SDK multiprotocol example:

ThreadSDK\examples\multiprotocol\ble_thread

ThreadSDK\examples\multiprotocol\ble_zigbee

The TimeSlot API is described here. (It is described for SDK11, which is kind of old, but it works on the new SDKs as well, without modifications).

Best regards,

Edvin

[Liam]

Hi Edvin,

Thank you for the reply.

 I've had a look at the Thread and Zigbee SDK. It provides a 802.15.4 radio driver module which seems to provide "raw" access to the 802.15.4 radio but not a "proper" 802.15.4 stack. Most comments on 802.15.4 multiprotocol suggest to use this. To me there would appear to be a considerable amount of work to get the radio driver to the point where it would associate with a 802.15.4 coordinator.

There seems to be a full 802.15.4 stack provided in SDK 15. It also provides Bluetooth. So would it be possible to use the TimeSlot API to request slots from the Bluetooth side and run the 802.15.4 within them?

regards

Liam

[Edvin]

Hello Liam,

Yes indeed. That is in fact the method that is used in our multiprotocol examples (where BLE is one of the protocols). The reason for this is that the BLE stack is a very time sensitive protocol, and hence, it will get 1st priority, and the other protocols will run in the timeslots in between. Unfortunately, we don't have an example doing exactly this already, but the TimeSlot API should be quite easy to use, so you should be able to do what you request.

Best regards,

Edvin

[Liam]

Hi Edvin,

 I've done a bit of work on this now.

 I have converted our existing code to use the 802.15.4 Stack API present in SDK15.2. Apart from a problem with seeing a coordinator beacon payload this now works as a endpoint and connects to our existing 802.15.4 coordinator.

 Secondly, using the BLE template from SDK15.2 I have implemented the timeslot API. I think this is working. A LED on the DK is being switched on and off by cases NRF_RADIO_CALLBACK_SIGNAL_TYPE_START and NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 in nrf_radio_signal_callback_return_param_t.

 So I now want to merge the two. So could you confirm that on NRF_RADIO_CALLBACK_SIGNAL_TYPE_START I should start calling the IEEE 15.4 handler and stop on NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 . 

 Do I need to worry about the state of the IEEE stack between timeslots i.e. is it preserved? Do I have to restore the radio state (channel, power etc) at any point or does the timeslot API take care of it?

 When should I initialise the IEEE stack?

 Sorry for all the questions; I just want to make sure I'm taking the right approach.

kind regards

Liam

[Edvin]

That is correct. From NRF_RADIO_CALLBACK_SIGNAL_TYPE_START you have control of the radio, and NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 is the callback called before the BLE event, and this is where you should gracefully shut down what you are doing in order to pass the radio over to the SoftDevice.

"Do I need to worry about the state of the IEEE stack between timeslots"?

This depends on how it is set up. I haven't looked too much into the 802.15.4 stack. By the look of the SDK15.2.0\examples\802.15.4\wireless_uart example, it looks like the state of this would be saved, and doesn't need to be set up at every timeslot. I guess you will find out quite fast whether or not it is saved between the timeslots.

You can initialize the IEEE at any time, but when you require the radio, it must either be in a timeslot, or before you use the softdevice.

Best regards,

Edvin