This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Peripheral UART example - GAP_EVENT_LENGTH and throughput

This is related to another post seen here:

devzone.nordicsemi.com/.../

Basically, I took the peripheral UART example and modified it so all UART printing was disabled. Upon receipt of BLE data in the nus event handler, I simply call ble_nus_string_send() 6 consecutive times to send 6 packets of 20 byte data and monitor the data times on a nrf51 dongle sniffer. The connection interval was set to 20ms.

I notice that if GAP_EVENT_LENGTH is set to 3 (default in the example), packets take 20ms to transmit. If GAP_EVENT_LENGTH is set to 16 (20/1.25) then 6 packets take 20ms to transmit, which is what I expected given that you are able to transmit 6 packets of 20 byte data within a connection interval.

Can someone explain what is going on and what GAP_EVENT_LENGTH does and how it effects throughput?

Parents
  • The GAP_EVENT_LENGTH desides how much time you can use per connection event (unless you enable connectio event length extension in the option api). 3 limits both the time and the number of tx buffers. If you increase this, the connection event can last longer, and you get more tx buffers. However to utilize this to send data fast you need to check the BLE_GATTS_EVT_HVN_TX_COMPLETE. Set a flag to tell the application to send more packets. Then have a function in main context that fills the buffers. As long as you are able to fill the TX buffers you can send packets continuosly until the next connection event (by either matching the gap event lengtht to the connection interval or using the conn event length extension option).

  • As long as you can afford to have 7 tx buffers I guess ou are fine. If you don't you could probably set the gap event length to e.g. 3. and use the connection event lengt extension option in the optino api.

Reply Children
No Data
Related