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

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

Einar Thorsrud — Thu, 01 Jul 2021 10:44:41 GMT

Hi,

As you are making both sides it makes sense to set the same value as min and max on both sides. Also, make sure that the interval is long enough. Compared to connections and event length If you have an event length of 2.5 ms (NRF_SDH_BLE_GAP_EVENT_LENGTH set to 2 in both peripheral and central) and you have 11 peripherals then you should have at least 2.5 ms * 11 + time for advertising, so it makes sense with no less than 30 ms connection interval.

Regarding the disconnects I do not know why you disconnect. is it because of an error check is hit when buffers are full? If so, it might be that you should look into the possibility to reduce the amount of data you need to transfer.

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

laumung — Wed, 30 Jun 2021 15:05:36 GMT

Hi Einar, I have change the and NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL to 11 * NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL but there are many reconnection during the transferring. I am wondering if I should change the

#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(1900, UNIT_1_25_MS) /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */

two parameters as same as in the central board? Thanks.

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

laumung — Fri, 25 Jun 2021 15:31:02 GMT

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). */

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

Einar Thorsrud — Mon, 21 Jun 2021 10:47:00 GMT

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.

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

laumung — Thu, 17 Jun 2021 17:42:59 GMT

Is the packet length parameter defined as below?

// <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size. 
#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
#endif

BTW, there is no error code shown for the resetting. How can I program to send debug information when resetting occurs?

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

laumung — Thu, 17 Jun 2021 17:12:26 GMT

Hi, here is the configuration for connection in central board.

// <o> NRF_SDH_BLE_GAP_EVENT_LENGTH - GAP event length. 
// <i> The time set aside for this connection on every connection interval in 1.25 ms units.

#ifndef NRF_SDH_BLE_GAP_EVENT_LENGTH
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 6
#endif

// <o> NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL - Determines minimum connection interval in milliseconds. 
#ifndef NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL
#define NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL 7.5
#endif

// <o> NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL - Determines maximum connection interval in milliseconds. 
#ifndef NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL
#define NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL 30
#endif


// <o> NRF_SDH_BLE_GAP_EVENT_LENGTH - GAP event length. 
// <i> The time set aside for this connection on every connection interval in 1.25 ms units.

#ifndef NRF_SDH_BLE_GAP_EVENT_LENGTH
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 6
#endif


// <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
#ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 0
#endif

// <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links. 
#ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
#define NRF_SDH_BLE_CENTRAL_LINK_COUNT 16
#endif

// <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Total link count. 
// <i> Maximum number of total concurrent connections using the default configuration.

#ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
#define NRF_SDH_BLE_TOTAL_LINK_COUNT 16
#endif

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

laumung — Thu, 17 Jun 2021 17:04:14 GMT

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.

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

Einar Thorsrud — Thu, 17 Jun 2021 09:27:43 GMT

Please let me know your complete configuration. The relationship between connection interval, event length, packet length and number of connections is essential as you can see here. Also, what is the cause for the reset?

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

laumung — Thu, 17 Jun 2021 02:49:28 GMT

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?

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

Einar Thorsrud — Wed, 16 Jun 2021 09:09:11 GMT

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)?

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

laumung — Wed, 16 Jun 2021 06:46:11 GMT

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.

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

laumung — Wed, 16 Jun 2021 02:25:24 GMT

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.

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

Einar Thorsrud — Tue, 15 Jun 2021 10:23:46 GMT

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).