Multiprotocol With Thread + Custom Protocol

[Legoabram]

First, by "Custom Protocol" I just mean that I need to directly access the radio to transmit or receive single packets occasionally. The literature appears to indicate that this is possible ("(Dynamic Multiprotocol) may be used to run several radio protocols simultaneously") given the reference to "several", but for the life of me I can't figure out how. I understand that this would involve using the nrf_802154 driver which is bundled with the Thread SDK. However, this driver appears to be more singleton like, which would indicate that only one protocol could use it at any given time. But this may be more due to me not having a clue in the world how to use it.

Specifically, I'm trying to set this up on an nrf52840 with SDK 15.2.0 / Thread and Zigbee SDK 2.0.0

So in short, with Thread using the 802.15.4 radio driver, how can I schedule occasional single packet transmission/reception without messing up the Thread SDK?

[Edvin]

Hello,

This seems a bit tricky on first glance. The reason for this is that in the multiprotocol examples in the SDK, it is the softdevice that control the timeslots. 

When you do BLE+openthread, the BLE stack will always have the top priority, and the openthread stack will use the softdevice API to request radio slots between the timeslots that are used for BLE.

I believe this is done in multiprotocol_802154_mode_set() in multiprotocol_802_15_4.c. I believe this function is implemented in libopenthread-nrf52840-softdevice-sdk.lib. You would probably need to rebuild this library in order to change it from using the softdevice to implementing custom timeslots for the proprietary radio. The messages that you are going to send and receive, are they on the 802.15.4 layer?

BR,

Edvin

[Legoabram]

Sorry for not getting back to this in a timely manner. Technically, no, they aren't on the 802.15.4 layer. I'd either be attempting to sniff out RSSI on BLE channels, or sending iBeacon advertisements. Which one will depend on some other factors which I won't detail here. So ideally, I'd need unrestricted access to the RADIO like the timeslots provide. But from the sound of it, outside of the Softdevice, there are no provisions for this?

That said, what kind of overhead would I be expecting if I were to implement a custom timeslot api for Thread to use?

[Edvin]

Well. The timeslot API is an API for the softdevice, to reserve a timeslot from outside the BLE timeslots.

I am not sure if this is possible. I would have to check with our Thread Team. The challenge you will encounter either way is that if you intend to scan for a long time on a BLE channel, then you will have a very bad Thread performance. Usually, when mixing BLE and Thread, it is a BLE peripheral. Advertising use very little time on the radio, and so does a connection. Scanning however takes as long as you set it to scan for, and the chances of picking up a packet is as large as the scan window/scan interval ratio. The Openthread performance will be equally bad. 

You can read a bit about a custom multiprotocol here:

https://github.com/NordicSemiconductor/nRF-IEEE-802.15.4-radio-driver/wiki/Multiprotocol-support

So from a software perspective, it is possible with a bit of work. But whether you will be able to certify a FTD (full thread device) router with that much packet loss is another question.

I can ask the thread team, but you may need to check with OpenThread whether such a device will be approved. You will probably need to specify the scan interval and scan window you think about using.

BR,

Edvin

[Legoabram]

Oh, minor correction. When sniffing RSSI, I intend to only have the radio on for very short periods of time, only about as frequently as advertisements. I'll take a look at the link you provided.