Scubapro Galileo 2 (G2)

[Linus Torvalds]

On Wed, Jun 21, 2017 at 5:49 PM, Linus Torvalds
<torvalds at 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