Can you do successive updates to a Notify Characteristic using sd_ble_gatts_hvs() during the same connection interval without losing data.

[SentinelLighting]

Can you do successive updates to a Notify Characteristic using sd_ble_gatts_hvs() during the same connection interval without losing data.

The question comes down to, does the Softdevice queue up multiple notify updates?

I am running S132 SoftDevice v6.1.0 as a peripheral

[SentinelLighting]

If it does queue, how many entries can it hold?

[Amanda Hsieh]

Hi Brian, 

does the Softdevice queue up multiple notify updates?

Yes, S132 SoftDevice v6.1.0 can support queue up multiple notify updates.

It is the central that is the link-layer master and decides the timing of each connection. The peripheral can request different connection parameters by issuing a connection parameter update request, but the central will always have the final say. 

The SoftDevice has a very robust scheduler to handle these conflicts to avoid link loss, but every time a conflict occurs one or two of the affected links will get its data delayed. 

You should start by setting the value for the requested connection interval. However, It really isn't easy to say what the optimal connection interval is when you're running multiple central connections. The different centrals (phones) do not have synchronized clocks and will drift in time continuously. This means the various links will go in and out of sync over time, and will occasionally conflict with each other. See the explanation in this post. 

 -Amanda H.

[SentinelLighting]

I am running a single central and a single peripheral.  How many calls to sd_ble_gatts_hvs() will be queued?  For example, if I define the characteristic as having a size of 132 bytes (audio data in this case), can I do five consecutive calls to sd_ble_gatts_hvs() and not lose data?  I understand that I would need to delay before doing another 5 writes.

Is there some document that explains how the softdevice is architected and how to use the softdevice relative to this issue?  I can find nothing in the Nordic documentation that talks about this

[Amanda Hsieh]

Hi Brian, 

Sorry to misunderstand your situation and thanks to clarify it. 

Do you get any error with five consecutive calls to sd_ble_gatts_hvx()?

I'm not sure why you lost date with five consecutive calls to sd_ble_gatts_hvs(). Maybe you can try to increase the connection interval by setting NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h to see if that helps. The Softdevice specification (Bluetooth Low Energy data throughput) includes some throughput numbers achievable with certain connection parameters to give an idea of what you can expect.

-Amanda H.

[SentinelLighting]

This should be a simple question to answer.  When sd_ble_gatts_hvx() is called, does the softdevice "save" or "queue" up the data internally until it can transmit the data?  If it does, how many consecutive calls can it save/queue before it errors/overflows?  For example if the data passed in sd_ble_gatts_hvx() is saved in a memory stack there must be a maximum number of entries that can be saved.  The worst case assumption would be that it can only save/queue up ONE entry, that would be the actual characteristic data.

The documentation seems to imply that the data for the characteristic is saved every sd_ble_gatts_hvx() call, and at some later point it is transmitted.  Your implication is that it saves/queues up each of these calls in some sort of transmission queue until it has a chance to transmit.  HOW MANY ENTRIES CAN IT QUEUE?