Delay between characteristics changing and connected device getting notification of that change

[DiBosco]

Hi folks,

I have a system basically working with the following setup:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)      
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)       
#define SLAVE_LATENCY                   0      

I have a custom service with four characteristics that allow data to get from Nordic to PC (running Linux, not Windows or OSX) with handshaking in the following way:

PC Puts data in char1

Nordic gets new data and then:

Nordic writes value to char2 which tells the PC the Nordic has got the data and has enough space in its buffer for the PC to send more data. PC then pus updated version in char1 and so on...

The other two characteristics work for data being sent the other way.

Now, this works fine apart from the fact that there's a big old delay between data being put in a characteristic and the other end getting notification of that change. One problem is I don't know whether this is a delay between the Nordic picking up what the PC has changed or the PC picking up what the Nordic has changed.

I have put measurements at the PC end so I can tell that from a characteristic changed by the Nordic to tell the PC it is ready for more data it takes 140ms between updates. ie it is a round trip of 140ms, which is far too long!

Nordic writes to char2, PC updates char 1. Between the PC picking up that change in char2 and updating char1 there is less than a millisecond.

From the Nordic picking up the change in  char1 and putting a new value in char2 to twell the PC it can update char1 there is less than a millisecond.

So, there is either:

A delay in the soft device updating the characteristic after its API is called or:

A delay in the PC picking up the change in the characteristic or:

A delay in the PC from the application writing to the characteristic and it appearing "on air" or:

A delay in the soft device from picking up the change in char1 to sending it to my software running on the Nordic.

Or some combination of these. 

Are there any settings I have not tweaked that might be causing this? If so, what migt they be?

Can anyone think of anything I can do to track down exactly where the problem might be please? If I could toggle a pin on the PC when it picks up a change in char2 that might help I guess, but the days of parallel ports are long gone! ;)

Many thanks.

[tesc]

Hi,

I am really sorry for not having gotten any further with this issue for so long.

Do you see this throughput issue only from the computer that also had (potentially still has) the issues described in the thread with subject nrf52832 talks to a laptop running v4.2 BT, but not v5?

It looks like you never found the reason for that issue (other than it seemed to be with Qt), but to me it looks like a caching issue. E.g. you have previously connected to a device that had the same BLE address (most likely the same device with different firmware) and the GATT table has been cached on the pc side.

It may of course  be something else that is wrong, which also leads to slow throughput.

Note that we have to look at different levels of the BLE stack here. Characteristic size, ATT MTU size, and the Link Layer data PDU. When a characteristic is larger than the MTU size, reads and writes are segmented when reading and writing. If a packet of maximum MTU size is too big to fit in a LL data PDU, the packet is automatically segmented and sent using multiple LL packets. From the sniffer traces I see that (both for "fast transfer" and "small packet sizes") packets are fragmented in LL (e.g. PDU is small and MTU is large).

Based on the sniffer traces, it looks to me the difference may be the event length. Every connection event, packets goes back and forth between central and peripheral. Each device can stop the connection event by not transferring any more packets. This happens either when receiving an empty PDU and there is no more data to send (which means both devices have nothing to send, so no reason to continue the connection event), OR when the device decides to stop the connection events e.g. based on a locally decided timeout. From what I can tell, the last thing is what happens, i.e. on the PC side, the maximum number of packets to send each connection event is low, which means more connection events are needed to transfer the data.

Fixing the issue may involve either increasing number of packets per connection event (on the pc side), or if both sides allow longer LL data PDUs, perform a data length update.

Regards,
Terje