On Wed, Jun 21, 2017 at 5:49 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
Note: if we're lucky and the Bluetooth Low Energy (BLE) uses the same type of packetization as their USB HID implementation, then we just need to swap the I/O layer, and we're done.
From what I've seen, they are very similar at least for both the EON Steel and the Scubapro G2.
But there is one big difference: the packet sizes are different for BLE than from USB HID.
Ok, having gotten over (at least some) of the BLE GATT communication issues with QtConnectivity, I can actually confirm that the problems are worse than that.
The command structure seems fairly similar, but the packetization of the commands is completely different over USB HID and BLE GATT.
The USB HID protocol is a simple "split it up into 64-byte packets by having a 62-byte payload and two byte per packet size information".
The BLE GATT protocol, in turn, depends on GATT to do the packetization, so it acts more like a streaming protocol, but then it HDLC-encapsulates it (it looks like it uses a crc32 checksum, but I haven't verified that part yet, but it would seem to fit).
I'm not quite sure *why* it does that (I thought BLE already gave you a reliable stream), but whatever. It is what it is.
I _think_ it may be so that the GATT receiver code can tell when it hits the last packet, without having to understand the stream data itself (that would explain why the USB HID protocol also uses a redundant packet size byte).
So the take-away is that sadly the libdivecomputer code does very much need to know which protocol it's running over, and do different things over different protocols.
At the same time, because BLE itself is so complicated, libdivecomputer can't actually do the IO itself on its own.
Linus