A better way to handle the completion of a long write?

[Clem Taylor]

I have a 384 byte, writable, variable length, vloc user characteristic and I want to trigger an event when the write completes so my application can operate on the data.

Right now I get the BLE_GATTS_EVT_WRITE event, check for op == BLE_GATTS_OP_EXEC_WRITE_REQ_NOW, walk down the list of handles in the prepared write data, looking for my value handle. If I find the handle I get the length with sd_ble_gatts_value_get() and act on the data using the buffer I allocated for the characteristic value (it is vloc_user). There is also the case that the central has <=20 bytes to write, so you also have to check for handle in the op == BLE_GATTS_OP_WRITE_REQ case as well.

It seems like there should be an easier way to handle this condition. The softdevice has already processed the prepared write and the data is sitting in the buffer, I just need to know that the value handle has been written to.

Is there a more direct solution?

[Carles]

Hi there,

First of all thanks for your feedback, it's great to get suggestions for improvement from SoftDevice users.

The problem is that the SoftDevice doesn't have a special mechanism to deal with Write Long Values (Prepare Write + Execute Write on a single handle) when compared to Reliable Writes (Prepare Write + Execute Write on multiple handles). This is because we chose to approach the user awareness of changes based on incoming over the air packets, and not based on changes on particular characteristic values. There were several reasons for this: one is to allow some apps to restrict particular operations, and another to be able to implement a reliable and safe deferral model via authorisation. But for some applications this raises the question on whether it is actually useful to know which operation was used to modify the value, when all the user wants is to be informed that it has changed. A subscriber model could make sense, where the application simply gets a "value changed" event at the end.

We will take for feedback into account for future versions, but for now the only solution is the one you already describe in your post.

Also in the future long MTUs will make it possible to avoid the complicated Write Long procedures by simply sending larger packets in one go with all the data in them.

Thank you again, keep this feedback coming!

Carles

[Matt Sieren]

I agree. I just ran into a similar problem trying to develop a device for iOS/OSX MIDI protocol and cannot proceed as they rely on fragmentation / reassembly and larger MTUs for larger data packets.