RE: Designing BLE Characteristic Layout

Beakerton — Wed, 20 Sep 2017 12:32:39 GMT

Thanks, endnode and Emil!

Emil -- Reading your link, it seems like the race condition is specifically trying to write at the same time that data is coming in. If I were to use a single characteristic for both reading and writing as endnode suggested, I would try to prevent that by having designated "ACK" and "End of Transfer" messages when multi-message transfers are used between the device and the host (essentially creating my own flow control).

As long as the host software followed the flow control implementation, it looks like I wouldn't see the race condition you indicate. For my project, having a bit of overhead time / messages aren't a big deal. The sync via BLE will only happen 1 per day and if it's a few seconds longer than it needs to be, it won't matter.

Thanks!

RE: Designing BLE Characteristic Layout

endnode — Tue, 19 Sep 2017 18:39:11 GMT

Well. Yes, you are trying to use BLE (G)ATT in the right way and it looks good. Just note that if you really care about the throughput and delays caused by connecting procedures you might consider to implement simple one GATT Service + Characteristic "tube" and do all that data flow and commands/response protocol on higher layer. It can still be as elegant (defining some OP codes for selecting which event data you want and then receiving them in another structure) but of course it adds few bytes of overhead. But because typical GATT client cannot work with multiple handles and methods in one connection event it might not have any real impact on throughput and you will save 50-1000ms during connection (faster GATT Service discovery = each Service or Characteristic can take up to 300ms if your phone stack is "dumb" enough).

To the reliability of lower layers and ack mechanism you can read some thoughts here and here.