More Bluetooth LE work

[Linus Torvalds]

On Mon, Jun 26, 2017 at 10:07 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>> Right now that third patch is a disgusting hack that can not be
>> committed, because it will break *other* LE dive computers (ie Suunto
>> EON Steel and Scubapro G2).
>
> That's... disappointing.

It's technically easy to fix, the only issue is how to carry the
information about the quirks around.

Some things would be most easily done by just passing more data from
libdivecomputer: it would be trivial to add a "this dive computer uses
random BLE addresses" flag, for example.

But that has its own downsides, particularly for something like the
Perdix that currently acts as if it's just talking to a serial line.

Having our own machinery to just recognize the name of the dive
computer at scan time, and set up our own quirk tables has some
advantages. That's basically what the "LE:" prefix did.

I suspect, for example, that I will need to do something similar for
the "use random address", for the simple reason that I can't even see
the BLE GATT descriptors before I need to know the random address
data. But I *can* see the name of the device at scan time, and just
react to "Petrel" or "Perdix", and say "ok, I need to connect to a
random address".

For other dive computers, we might need quirks that get triggered at a
later date when we actually see the GATT characteristics.

Because not all bluetooth devices necessarily show names at scanning,
although so far I think all the dive computers I've worked with do.

> Yeah - that definitely should depend on the model - is that accessible
> from this part of the code?

Currently no.

Can it be made accessible? Yes. The main question is how.

For example, the nice thing about just modifying the device name -
hacky as it was - is that it's already passed around everywhere,
including all the way through the serial code in libdivecomputer. And
the 'devaddr' is what the subsurface UI saves away for next time too,
so it not only gets generated at scanning, it's what we use next time
around when we do *not* scan for devices, and just connect to them.

So adding flags to the device name has a lot of advantages, but it's
good for one or two quirks. I think the "LE:" thing was fine (it
really _is_ part of the address, conceptually), and I think it would
be fine to add a similar prefix for the "target uses a random BLE
address to connect" quirk. That also really is about addressing the
device.

Some other quirks don't work that way - not only aren't they really
about addressing, they are about things that might not be visible at
the scan stage.  There might be quirks that depend on the GATT
characteristics layout, which is something we only see as we actually
connect to the device for downloading.


>> - this *also* allows people who currently happily use rfcomm to play
>> with the LE back-end. So if you have an older Perdix, and it currently
>> works with rfcomm, what you can do is to just hand-edit the bluetooth
>> address to have that "LE:" prefix, and that will force the new BLE
>> GATT path. It might be faster and lower energy. And it might not. It
>> might not work for you at all. It's a crapshoot.
>
> How / where does one edit that address - that gets detected during
> scanning, right? So that would have to be a flag / checkbox that just
> adds it to the address. Or am I missing something?

It does get detected during scanning, yes.

But if you don't scan for devices - you just use the previously
detected thing - you'll notice that you see the bluetooth address in
that address window.

And you can edit it there too.

That made no sense before my addtition, but it was ctually true even
before I added the whole "LE:" thing. You *could* - instead of
scanning - just enter the bluetooth address by hand.

> Who else has BLE dive computers? Linus, isn't the Aeris shaving mirror
> BLE?

Oh, I guess I should take a look at that one.

Shudder.

> So if everyone who has a BLE dive computer could use a BLE scanner
> (like the Nordic nRF Connect app on Android) to look at the services that
> the dive computer offers on its custom service class UUID and maybe
> even do a BLE trace of the vendor app talking to the dive computer, that
> might get us started towards broader support...

Yes, and you'd need both of those, along with some basic knowledge of
the protocol.

In all the three BLE dive computers I've worked on, I knew the basics
of the protocol from previous non-BLE details. So then I just had to
match up the packet traces and see how the protocol was munged over
BLE.

Getting a good BLE trace is easy on android when it works, but as I
found out the hard way, you can also screw it up.

It should work on most modern android phones, which is good. I don't
know how to do BT logs on iOS, Windows or MacOS, though.

The Nordic BLE scanner is good, but it has a few annoying "features".
The best way to get the information out is literally:

 - connect to the device

 - make sure to expand all the GATT characteristics

 - take two or three screenshots as you traverse down the full list of data.

 - share the screenshots.

Ridiculous, I know, but it gets the uuid's for the characteristics etc.

                 Linus