Queued Writes intentions and clarifications?

[SRA]

Can I get some clarification on what Queued Writes is and is not? This is just another one of the hilariously under documented features that could be summed up immediately if instead of just posting code - someone thought to write a few sentences on “How we intended this feature would be used”.

My sincerest plea for Nordic is someone write “how we intended this to be used” notes on SDK15 and beyond. A questionably readable example is not a replacement. 

* It seems Queued Writes use a BLE feature of “prepared write” and “execute write”. Is this something from the BLE spec? Because when using a generic app as the master/client, it still seems to work in the example.

* I assume that under the hood this is made possible with some gap/l2cap fragmenting using offsets. Does that mean that data no larger than 512 bytes can be written which iirc is the absolute maximum size of a GATT characteristic? If not is there an upper size?

* Does each packet get a response? If so, can multiple packets be put in a single connection interval? Does the bandwidth slow to a crawl with 1 packet per interval with queued writes?

* It seems to me the overhead is ~6B per 18 data bytes. At 250 data, you need about a 340 buffer to store this. This seems to be a reason I don’t often see queued writes used - despite the most frequent topic of BLE being “how do i transfer more data”. Is there something I may be missing here?

Thanks

[bjorn-spockeli]

Hi SRA, 

First, I apologize for the late reply.

Your feedback has been noted and I will suggest that the documentation is expanded upon and/or a blog post is written on the topic. 

Q1: Yes, Prepare Write Request/Response and Execute Write Request/Response is defined by the Bluetooth Specification, see BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part F,  Section 3.4.6 Queued Writes. 

Q2: Yes, the maximum size of an attribute is limited to 512 bytes, hence this is also the limit for queued writes. 

Q3: Yes, each Prepare Write Request must be replied to by calling sd_ble_gatts_rw_authorize_reply ( SD will then reply with ATT Prepare Write Response), see GATTS Queued Writes: App handled, no attributes require authorization or the other Queued Writes Message Sequence Charts found here. So yes,  you'll only see one packet per connection interval when using Queued Writes. 

Q4: You are correct that the Queued Write operation is not widely used. I think that the overhead is 4 bytes (Attribute handle 2 bytes + Attribute Offset 2 bytes) per 18 byte data. I would rather  the low throughput compared to write commands is the reason for its little use. 

Best regards

Bjørn 

[awneil]

SRA said:

My sincerest plea for Nordic is someone write “how we intended this to be used” notes on SDK15 and beyond. A questionably readable example is not a replacement. 

I heartily agree!

To be fair, it's not just Nordic - this seems to be endemic in manufacturer-provided libraries & SDKs. [1]

It's not helped by the over-reliance on Doxygen-generated documentation, which will naturally produce very "close-in" documentation of individual functions/types/variables etc - but all too often lacks the overview, context and intention of the system or module as a whole.

The examples don't help in this, as they provide  no explanation of the structure, or process of creating the application - they are purely presented as a done & dusted fait accompli.

The "description" is little more than. "press that button and see this happen"

For example: https://devzone.nordicsemi.com/f/nordic-q-a/60875/multi-link-peripheral---what-is-really-needed - which is what prompted the wakeup of this old thread.

Sorry - rant over.

EDIT

[1] To illustrate "seems to be endemic in manufacturer-provided libraries & SDKs", see:

https://www.avrfreaks.net/comment/2200431#comment-2200431

and the reply there.