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
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.
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
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
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.
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?
Hi Brian,
SentinelLighting said:HOW MANY ENTRIES CAN IT QUEUE?
It depends on the value of BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT.
The number of Handle Value Notifications that can be queued is configured by ble_gatts_conn_cfg_t::hvn_tx_queue_size When the queue is full, the function call will return NRF_ERROR_RESOURCES. A BLE_GATTS_EVT_HVN_TX_COMPLETE event will be issued as soon as the transmission of the notification is complete.
You might want to increase the size of the queue. As Runar indicated in how to set the queue size of notification, You don't need to change BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT or use sd_ble_cfg_set. The hvn_tx_queue_size will be indirectly configured based on NRF_SDH_BLE_GAP_DATA_LENGTH and NRF_SDH_BLE_GAP_EVENT_LENGTH values. You could increase the event length to 75 ms. This will increase the achievable throughput for the link.
-Amanda H.
