Bluetooth LE protocols

[David Carron]

Hello

The McLean Extrême uses a dual mode bluetooth module which supports SPP under bluetooth classic, and a vendor specific "Microchip transparent UART service" serial protocol  under bluetooth LE.

https://microchipdeveloper.com/wireless:ble-mchp-transparent-uart-service

UART Service 49535343-FE7D-4AE5-8FA9-9FAFD205E455

UART TX Characteristic 49535343-1E4D-4BD9-BA61-23C647249616

UART RX Characteristic  49535343-8841-43F4-A8D4-ECBE34729BB3

Is this service supported by subsurface, and if not, where would be a good starting point for me to add support?

Thanks a lot

David

[Linus Torvalds]

It looks like the usual "do serial over GATT" that we already support
in subsurface.

I suspect it would "just work" if you add DC_TRANSPORT_BLE to the
McLean definition in libdivecomputer, and then subsurface will try to
use its heuristics for finding the GATT serial vendor-specific service
and if it follows the usual pattern it will all just work.

Of course, since these BLE GATT serial services aren't standardized
(I'll refrain from venting about the Bluetooth SIG), I can only say
"probably".

This also assumes that the actual protocol over that serial line is
exactly the same as the traditional rfcomm BT protocol. If you do any
kind of special BLE packetization stuff (looking at that "transparent
uart service" thing I doubt you do), then more surgery of
libdivecomputer itself would be needed.

And if it doesn't work with that modification, I'd need a
libdivecomputer logfile from a failed download, and possibly a
bluetooth packet trace. I've seen enough of these random BLE
implementations that I can _probably_ just debug it with that.

If there's anything more complex going on, you'd need to send me a
loaner dive computer, debugging BLE remotely - aside from the trivial
"oh, we're picking the wrong service because XYZ" issues - is a
nightmare.

Linus

[David Carron]

As you point out, since the Bluetooth SIG haven't formalised a specific serial emulation GATT for bluetooth LE, so unless somebody, somewhere in the code is specifically looking for the bespoke Microchip transparent UART service and characteristic IDs there's no real reason for it to work.

The computer firmware doesn't know at all which particular flavour of bluetooth which particular service is being used by the bluetooth chip to emulate a serial flow so assuming the data managed to get transferred the'll be in the exact same format in classic or LE.

I took a quick look at the subsurface code but I couldn't really find if the service and charactersitic selection and interpretation is implemented there or delegated to a lower-level library. If you could point me in the right general direction I could take a look through and implement the missing parts if required.

David.

[Linus Torvalds]

On Tue, Sep 8, 2020 at 10:24 AM David Carron <david.d...@gmail.com> wrote:
>
> As you point out, since the Bluetooth SIG haven't formalised a specific serial emulation GATT for bluetooth LE, so unless somebody, somewhere in the code is specifically looking for the bespoke Microchip transparent UART service and characteristic IDs there's no real reason for it to work.

See, we're pretty much the only project out there that actively tries
to be cross-platform and cross-manufacturer.

Which means that we don't do special BLE drivers for different devices.

We don't care about the service ID. We see "oh, this is a dive
computer that does BLE, let's just see what services it has and if
they might be a serial thing".

We have a couple of special service ID's that we particularly
recognize, but for most cases it actually works fine without them. In
fact, the only one we really do *special* things for is the
Heinrich-Weikamp one, because that one has some special flow control
stuff that nobody else does.

The other services we recognize is because some dive computers have
multiple services that all *migth* be serial lines. But that's
actually fairly unusual. Most of the time, it's "oh, only this service
has both a readable and a writable characteristic that can be a serial
service".

So I'm serious: the subsurface code probably "JustWorks(tm)".

> I took a quick look at the subsurface code but I couldn't really find if the service and charactersitic selection and interpretation is implemented there or delegated to a lower-level library. If you could point me in the right general direction I could take a look through and implement the missing parts if required.

The core code is in core/qt-ble.cpp

But note that the "uud_match[]" arrays (yes, I typoed uuid, and then
it got duplicated with cut-and-paste ;) are really just "Oh, we know
abotu these". You can add the service UUID's you have to them, but you
don't have to. It likely works without them - we made do without those
known services arrays for years.

Linus