Cannot write to more than one characteristic

RE: Cannot write to more than one characteristic

Kenneth — Tue, 01 Jun 2021 20:33:13 GMT

Work queue should work, but you can also check out handling of bt_gatt_write() here:

https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/software/posts/building-a-ble-application-on-ncs-sdk---contrasting-to-softdevice-based-ble-applications---part-2-central-role

(Edit: Fixed the link)

RE: Cannot write to more than one characteristic

Jonas Lien — Mon, 31 May 2021 07:44:18 GMT

Alright, so I didn't get any further trying to sequentially use bt_gatt_write, but it worked once I wrapped it into a work item and placed it on a work queue. Is this the preferred way to do it, or do you have other best practices for writing to multiple characteristics / multiple times to the same one.

RE: Cannot write to more than one characteristic

Kenneth — Thu, 27 May 2021 20:09:57 GMT

Both write request and write commands are acknowledged and retransmissted on the link layer, the only difference is really that write request also require an acknowledgement from the application on the peer. I have not see any lost packets from either really.

It should be possible to write to a different characteristic while waiting yes.

RE: Cannot write to more than one characteristic

Jonas Lien — Thu, 27 May 2021 15:21:30 GMT

To add onto previous statement: if bt_gatt_write_without_response() is the option for a command, then that is sadly not feasible for our application. However, it should be possible to write to more than only one characteristic once per connection while still getting write acknowledgements from bt_gatt_write, right?

RE: Cannot write to more than one characteristic

Jonas Lien — Thu, 27 May 2021 13:08:25 GMT

Thanks for your quick reply, Kenneth.

Do you mean that zephyrs bt_gatt_write is a write request and another function is a write command? Or have I misunderstood you?

Jonas

RE: Cannot write to more than one characteristic

Kenneth — Thu, 27 May 2021 12:23:54 GMT

You can try to use nRF Connect for Desktop as peer device (e.g. central here) while debugging. I suspect in this case that you are doing an write request, this needs to be handled in the peer before next write request can be executed. If you use write command instead then you avoid this.

Kenneth