【GATT Queue】How to Configure the stack FIFO

RE: 【GATT Queue】How to Configure the stack FIFO

xiaolongba — Tue, 23 Nov 2021 14:01:32 GMT

Hello vidar Bro,

sorry for the late response as I was on annual leave several days ago

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/339702#339702"]It sets the max. payload length for all packets. [/quote]

Got it. so my understanding above is correct?

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/339702#339702"]But what is the motivation for using the nrf queue module? [/quote]

no, I just want to know what is the difference between nrf queue module and write_cmd_tx_queue_size

RE: 【GATT Queue】How to Configure the stack FIFO

Vidar Berg — Thu, 18 Nov 2021 15:58:18 GMT

Hi,

It sets the max. payload length for all packets. But what is the motivation for using the nrf queue module? I forgot to mention earlier that there is a bug in the nrf queue module with the way it handles write commands, please see this thread details: https://devzone.nordicsemi.com/f/nordic-q-a/60557/bug-improvement-in-handling-nrf_error_resources-response-in-gatt-queue-nrf_ble_gq_req_gatts_hvx-processing

RE: 【GATT Queue】How to Configure the stack FIFO

xiaolongba — Thu, 18 Nov 2021 15:47:02 GMT

Hi Vidar Bro,

most of them are clear, but the following doubts is still exist:

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/339649#339649"]NRF_BLE_GQ_GATTC_WRITE_MAX_DATA_LEN is set the max. payload length for your write commands[/quote]

Does it mean that the payload length of all packets, or one packet?

also what is the relationship between NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT and NRF_BLE_GQ_DATAPOOL_ELEMENT_SIZE? could you give me an example? such as NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT=8,NRF_BLE_GQ_DATAPOOL_ELEMENT_SIZE=20. what does it mean? it means that the total payload length is 8*20 =160 bytes?

thanks in advance.

RE: 【GATT Queue】How to Configure the stack FIFO

Vidar Berg — Thu, 18 Nov 2021 13:09:50 GMT

Hi,

The time it takes to transmit and and receive the packet does not map 1:1 with the required event length because there's additional overhead such as post processing that need to be accounted for as well. We have not documented a formula which covers all scenarios (is not as easy as it may sound). Instead we have made the Softdevice notify the application when the event length is too short for a given packet length as you have seen.

[quote userid="21601" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/339476#339476"]got it, I still would like to know what is the difference between GATT queue and write_cmd_tx_queue_size ? could you help me clarify?[/quote]

It makes a bit more sense to use the BLE GATT Queue module when you're doing GATT procedures that can't run in parallel. For instance, write requests where you have to wait for the write response before the Softdevice allows you to queue up the next.

sd_ble_gattc_write() already lets you add 'write_cmd_tx_queue_size' number of write command packets to the Softdevice's output buffer, so you typically don't need to keep an additional buffer in the app, which basically is what GATT Queue provides.

If you want to use the queue module you need to make sure NRF_BLE_GQ_GATTC_WRITE_MAX_DATA_LEN is set the max. payload length for your write commands. NRF_BLE_GQ_DATAPOOL_ELEMENT_COUNT will determine the max. number of packets you can queue up.

RE: 【GATT Queue】How to Configure the stack FIFO

xiaolongba — Wed, 17 Nov 2021 15:06:37 GMT

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/339445#339445"]My suggestion was to increase the output buffer in the Softdevice rather than increasing the GATT queue module. The write_cmd_tx_queue_size specifies the number of packets (the Softdevice accounts for the max. packet here) you can place in the Softdevice queue.[/quote]

got it, I still would like to know what is the difference between GATT queue and write_cmd_tx_queue_size ? could you help me clarify?

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/339445#339445"]Please take a look at the "Suggested intervals and windows" section of the Softdevice specification.[/quote]

Actually, I looked into this section. but I still can not get the correct value. to explain more clear, let me give you an example, as below:

in my case, the NRF_SDH_BLE_GAP_DATA_LENGTH is 251bytes, while NRF_SDH_BLE_GAP_EVENT_LENGTH is 4.

based on this configuration, the softdevice told me the following error info:

The requested TX/RX packet length is too long by 16 octets

also, I checked Bluetooth spec, the LL data is (251+14)*8 = 2120 us if NRF_SDH_BLE_GAP_DATA_LENGTH is 251 octets and the 1M PHY, so the CE_Length_measured is (2120 + 2120+2*T_IFS) = 4540us, while the NRF_SDH_BLE_GAP_EVENT_LENGTH is 4, so the CE_LENGTH is 4*1.25ms = 5ms, it should cover 4540us, but the sd still reported me the error info, that is

The requested TX/RX packet length is too long by 16 octets

so I want to know how to get these 16 octets based on the configuration I mentioned above. could you give me a hand, It took me lots of time recently, so your great support is very useful for me.

thanks again, bro.

RE: 【GATT Queue】How to Configure the stack FIFO

Vidar Berg — Wed, 17 Nov 2021 13:35:03 GMT

[quote user="xiaolongba"]for queue size, is it only for write cmds cache, without payload? but as you know, each write cmd will carry some payload, such as 200 bytes. which parameters are used for these payload caches? I don't know if I explained clearly, in other words, there is one write cmd with 200bytes payload, and queue size can cover the cmd and payload together[/quote]

My suggestion was to increase the output buffer in the Softdevice rather than increasing the GATT queue module. The write_cmd_tx_queue_size specifies the number of packets (the Softdevice accounts for the max. packet here) you can place in the Softdevice queue.

[quote user="xiaolongba"]how to calculate it. could you share the formula for it?[/quote]

Please take a look at the "Suggested intervals and windows" section of the Softdevice specification.

RE: 【GATT Queue】How to Configure the stack FIFO

xiaolongba — Mon, 15 Nov 2021 08:55:44 GMT

Hello Victor Bro,

Based on the issue above, I would like to ask you another question about it. as you know, I tried to optimize the max throughput based on the solution above but found that the following warning has been triggered:

The requested TX/RX packet length is too long by 16 octets

in my case, the NRF_SDH_BLE_GAP_DATA_LENGTH is 251bytes, while NRF_SDH_BLE_GAP_EVENT_LENGTH is 4.

also I understood how to fix this warning, that is to increase the NRF_SDH_BLE_GAP_EVENT_LENGTH value from 4 to 5,

However, I would like to know where are 16 bytes coming from? how to calculate it. could you share the formula for it? I need your help, Bro.

thanks in advance.

RE: 【GATT Queue】How to Configure the stack FIFO

xiaolongba — Thu, 11 Nov 2021 13:57:11 GMT

Hello Bro,

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/338557#338557"]Are you sure you are performing GATTC Characteristic or Descriptor Value Reliable Write (aka write requests) and not GATTC Characteristic Value Write Without Response (aka write commands). Write requests will lead to a considerably lower throughput because you can't issue multiple write requests in parallel (the stack needs to wait for the write response to come back before issuing a new request). This effectively limits you to write per connection event. [/quote]

I used the write commands, sorry for the misunderstanding.

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/338557#338557"]

1. As mentioned above, it's not possible to send multiple write requests in one connection event.

[/quote]

I can get your point,

[quote userid="21601" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo"]I used the gatt queue lib for this case, the default queue length is 4, that means SD can hold 4 write requests. I assumed that the SD received 4 write requests before the next connection event is coming, so the SD can transmit these 4 write requests one by one when the connection event has come (CE length is enough). am I correct?[/quote]

but I used the write cmd. so for this situation, my understanding above if it is correct？

[quote userid="4240" url="~/f/nordic-q-a/81618/gatt-queue-how-to-configure-the-stack-fifo/338557#338557"]2. An easier way to deal with this, assuming you use write commands, is to increase the write_cmd_tx_queue_size (see this post). This defines the number of packets you can add to the Softdevice's write output buffer.[/quote]

I have checked this link, also I understood that it is used for high throughput when increasing the queue size, but what I was confused about is :

for queue size, is it only for write cmds cache, without payload? but as you know, each write cmd will carry some payload, such as 200 bytes. which parameters are used for these payload caches? I don't know if I explained clearly, in other words, there is one write cmd with 200bytes payload, and queue size can cover the cmd and payload together?

RE: 【GATT Queue】How to Configure the stack FIFO

Vidar Berg — Thu, 11 Nov 2021 12:13:49 GMT

Hello,

Are you sure you are performing GATTC Characteristic or Descriptor Value Reliable Write (aka write requests) and not GATTC Characteristic Value Write Without Response (aka write commands). Write requests will lead to a considerably lower throughput because you can't issue multiple write requests in parallel (the stack needs to wait for the write response to come back before issuing a new request). This effectively limits you to write per connection event.

1. As mentioned above, it's not possible to send multiple write requests in one connection event.

2. An easier way to deal with this, assuming you use write commands, is to increase the write_cmd_tx_queue_size (see this post). This defines the number of packets you can add to the Softdevice's write output buffer.

Best regards,

Vidar