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]

Dear Susheel,

Thank you for your response. While we understand your recommendation to use BLE_NUS_C_EVT_NUS_TX_EVT as anchor points with improved soft device priorities, we think that it is difficult to ensure that all priorities are consistent and running in the appropriate order.

Given this, we were wondering if there might be an alternative solution to identifying packet reception immediately, without relying on BLE_NUS_C_EVT_NUS_TX_EVT. If there are any other suggestions or recommendations you could provide, we would greatly appreciate it.

Thank you again for your assistance.

[Susheel Nuguru]

My sincere apologies for the late response Vahid. 

F_Vahid said:

Given this, we were wondering if there might be an alternative solution to identifying packet reception immediately, without relying on BLE_NUS_C_EVT_NUS_TX_EVT

There is no easy way to detect the packet reception without the BLE stack first processing it and notifying the application using SWI interrupt. 

One other way is to use RADIO notifications but it is similar way of notifications to the application.

The only way I can see this working for you is to have other priorities lower than the SWI event handler priority so that when the packet is received, softdevice does the postprocessing and notifies the application and this will immediately cause the application to handle the event without and delays caused from any other higher priority contexts in your application.