BLE download from EON Steel on Android

Linus Torvalds torvalds at linux-foundation.org
Sun Jun 25 10:28:13 PDT 2017


On Sun, Jun 25, 2017 at 2:59 AM, Jan Mulder <jlmulder at xs4all.nl> wrote:
>
> Obviously, I still can download from my OSTC3 (self build 283). But,
> checking the log, over BT and not BLE. I was unsure if the OSTC3 is BLE as
> well, so I checked with the Nordic Semiconductor tools . Yes, my OSTC3 is
> BLE and BT. So now the big question (did not check the code yet): how do I
> force/select BLE over BT? Just to test things :-)

So BLE is very different from legacy BT rfcomm, for two main reasons:

 (a) there is no standard serial mode for BLE at all.

 (b) Instead, there is a "somewhat common convention of using BLE GATT
to send and receive packets".

The lack of a true standard means that the BLE side in subsurface is -
pretty much by definition - something of a hack. Theer is no defined
right way to do things - you can't look up a "serial service", you can
only do things like "ok, ignore the standard services, look at the
vendor-specific service instead, and try to match it up with the
somewhat common convention.

It also means that each dive computer needs to be at least separately
checked - it's not like it will automatically work. The patterns I'm
triggering on right now may not be the right patterns for the next
dive computer. In fact, the Shearwater Perdix seems to have a rather
different pattern (with just one GATT service that can do both reads
and writes, rather than separate services for reads and writes),
although the way I wrote things it all *might* still work if I could
just connect to it).

But apart from the lack of standard, the other keyword here is "send
and receive packets" rather than "serial". It really is packetized,
although right now both of the dive computers I've successfully worked
with have basically turned the small packets into just a serial
stream.

So you can treat the packet model as a transport for serial, and I
suspect most people end up doing exactly that in practice. For the
Suunto EON Steel, for example, that means that the libdivecomputer
part actually acts fairly differently from the USB HID part - both are
fundamentally packetized protocols, but the USB HID side actually
treats them as packets, while the BLE GATT side essentially implements
a separate serialish protocol over the small BLE GATT packets.

But I *suspect* that dive computers like the OSTC and the Shearwater
ones - where the traditional model is a serial stream model - will
basically always treat the BLE GATT protocol as just a plain wrapper
for serial.

And I could add an explicit "emulate serial over BLE GATT" thing, but
if I do that, it will *replace* the rfcomm serial.

Right now, the way I did the BLE GATT packet interface, the
libdivecomputer code can basically continue to use the rfcomm code
unchanged - so a device like yours that does both BLE GATT _and_
legacy BT rfcomm will just continue to work with the rfcomm code, and
the new BLE GATT code never even gets triggered. That's very much by
design - I didn't want to break the old interfaces. But it does mean
that if you used to use rfcomm, you will _still_ use rfcomm.

I think I'll add a "force BLE" checkbutton or something, which will
say "instead of rfcomm over legacy BT, emulate serial over BLE GATT".
But it will have to be a new button, exactly so that by default things
don't break for dive computers where BLE doesn't work.

However, due to the lack of a real standard, I want to point out again
that it's very much hit and miss whether it will work. And BLE itself
is a problem: it really is more complex than legacy BT, and perhaps
more importantly, it has gotten much less testing (I'm hitting issues
with pretty much everything I've tested: first the EON Steel, then
some minor issues with the Scubapro G2, and now major issues with the
Shearwater Perdix).

                    Linus


More information about the subsurface mailing list