BLE GATT Queue in server for Notifications

[RoccoBr]

Hello,

I'm trying to understand if I can use BLE GATT Queue in my peripheral for sending Notifications. All the example and documentation about BLE GATT Queue seem to be for central rather than peripherals  

my ultimate goal is to have a tx queue in SoftDevice as big as possible, I have already tried increasing NRF_SDH_BLE_GAP_EVENT_LENGTH and NRF_SDH_BLE_GATT_MAX_MTU_SIZE, but it doesn't seem to have the desired effect and it seems that changing directly ble_gatts_conn_cfg_t::hvn_tx_queue_size is not allowed/recommended

[Edvin]

Hello,

Yes, you may use the gatt queue to send notifications. But please note that this is not the intended use case for gatt queue. The Gatt queue is intended for use if you want to send multiple notifications on several characteristics at once. Say for example that you have a navigation system, and you want to update the direction on the next turn as well as the distance to the next turn after a turn has been executed. 

However, if you intend to stream a lot of data, I suggest you just queue up the packets using sd_ble_gatts_hvx(). As long as you keep this queue full, you will get the maximum throughput that your connection is set up to handle. 

The size of the softdevice queue is set up automatically, and increasing it will not have any effect. As long as you queue up all the packets that can fit (until it returns NRF_ERROR_RESOURCES), then you can wait for the BLE_GATTS_EVT_HVN_TX_COMPLETE event, which means that one or more of your queued packets have been successfully transmitted. Then you can fill up your queue with new packets. 

The queue length is set up to be long enough to not run out during one connection interval.

Best regards,

Edvin

[RoccoBr]

thanks Edvin.

If softdevice queue is set up automatically, can you please explains this Message chart, the second example, where the tx_queue_size is set EXPLICITLY : https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v7.3.0%2Fgroup___b_l_e___g_a_t_t_s___h_v_n___m_s_c.html

[Edvin]

Well, it is possible to configure it, but by default, it will set the queue size based on your connection event length and the characteristic values in your services. This is used in case you need your application to keep track of remaining queue elements, in case you have high priority and low priority data. 

The chart is a bit simplified. The queue doesn't exist of remaining packets, but remaining bytes. So if you queue a lot of small packets, you can queue more packets (although this will give you a lower payload throughput, because the "header to payload ratio" increases.

Perhaps you can tell me a bit more about what your application will do, and why you started reading about the queue size. Did you encounter any issues while developing?

(Just in case we are looking at an XY problem here)

BR,
Edvin

[RoccoBr]

our central and peripheral devices are mounted on a truck, the central is in a fix position, the peripheral is moving around roughly in circle, so we have an area where the connection is not that strong. we have increased the timeout interval to the maximum so devices don't disconnect, and we need to queue packets in the "gray area" so they are transmitted (possibly quickly) where connection is stronger. We are sending Notifications with 51 byte of payload every 50ms 

[Edvin]

I see. There is still no need to increase the softdevice queue size. It doesn't really matter where the queue is located. Just buffer up the data in your application, and push it through as fast as you can, until you are either out of data to send, or until it returns NRF_ERROR_RESOURCES. In that case, wait for the TX Complete event, and continue queuing data. 

BR,
Edvin