Peripheral, central and mesh simultaneously in nRF52840

[someone]

I know that RF52840 could act simultaneously as the Advertiser\Peripheral and Observer\Central and I saw Nordic's recent demo video of BT + Thread co-existence. However, it's unclear to me will it work if everything is "on" or there are some limitations on possible usage.

We try to build an application, which requires any of the following configurations:

1. Peripheral, central + Bluetooth mesh
2. Peripheral, central + Thread

I was told by a guy from Bluetooth SIG that the first option is not limited by the specifications and it all depends on a stack implementation, but generally must be possible.

Are any of these combinations possible? If no, I'd be highly appreciated if someone could explain the details of the limitation.

[Sigurd]

Hi,

Both of the configurations you list are possible.

Limitations:

1. Concurrent BLE + Mesh activity:

By design, the SoftDevice activity is prioritized over mesh activity. Therefore, you should keep the connection and advertisement intervals used by the SoftDevice as large as possible (i.e. infrequent) when using Bluetooth low energy connections. If scanning, keep the scan duty cycle as low as possible. You should also reduce mesh activity while the SoftDevice is doing fast advertising and continue normal activity after a connection is established.

2. BLE + Thread:

As shown in the concurrent Thread and Bluetooth 5 video, the radio time is divided between Thread and BLE. Using a arbitration algorithm and with the very short switching period on the nRF52 radio, you have a seamless transition between Thread and BLE. But note that due to nature of the time-multiplex solution, using the BLE Central role here is ineffective compared to a stand-alone BLE central.

---

Only BLE: The nRF52 have support for 20 concurrent BLE connections , where you can freely configure each link in any combination between Peripheral and Central.

[someone]

Thank you for the answer. It seems that #2 doesn't fit the requirements, as Central role becomes inefficient here. Regarding #1 it's still unclear to me. Increasing advertisement intervals should not be an issue, however, what are general recommendations for concurrency? Let's say 300ms is large or small interval? And I also didn't understand regarding the scanning, mainly our application requires continuous scanning, does it mean we need somehow manually stop\start scanning? Shouldn't it be possible to do transparently to SDK user?

[Sigurd]

With 300 ms advertising interval the central device should be able to find the device within short time. For connectable advertising, the advertising interval can be between 20 ms to 10240 ms. For non-connectable advertising (typical beacons) the advertising interval can be minimum 100 ms. E.g. Eddystone beacons use 200 ms advertising interval.

You don’t need to manually start/stop scanning, you can keep the scanner on all the time. Regarding the “scan duty cycle”, in BLE we have scan interval and scan window, that decide how often the central scans and how long. You just tell the SoftDevice the settings you want to use, and tell it to start scanning, and everything else is transparent and done automatically for you in the SoftDevice.

[someone]

Thank you for the great answer!

[ToasTer86]

Hey Sigurd, thanks a lot for explaining this earlier. I wonder how "ineffective" the central role will be when using Thread? I will only be working with a maximum of 2~4 other peripherals.

Thanks a lot in advance