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.

[Susheel Nuguru]

Hi, 

The bottleneck is most likely in your central device. You need to benchmark the postprocessing time of each packet received in central (from each peripheral) from the time your application receives it to the instance the processed packet info is sent to the USB_CDC ACM (inside the USB driver). 

If 8 peripherals are sending packets each at ~16ms period, then the central is receiving these packets at the rate of ~2ms.  If the post processing of each packet from the time it is received by the BLE controller->application processing->USB_CDC handling is greater than 2ms, then you have a bottleneck in the post processing of the incoming packets. This is not a defect in the central, but a limitation on how much processing you can do on a single core MCU with a limited processing speed.

[F_Vahid]

Dear susheel

Thank you for your kind and quick response. I understand that post-processing could cause delays in the central device's performance, and we have already removed the post-processing section (see below code). Currently, we are only writing the received packets to a buffer and sending them to the USB module in the ble_nus_c_evt_handler function. However, the irregular delays in receiving data from multiple devices still persist.

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;

    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;
    }
}

Could there be any problems in the BLE configuration on either the central or peripheral side that could be causing this issue? Is the ble_nus_c_evt_handler function the best place for writing data to the USB port?

Any help you can provide in resolving this issue would be greatly appreciated. Thank you again for your support and assistance.

[F_Vahid]

Could the issue be related to the low-frequency clock utilization? Is BLE softdevice uses a low-frequency clock? Since  is_hfclk_enabled = (bool) (NRF_CLOCK->HFCLKSTAT & CLOCK_HFCLKSTAT_SRC_Msk); return false.

[Susheel Nuguru]

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

F_Vahid said:

Is the ble_nus_c_evt_handler function the best place for writing data to the USB port?

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.

[F_Vahid]

Susheel Nuguru said:

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

We will check it

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.

It's unlikely that we get a Nordic UART Service (NUS) event every 2ms since the motion devices are not necessarily synchronized with each other. It's possible that the central device receives data packets from two individual devices in less than 2ms, although they send every 16ms, and we have eight packets every 16ms (with time differences that may vary from case to case).

Thank you for your helpful suggestion. We will test it out and report back with the results.