Strange Delay - Does sd_ble_gatts_hvx buffer?

[muhkuhns]

//Edit:

So Hung Bui just told me in another question, that there is indeed a buffer of size 6 or so? How can I decrease that to 1 (i.e. disable it) so that only the latest sd_ble_gatts_hvx is in queue?

Hello,

I am using a setup of 4 peripherals connected to one central (nRF51-DK) to collect measurements..

My code is based on the multilink example. It basically works fine but there is a strange delay of about 7times the connection interval.

The peripherals measure e.g. every second. Then notificate it to the central.

The central prints out all 4 measurements every second.

Connection Interval = Interval for Measurements = Interval for notification = Intervall for printf

If I force change the measurement value, it has ~5seconds delay before it appears on screen. The sensor is more than fast enough.

central - main.c

central - client_handling.c

peripherals - main.c

[Hung Bui]

@Muhkuhns: No you can't change the buffer size. You can monitor the number of packets being sent by checking the count number when in TX_COMPLETE event. However, it would be more simple if you use indication instead of notification. There will be only one indication can be queued at a time. And you can't send another infication before the first one finished.

However, BLE is not real time protocol but a reliable protocol, so a packet will be re-transmitted until it's received and acked by the peer device. So even in the case that you only send one notification/indication at a time you have no guarantee when will the peer device receive it.

I would suggest you to add a timestamp into the notification/indication packet. So that the master when receive the packet can find when the data is sampled regardless when it's actually received.

[Hung Bui]

@muhkuhns: You are talking about realtime requirement where packet can be discarded if it would not meet the time to arrive. This is not supported by Bluetooth 4.0 spec. Adding a timestamp (then you need to sync the devices) is the only solution I can think of.

If you don't want the first few packets you can try not to send them with the hvx command and wait until it's stable.