More Bluetooth LE work

[Dirk Hohndel]

> On Jun 27, 2017, at 12:48 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
> So attached are three patches that currently allow me to download
> dives from my Shearwater Perdix AI, and that I assume works with the
> regular Perdix too (which has some newer versions that are BLE-only
> and no longer support rfcomm).

I have a dual stack Petrel - in order to test we'd need that way to switch
between BT and BLE / at least for testing and debugging.

> HOWEVER. BIG CAVEAT!
> 
> 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.

> The issue is that the Shearwaters use a
> slightly different model for connecting and their BLE packet sending,
> and rather than do the sane thing and discover that dynamically, that
> third patch just hardcodes the Shearwater way.

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

> The two first patches are good to go, though, and you should consider
> the third patch a "hey, I want to test my Shearwater download" special
> patch that you do not actually commit, you just apply to your build
> tree for testing.

I didn't take my Petrel AI to Palo Alto (I know, how could I not?), so I won't
test that until Thursday.

> CAVEAT NUMBER TWO!
> 
> The Perdix AI has some new fields for actual air integration, and
> those new fields will presumably need libdivecomputer support, and I
> haven't got any test data for it. So while I have a Perdix AI download
> working fine, I'm not saying it's all perfect.

I have the info from Shearwater on how to parse them (I think I shared
that with you, Linus), and I have a Petrel AI with a dozen real air integrated
dives on it, so that, too, I can work on on Thursday.

> Anyway, with those caveats out of the way, some explanations:
> 
> - the same bluetooth device may support both legacy bluetooth
> (rfcomm) _and_ the BLE GATT model. That's true of the older Shearwater
> Perdix, for example, and our current custom_io model actually
> describes both modes at the same time, so that the libdivecomputer
> backend can just pick whichever it wants.

Neat.

> - in particular, I don't want to change the behavior of the old
> rfcomm code - I don't have anything that uses it, and it supposedly
> works fine for others, and it's a more standardized protocol than the
> BLE GATT hackery of more modern dive computers, so it should remain
> the default mode for those dive computers that support it.

Yes it should - but as I said earlier, it would be great to have a "prefer
BLE flag" for testing.

> - HOWEVER, when we scan for the dive computers, we can see that some
> dive computer _only_ supports BLE. When that happens, the first patch
> in this series will now explicitly mark the bluetooth address with a
> "LE:" prefix at scan time, which will allow the rfcomm code to realize
> that it cannot use rfcomm for the device.

Good - we could then use that to hack that flag that I mentioned earlier.
Easy enough.

> - the first patch then also makes the actual BLE packet code ignrioe
> the possible "LE:" prefix (but not having that prefix is ok too for
> the packet code, for the dual BT support case).  The rfcomm case will
> obviously fail with the "LE:" prefix, but it would have failed anyway
> since rfcomm doesn't work over LE.
> 
> - the second patch then hooks into the rfcomm code, and instead of
> just failing, it says "dammit, if I see that LE prefix, I know that I
> can't use rfcomm, but I'll instead do my own serial emulation over the
> packets I can send".
> 
> - this is what makes the Perdix AI "just work" without any extra
> effort (well, as long as we have the hack in place to do the packet
> accesses properly for the shearwater case) - the libdivecomputer
> backend will just use the same old serial code, never even realizing
> that now it goes over BLE.
> 
> - 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?

> - that third patch really is crap. Don't look at it. Don't commit it.
> I'm sorry. But you currently need it to make the BLE GATT code work
> with shearwater dive computers.

Got it.

> Anything I forgot?
> 
> People who have non-Shearwater dive computers that use rfcomm but
> might use BLE, you might *try* to apply the two first patches, and it
> might just work for you (and use the "LE:" trick to force LE mode).
> Maybe. Don't apply the third one, I suspect Shearwater is alone in how
> they do that odd "one single characteristic, two descriptors" thing
> (Suunto and Scubapro use two separate characteristics - one for
> reading ("notify") and one for writing).

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

> But tit's really worth noting once again the fact that BLE GATT really
> isn't standardized wrt exactly how to send packets and what they mean,
> meaning that there is really no reason to expect that things will
> "JustWork". I suspect each BLE dive computer will need some packet
> sniffing and some hackery. So far every single one I've worked on has
> been very different (in some ways: the ScubaPro G2 and Suunto EON
> Steel are similar in how the packets are being sent and received, but
> have different encodings). The Perdix AI has a very plain encoding,
> but instead uses a different approach to send and receive the packets.

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...

/D