Multiprotocol With Thread + Custom Protocol

RE: Multiprotocol With Thread + Custom Protocol

Legoabram — Tue, 02 Jun 2020 15:20:17 GMT

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.

RE: Multiprotocol With Thread + Custom Protocol

Edvin — Tue, 02 Jun 2020 14:28:39 GMT

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

RE: Multiprotocol With Thread + Custom Protocol

Legoabram — Sat, 30 May 2020 22:24:21 GMT

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?

RE: Multiprotocol With Thread + Custom Protocol

Edvin — Wed, 06 May 2020 12:57:21 GMT

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