Receive regular Ble packets from multiple peripherals

[F_Vahid]

Dear Nordic support team,

We are currently working on a motion tracking project that involves sending quaternion matrices from 8 individual devices (custom boards with nRF52840) to a central device (nRF52840 dongle). The peripherals are programmed to send packets every 16.8ms (59.5 Hz refresh rate), and the central device receives these packets and prints them on the com port using the USB CDC ACM module. However, we have noticed that when only one device sends data, the data on the com port is regular, with delta_t~=15ms. But when multiple devices send data, the received data (two successive packets from one specific device) on the com port is irregular, and the timestamps vary from 1 to 80ms.

We do not believe that the issue is with the peripheral devices because they are programmed to send data regularly and independently from the central device (which does not send any data to the peripherals). We have also tested the USB module and found that it is rarely the cause of the issue, as it can write test data every 500us on the com port. However, we suspect that the problem is related to the central device's concurrent receive function, which may be affecting its performance.

We are currently using a code for the central device that can be found at https://github.com/NordicPlayground/nrf52-ble-app-uart-c-multilink. We have attached the main and configuration files for both the peripheral and central devices. We would greatly appreciate your help in resolving this issue, as we require the motion data to be received regularly. Is it possible to receive 8 packets every 15ms regularly?

Thank you for your support, help, and time.

Best regards.

[F_Vahid]

Susheel Nuguru said:

BLE needs HFCLK and it is recommended to have a high accuracy XTAL for it. 

Since we use the pca10059 dongle, it has two crystals (i.e., 32kHz and 32MHz).

Susheel Nuguru said:

Are you getting BLE_NUS_C_EVT_NUS_TX_EVT as expected every ~2ms? If yes, then what is the time taken by the snprintf and app_usbd_cdc_acm_write? you can toggle a gpio just after this event is called and toggle the same gpio again just before leaving this event handling. That way you will get an accurate processing time for this event. Without knowing the exact number of how long this event processing takes, it is hard for me to look into other clock accuracy related reasons.

We tested your suggestion. We set a Dongle pin (0,15) at the beginning of the ble_nus_c_evt_handler function and clear that pin at the end of the function. The function code is as follows:

static void ble_nus_c_evt_handler(ble_nus_c_t * p_ble_nus_c, ble_nus_c_evt_t const * p_ble_nus_evt)
{
    ret_code_t err_code;
    uint16_t length;
    uint8_t dat_tab[36];
    char *pt;
    int i=0;
    int j=0;
    nrf_gpio_pin_set(15);


    switch (p_ble_nus_evt->evt_type)
    {
        case BLE_NUS_C_EVT_DISCOVERY_COMPLETE:
            //NRF_LOG_INFO("Discovery complete.");
            err_code = ble_nus_c_handles_assign(p_ble_nus_c, p_ble_nus_evt->conn_handle, &p_ble_nus_evt->handles);
            APP_ERROR_CHECK(err_code);

            err_code = ble_nus_c_tx_notif_enable(p_ble_nus_c);
            APP_ERROR_CHECK(err_code);
            //NRF_LOG_INFO("Connected to device with Nordic UART Service.");
            break;

        
        
        case BLE_NUS_C_EVT_NUS_TX_EVT:
        NRF_LOG_HEXDUMP_DEBUG(p_ble_nus_evt->p_data, p_ble_nus_evt->data_len);
        memcpy(m_nus_data_array, p_ble_nus_evt->p_data, p_ble_nus_evt->data_len);
        length = p_ble_nus_evt->data_len;


        // Send readable data through CDC ACM
        char cdc_data[BLE_NUS_MAX_DATA_LEN];
        if(m_nus_data_array[0]<=20)
        {
          sprintf(cdc_data, "%d,%d,%d,%d,%d\r\n", m_nus_data_array[0],m_nus_data_array[1],m_nus_data_array[2],m_nus_data_array[3],m_nus_data_array[4]);
           ret_code_t ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,cdc_data,strlen(cdc_data));
        }
        else if(m_nus_data_array[0]==51){
        //if(length<15)
        //{
        //sprintf(cdc_data, "%d,%d,%d\r\n%d,%d,%d\r\n%d,%d,%d\r\n%d,%d,%d\r\n%d,%d,%d\r\n",m_nus_data_array[0],m_nus_data_array[1]-100,m_nus_data_array[6]-125,
        //m_nus_data_array[0],m_nus_data_array[2]-100,m_nus_data_array[7]-125,m_nus_data_array[0],m_nus_data_array[3]-100,m_nus_data_array[8]-125,
        //m_nus_data_array[0],m_nus_data_array[4]-100,m_nus_data_array[9]-125,m_nus_data_array[0],m_nus_data_array[5]-100,m_nus_data_array[10]-125);
        //}
        //else
        //{
        //float step_rate = ((float) m_nus_data_array[24])/10;
        //long int step_count = (m_nus_data_array[13])|(m_nus_data_array[14]<<8)|(m_nus_data_array[15]<<16);
        //long int distance = (m_nus_data_array[16])|(m_nus_data_array[17]<<8)|(m_nus_data_array[18]<<16);
        //float speed = (float) m_nus_data_array[19]/10;
        //float calories = ((float) ((m_nus_data_array[21])|(m_nus_data_array[22]<<8)|(m_nus_data_array[23]<<16)))/10;
        //float sdnn = m_nus_data_array[25]*10+((float) m_nus_data_array[26]/10);
        //float rmssd = m_nus_data_array[27]*10+((float) m_nus_data_array[28]/10);
        //float sdsd = m_nus_data_array[29]*10+((float) m_nus_data_array[30]/10);
        //float sd1 = m_nus_data_array[31]*10+((float) m_nus_data_array[32]/10);
        //float sd2 = m_nus_data_array[33]*10+((float) m_nus_data_array[34]/10);
        //float bsi = m_nus_data_array[35]+((float) m_nus_data_array[36]/100);
        
        //sprintf(cdc_data, "%d,%d,%d\r\n%d,%d,%d\r\n%d,%d,%d\r\n%d,%d,%d\r\n%d,%d,%d,%d,%d,%d,%d,%f,%d,%f,%f,%f,%f,%f,%f,%f,%f\r\n",
        //m_nus_data_array[0],m_nus_data_array[1]-100,m_nus_data_array[6]-125,
        //m_nus_data_array[0],m_nus_data_array[2]-100,m_nus_data_array[7]-125,
        //m_nus_data_array[0],m_nus_data_array[3]-100,m_nus_data_array[8]-125,
        //m_nus_data_array[0],m_nus_data_array[4]-100,m_nus_data_array[9]-125,
        //m_nus_data_array[0],m_nus_data_array[5]-100,m_nus_data_array[10]-125,m_nus_data_array[11],m_nus_data_array[12],
        //step_count,distance,speed,m_nus_data_array[20],calories,step_rate,sdnn,rmssd,sdsd,sd1,sd2,bsi);
        //}
        }


        //ret_code_t ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,cdc_data,strlen(cdc_data));
         //ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,cdc_data,strlen(cdc_data));
         //ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,cdc_data,strlen(cdc_data));
         //ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,cdc_data,strlen(cdc_data));
         //ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,cdc_data,strlen(cdc_data));
        
        //if(ret != NRF_SUCCESS)
        //{
        //    //NRF_LOG_INFO("CDC ACM unavailable, data received: %s", m_nus_data_array);
        //}
            break;


        case BLE_NUS_C_EVT_DISCONNECTED:
            //NRF_LOG_INFO("Disconnected.");
            scan_start();
            break;
    }
    nrf_gpio_pin_clear(15);
}

The result for a single connected peripheral and for a 200ms time range has been measured as:

As shown, there are 13 received packets in the 200ms time range (~16ms for each packet).  However, there are some gaps with a size of 30ms which is higher than the desired value (previously we have ignored these tolerances). However, for a better look, we zoomed and the following images have been drawn.



As seen, the post-processing takes time around 40us which is not high.
However, to have a better vision we captured two figures (please see the following images) that show the time stamp of received packets for situations where a single (first image) and two peripherals (second image) send data to the central. It is noted that in the second image, two devices send data to central, but the central write only the first device's data on the com port.


Overall, there is some irregularity even single device sends data to central. However, the situation becomes worse when higher numbers of peripherals send data to the central.
Can you help us in solving this issue? It is noted that regular data reception is necessary for a smooth avatar movement in the motion-tracking application. We will appreciate any help and information about this issue. Thanks again, dear Susheel.