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, thank you for your kind reply. I remember I have read some post suggest that it's better to increase the BLE transfer rate with larger packet size in every transmission. Maybe I am wrong. I have checked two reference in your poster and there are many parameters. I list the parameters about BLE connection in my project. Hope it helps.

In peripheral board, which collects the sensor data and transfer to central board, the parameter are shown below.

#define APP_BLE_CONN_CFG_TAG            1                                           /**< A tag identifying the SoftDevice BLE configuration. */

#define DEVICE_NAME                     "Nordic_UART_SAADC_01"                               /**< Name of device. Will be included in the advertising data. */
#define NUS_SERVICE_UUID_TYPE           BLE_UUID_TYPE_VENDOR_BEGIN                  /**< UUID type for the Nordic UART Service (vendor specific). */

#define APP_BLE_OBSERVER_PRIO           3                                           /**< Application's BLE observer priority. You shouldn't need to modify this value. */

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

#define APP_ADV_DURATION                18000                                       /**< The advertising duration (180 seconds) in units of 10 milliseconds. */

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(10, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(1800, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000)                       /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000)                      /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                           /**< Number of attempts before giving up the connection parameter negotiation. */

#define UART_TX_BUF_SIZE                256                                         /**< UART TX buffer size. */
#define UART_RX_BUF_SIZE                256                                         /**< UART RX buffer size. */

static uint16_t   m_conn_handle          = BLE_CONN_HANDLE_INVALID;                 /**< Handle of the current connection. */
static uint16_t   m_ble_nus_max_data_len = BLE_GATT_ATT_MTU_DEFAULT - 3;            /**< Maximum length of data (in bytes) that can be transmitted to the peer by the Nordic UART service module. */
static ble_uuid_t m_adv_uuids[]          =                                          /**< Universally unique service identifier. */
{
    {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
};

/** @brief Default ATT MTU, in bytes. */
#define BLE_GATT_ATT_MTU_DEFAULT          128      //23

/**@brief Invalid Attribute Handle. */
#define BLE_GATT_HANDLE_INVALID            0x0000

/**@brief First Attribute Handle. */
#define BLE_GATT_HANDLE_START              0x0001

/**@brief Last Attribute Handle. */
#define BLE_GATT_HANDLE_END                0xFFFF

/** @defgroup BLE_GATT_TIMEOUT_SOURCES GATT Timeout sources
 * @{ */
#define BLE_GATT_TIMEOUT_SRC_PROTOCOL      0x00  /**< ATT Protocol timeout. */
/** @} */

In central board, which receive data from sensor board, the parameters are shown below.

#define APP_BLE_CONN_CFG_TAG    1                                       /**< Tag that refers to the BLE stack configuration set with @ref sd_ble_cfg_set. The default tag is @ref BLE_CONN_CFG_TAG_DEFAULT. */
#define APP_BLE_OBSERVER_PRIO   3                                       /**< BLE observer priority of the application. There is no need to modify this value. */

#define UART_TX_BUF_SIZE        1024                                     /**< UART TX buffer size. */
#define UART_RX_BUF_SIZE        1024                                     /**< UART RX buffer size. */

#define NUS_SERVICE_UUID_TYPE   BLE_UUID_TYPE_VENDOR_BEGIN              /**< UUID type for the Nordic UART Service (vendor specific). */

#define ECHOBACK_BLE_UART_DATA  1                                       /**< Echo the UART data that is received over the Nordic UART Service (NUS) back to the sender. */

#define Packet_Len        7
#define Channel_Num       6

BLE_NUS_C_ARRAY_DEF(m_ble_nus_c, NRF_SDH_BLE_CENTRAL_LINK_COUNT);       /**< BLE Nordic UART Service (NUS) client instances. */
NRF_BLE_GATT_DEF(m_gatt);                                               /**< GATT module instance. */
BLE_DB_DISCOVERY_DEF(m_db_disc);                                        /**< Database discovery module instance. */
NRF_BLE_SCAN_DEF(m_scan);                                               /**< Scanning Module instance. */
NRF_BLE_GQ_DEF(m_ble_gatt_queue,                                        /**< BLE GATT Queue instance. */
               NRF_SDH_BLE_CENTRAL_LINK_COUNT,
               NRF_BLE_GQ_QUEUE_SIZE);

static uint16_t m_ble_nus_max_data_len = BLE_GATT_ATT_MTU_DEFAULT - OPCODE_LENGTH - HANDLE_LENGTH; /**< Maximum length of data (in bytes) that can be transmitted to the peer by the Nordic UART service module. */

Appreciate your kind help. 

[laumung]

Hi Einar, I reduced the data size in the packet to 8 and 4 tonight. Unfortunately the problem were still there. When up to 8 or 9 peripherals added to the BLE network, the central board will loose all the connection and re-connect to the peripherals after reset all the peripherals. BTW, can we find out what cause the problem by the debug information? Thanks.

[Einar Thorsrud]

Hi,

You are right that for maximum throughput you should use long packets in general. I was thinking it might not be a good idea in this case but that is not the major concern. The major point is that you should adapt the event length to the length of the packet you send, and ensure that you can fit an event for each connection within each connection interval, as shown in Connection timing as a Central. What packet event length do you use with which packet length? You should make sure that fits in the connection interval you use. What is that (I just see min and max in your peripheral)?

[laumung]

Hi Einar, I understood what you said in your poster. Which parameter should be modified to make more peripherals? I changed the APP_ADV_INTERVAL from 64(default) to 600 and the peripherals can add up to 15. But the central board will reset every 6 or 7 seconds after the change even the number of peripherals increase. The debug information of the central board is shown below.

Which parameter else should I change to stop the reset?