Why too much data is lost when there is 11 peripheral connected to 1 central via NUS connection

[laumung]

Hello, I have a big problem now. I set up a BLE network with 11 peripheral boards connected to 1 central board via NUS protocol. the peripheral board is based on NRF52840 and the central board is NRF52840 DK board. The peripheral board read the sensor at 50Hz and 16 bytes per reading. Every 14 readings, the sensor board will send the data as s packet to the central board, and the central board transfers data to the laptop via the UART port. When there is only one peripheral, it is fine.

But when the peripheral boards increase, the data will be lost and most data cannot transfer to the laptop. What causes the problem? Thanks. Any help will be appreciated.

[Einar Thorsrud]

Hi,

You are sending quite long packets (sensor data per packet is 16 byte * 14 readings = 224 byte), so it takes a bit of time on air. Ignoring any overhead and just looking at sensor data this is about 9 kbps with 11 peripherals ,which in itself is not too much. However, the central will need to schedule time for all connections. Depending on connection parameters and number peripherals the SoftDevice scheduling may be difficult. You can see more about SoftDevice scheduling here, and specifically Connection timing as a Central is relevant.

With your fairly low total data rate you should be able to get everything through with sensible connection parameters. Which connection parameters do you use? It may make sense to send less data more often, using shorter event lengths and shorter packets. That way each connection can exchange data more frequency and you can add some margin for retransmissions (which will happen more seldom with shorter packets).

[laumung]

Hi Einar, I understood what you said in your poster. Which parameter should I change for correction?  I changed the APP_ADV_INTERVAL from 64(default setting) to 600 and the number of peripherals can add up to 15. But the central board will reset every 6 or 7 second as shown below.

...

Which other parameter can be changed to cancel the regular resetting? Thanks.

[Einar Thorsrud]

Hi,

If you have very rapid advertising that will cause problems when things are tight, so that is an important adjustment. See SoftDevice timing-activities and priorities.

If you use a connection interval of 7.5 ms and a event length of 6 * 1.25 ms  = 7.5 ms then that means that your connection parameters are suited for a single connection. You should make sure that you can fit all events in a connection interval as shown here. That means that if you have set the event length to 6, and want say 15 peripherals, you should have at least 6 * 1.25ms * 15 = 112.50 ms connation interval. That said, if you only need to send one long packet every event, you could reduce the event length to 3 (3.75 ms) or possibly even 2 (2.5 ms), and reduce the connection interval accordingly.

Regarding the cause for the reset I assume you can start searching in your code for "SYSTEM RESET". I do not find that string in the SDK (17.0.2), but clearly you log something before resetting so that should be possible to find.

[laumung]

Thank you Einar, after I change the APP_ADV_INTERVAL from 64(default) to 3000. There are more peripheral boards can join the BLE network. Thanks a lot. 

#define APP_ADV_INTERVAL 3000 //64 /**< The advertising interval (in units of 0.625 ms. This value corresponds to 40 ms). */