How to reduce the response time of read requests

[Ryan Huang]

Hi,

I am working on the heart_rate_collector example code of nrf51-ble-driver_linux_0.5.0. I try to modify the example code let it can connect the Environmental Sensing Service (ESS profile) peripheral.

The ESS peripheral have temperature(Assigned Number: 0x2A6E) and humidity(Assigned Number: 0x2A6F) characteristic. Both of characteristic all support notify property.

When I connect the ESS peripheral and use the "sd_ble_gattc_read" to read its characteristic(such characteristic uuid: 0x2A29). Time between read request and read response is short.

But, when the notify function of temperature and humidity characteristic is be enabled, I also use "sd_ble_gattc_read" to read characteristic uuid: 0x2A29. Time between read request and read response is become very long.

I capture this sniffer packet sniffer.pcapng

And then, I use my android smart phone and install "nRF Connect for Mobile" APP to connect the ESS peripheral. Time between read request and read response is always short. (even the notify function of temperature and humidity characteristic is be enabled)

Does anyone have any way to reduce the response time of read requests?

[Hung Bui]

@Ryan: Do you have authorization set for the characteristic ? If you don't send notification packets does the response still take a lot of time to come ?

[Hung Bui]

Update: I missed the part you said that it was faster if no notification enabled. What happened was that the S130 only allow one packet per connection event, and if you already queued 8 notification packets, the read response will have to wait for these 8 packets to be transmitted before it can transmit. Since the S130 only allow one packet per connection event, it take 7 events to transmit all of them.

In your case with Android phone, there are more packet per connection interval allowed, so you can see the response come sooner.

The solution for it is to not to queue too many notification so that the read response can be sent earlier. Or you can temporary change the connection interval so the read response will arrive faster (but this will consume more power).

Another option is to use newer S130 version, but the official version of ble driver is not released yet. You can have a look here for the latest driver that use S130 v2.0.

[Ryan Huang]

Hi Hung Bui,

Thanks for your reply!

1. The solution for it is to not to queue too many notification so that the read response can be sent earlier. How can I implement this solution on ble driver or its application?

2. you can temporary change the connection interval so the read response will arrive faster. Your mean when the central send read request, central use the "sd_ble_gap_conn_param_update" function set new connection interval again. Is right? But the peripheral will send the BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST event again, so then central need respond this event again. This event will always occur in cycles.

3. When will you release a new S130 version for this ble driver? The release will important for me when we develop our platform.

Thanks

[Hung Bui]

Hi Ryan,

1. You can use a timer instead of queuing when you have data, so you only send notification (cal hvx function) every 1 second for example.

2. Yes, this only applies if you plan to have shorter connection interval for the whole operation. It may not be effective if you only switch to short interval for the read request and then switch back again. (But still it will be shorter than the 7 seconds latency as the connection param request will be sent without waiting for the queue of notification to be finished).

3. The one on github is the latest one and can be used. I don't think we will release new official ble_driver_pc soon.

[Ryan Huang]

Hi Hung Bui,

Thanks for your reply!

Which one will queue notification packets, peripheral or central? According to your first answer, the peripheral have used a timer to get a data, and then call sd_ble_gatts_hvx function to send notification with this data.

Thanks