Peripheral, central and mesh simultaneously in nRF52840

RE: Peripheral, central and mesh simultaneously in nRF52840

Sigurd — Sun, 03 Dec 2017 20:49:54 GMT

Hi ToasTer86,

Overall you will have less radio time available for BLE, so you will get a lower throughput compared to a stand-alone BLE central. Let's say that you are running BLE 4.2 with DLE and long ATT MTU, where you one a one-to-one link could get 775 Kbps. Let's say Thread uses 50% of the radio time, and that this leaves you with ~400 kbps for your BLE links. Dividing this across your 4 peripherals, you would maybe get around 100 Kbps max for each link. So for almost all regular BLE applications it will work perfectly fine. If you however experience any trouble with the BLE links, you could try to increase the BLE connection interval.

RE: Peripheral, central and mesh simultaneously in nRF52840

ToasTer86 — Thu, 30 Nov 2017 16:58:52 GMT

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

RE: Peripheral, central and mesh simultaneously in nRF52840

someone — Mon, 16 Oct 2017 13:47:15 GMT

Thank you for the great answer!

RE: Peripheral, central and mesh simultaneously in nRF52840

Sigurd — Mon, 16 Oct 2017 09:38:57 GMT

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.

RE: Peripheral, central and mesh simultaneously in nRF52840

someone — Fri, 13 Oct 2017 16:03:16 GMT

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?

RE: Peripheral, central and mesh simultaneously in nRF52840

Sigurd — Fri, 13 Oct 2017 12:58:43 GMT

Hi,

Both of the configurations you list are possible.

Limitations:

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.

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.