• State Verified Answer
  • Replies 3 replies
  • Subscribers 62 subscribers
  • Views 1837 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 126124
Options
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

leonhart88

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?

  • 0

    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).

  • 0 in reply to run_ar

    Thanks for the answer. I'm currently just calling ble_nus_string_send() as fast as possible and if there is an error I call it again to ensure the correct amount of packets get transferred. I'm checking BLE_GATTS_EVT_HVN_TX_COMPLETE to make sure I get the correct number of packets sent out, but I'm not using it to reduce the unecessary ble_nus_string_send() calls at the moment (but I will probably change it to do as you suggest).

    So in terms of GAP_EVENT_LENGTH, is there any rule of thumb for how long it should be? My peripheral will only have one connection so I just set it to the connection interval, but are there any downsides of doing this?

  • 0 in reply to run_ar

    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.

Related