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.

[muhkuhns]

Thanks for this detailed answer! So there is really no way to "overwrite" the first package in the queue or something? Could I do this with indication?

All I want is to always send the latest possible package to the central. Package inbetween can be lost. (They arrive fine on every interval... just my start seems to be totaly corrupted and fills the buffer which causes the delay..)

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

[muhkuhns]

Following the realtime descriptions I learned, what I want is not any of them.

I only want to overwrite the first place in the send buffer, so that always the latest measurement is sent on the next connection interval. I. e. just the deletion of the buffer/queue. I don't care when or even if they arrive. I just don't want to start sending old information when there are already new one. I won't believe that this can't be done.

[Hung Bui]

@muhkhuns: You can try to keep track of the buffer, and only queue packet if the buffer is free. To be able to do that you can follow the instruction in the description of sd_ble_tx_buffer_count_get() function.

Once the packet is queued, there is no way from the application to discard it.

[muhkuhns]

For the time being I just put a if(tx_completed) before the masurement/send part and set the flag on TX completed evt. Thanks for the idea!