About NRF52833 transmission delay

[Lianghaisen]

Take Bluetooth UART as an example, there will be a delay in the process of sending data from the peripheral device to the central device to receive the data.

What factors will affect this delay? In theory, what is the minimum delay?

We want the central device to receive the data quickly. Programmatically, how to minimize this delay? Do you have any test data on this?

搜索

复制

[Edvin]

Hello,

What factors will affect this delay?

This is decided by something called the "Connection Interval". In a BLE connection, this is the interval at which the two devices will communicate. When they are done sending the packets that are queued up (or empty packets if nothing is queued up), then they will both go to sleep, and wake up when the next connection interval has passed. 

The minium connection interval is 7.5ms, since this is the minium allowed connection interval from the Bluetooth Specification. Note that it is the central device that has the final saying when negotiating the connection interval, so if the central device is not controlled by you (e.g. if it is a mobile phone), you may not get the minium connection interval. But if you control both the central and the peripheral (for example if both are nRF devices), then you can get the minimum connection interval of 7.5ms. 

Programmatically, this depends on what SDK you are using. Have you started development? Are you using the "old" nRF5 SDK or the nRF Connect SDK (NCS)? Whether it is one or the other, you should be able to figure out how to set it by searching here on DevZone, but let me know what SDK you are using if you can't find it, and I will help you out.

Best regards,

Edvin

[Lianghaisen]

Our company is engaged in medical equipment, and the SDK we use is nRF5 SDK 17.1. For NCS, we haven't adapted yet. We are already developing the product. Our customers require a transmission delay of less than 40ms.

The reference codes we use are examples\ble_peripheral\ble_app_uart and examples\ble_central\ble_app_uart_c.

We tested 20 times, and the average transmission delay was 43.22ms. In the test, we only send one byte to test.

I have a question, why is the transmission delay different every time, the minimum transmission delay is 2ms, the maximum transmission delay is 105.2ms.

搜索

复制

[Edvin]

Hello,

What HW are you running your tests on? Are you using 2x nRF52833 DKs from Nordic? Or custom hardware?

Bluetooth Low Energy has retransmissions until the packets are acknowledged. So if a packet is lost on air, it will be retransmitted until it is ACKed. This can go through on the first attempt, but if it is not ACKed then, it will be retransmitted in the next connection interval. 

A transmission delay of 2ms is based on luck. I guess you measure the time it takes from you queue up the packet until it is received on the other side. If you queue it right before the connection event (the event that occurs every connection interval), then it may be sent directly after, and received by the receiver. But in general, it may take up to one connection interval for the packet to be aired (if you queue it directly after, or too short before the previous connection event). 

If you need it to be less than 40ms and you are using 2x nRF devices, you should set the connection interval to 7.5ms. 

In the peripheral application, this is set by setting MIN_CONN_INTERVAL and MAX_CONN_INTERVAL (both close to the top of main.c) to:

MSEC_TO_UNITS(7.5, UNIT_1_25_MS)

On the central side, you need to make sure it accepts 7.5 ms as a connection interval. In SDK17.1.0, the central applications typically set this in sdk_config.h. Make sure that the connection interval you want to use is between

NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL
and
NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL

(so basically, set the NRRF_BLE_SCAN_MIN_CONNECTION_INTERVAL to 7.5, so that it will accept the peripheral's request of 7.5ms).

Best regards,

Edvin

[Lianghaisen]

The results of the custom hardware and development board measurements were similar. Thank you very much!

搜索

复制

[Edvin]

Did you try turning down the connection interval to see if you get most packets through before 40ms passes?

BR,

Edvin