Mares Quad with BLE Interface

[Dirk Hohndel]

> On Apr 10, 2018, at 9:19 AM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> The BLE case has no chance in hell of working right now -
> libdivecomputer doesn't even have any support for it, and we've never
> seen a BLE trace. So getting BLE working would require somebody to
> first get a successful trace from the Mares app, and then likely a
> whole lot of work to figure out the protocol. It *might* be one of
> those easy cases ("very usual BLE serial emulation, same protocol as
> the old serial protocol") but it might be a big job. But even the
> "easy case" tends to be pretty nasty with BLE.

Dropping the user forum for the moment and switching this to the developer
mailing list...

What's our best bet to create a process to do this?
Ask people to send their dive computers to Linus? Tempting, but maybe
not as scalable as one might hope.
Asking Linus to buy every dive computer out there? Clearly you're working
towards that already, but also not all that scalable.
Instructions how to create a BLE trace (I guess on Android?)?
Other ideas?

Pretty much every major dive computer manufacturer has announced at
least one new BLE dive computer (they all want to have their own custom
iPhone app... go figure). So we'll see a lot more of these pop up - and it's
disappointing to think that we can't figure out how to get more BLE dive
computers supported...

Jef has gotten quite good at getting to the bottom of serial/USB connection
traces, maybe we can learn from that?

/D

[Linus Torvalds]

On Tue, Apr 10, 2018 at 9:26 AM, Dirk Hohndel <***@hohndel.org> wrote:
>
> What's our best bet to create a process to do this?
> Ask people to send their dive computers to Linus? Tempting, but maybe
> not as scalable as one might hope.

Yeah. Especially since I wouldn't be very motivated by most dive
computers. I've not been all that excited about the Mares ones I've
seen: the Icon HD is ok, but I had issues with the screen.

> Instructions how to create a BLE trace (I guess on Android?)?

Yeah, but we know how easy _that_ can be, particularly since Android 8
(or something) apparently broke the documented ways by hiding the
trace. So you can get a trace, but _accessing_ that trace is
apparently impossible now.

(Or maybe google fixed it? I haven't tried).

But yes, at a minimum we'd need a BLE trace of a successful download,
and the BLE GATT descriptor listing (getting *that* is a pain too, the
best approach seems to be "use Nordic's nRF connect, and then expand
all the descriptors, and take screen shots", which isn't very
user-friendly either.

So both of those are somewhat painful for your average user that
doesn't really know anything about BLE.

We were very lucky with Berthold and the Aladin Sport. He did his own
fake GATT server and tricked the LogTrak mobile app to talk to his
desktop and got some traces that way. With *that* kind of expertise
on the user side, supporting the result was pretty easy. He did all of
the heavy lifting himself.

Linus

[Dirk Hohndel]

> On Apr 10, 2018, at 9:44 AM, Linus Torvalds <***@linux-foundation.org> wrote:
>
> On Tue, Apr 10, 2018 at 9:26 AM, Dirk Hohndel <***@hohndel.org> wrote:
>>
>> What's our best bet to create a process to do this?
>> Ask people to send their dive computers to Linus? Tempting, but maybe
>> not as scalable as one might hope.
>
> Yeah. Especially since I wouldn't be very motivated by most dive
> computers. I've not been all that excited about the Mares ones I've
> seen: the Icon HD is ok, but I had issues with the screen.

This was intended as a joke...

>> Instructions how to create a BLE trace (I guess on Android?)?
>
> Yeah, but we know how easy _that_ can be, particularly since Android 8
> (or something) apparently broke the documented ways by hiding the
> trace. So you can get a trace, but _accessing_ that trace is
> apparently impossible now.
>
> (Or maybe google fixed it? I haven't tried).
>
> But yes, at a minimum we'd need a BLE trace of a successful download,
> and the BLE GATT descriptor listing (getting *that* is a pain too, the
> best approach seems to be "use Nordic's nRF connect, and then expand
> all the descriptors, and take screen shots", which isn't very
> user-friendly either.
>
> So both of those are somewhat painful for your average user that
> doesn't really know anything about BLE.
>
> We were very lucky with Berthold and the Aladin Sport. He did his own
> fake GATT server and tricked the LogTrak mobile app to talk to his
> desktop and got some traces that way. With *that* kind of expertise
> on the user side, supporting the result was pretty easy. He did all of
> the heavy lifting himself.

The question is, can any of this be well documented or even automated?
Berthold, any suggestions?

I remember the Android process being reasonably painful - even without
Google hiding the output file from you.

Some googling seems to come up with quite a few posts on how to do this:

https://learn.adafruit.com/reverse-engineering-a-bluetooth-low-energy-light-bulb/sniff-protocol

It seems that using this device really helps

https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF-Sniffer
https://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=50443

But that's $45 or so - not something that we can ask the casual diver to buy...

Hmmm... running out of easy ideas

/D

[Berthold Stoeger]

On Dienstag, 10. April 2018 22:10:23 CEST Dirk Hohndel wrote:

> The question is, can any of this be well documented or even automated?
> Berthold, any suggestions?

Well, ultimately my endeavours were not really successful, as I never managed
to get the app to respond to my messages. All I got was the initial handshake.
Moreover, I should have realized from the start that it's just a variant of
the G2. At least I learnt what BLE and DBUS are.

The easy part was dumping the structure of the BLE interface ("the
characteristics") using Qt/BlueZ. I suppose tools that do this exist,
otherwise I can quickly string something together.

The hard(er) part was setting up a server. Out of a number of options,
this BlueZ-based server: https://github.com/nettlep/gobbledegook was the most
successful. But it had some limitations: I couldn't set all the
characteristics (IIRC the vendor string). Also, to advertise as the Aladin
Sport, I had to set my hostname accordingly. :) At the time, this looked to me
like BlueZ limitations. But I didn't investigate further, once Linus realized
that it's simply a G2-variant.

In summary, cloning the structure of a dive computer and catching the initial
message of the mobile app can probably be automated rather easily with certain
limitations. If there is interest, I could try this based on a BlueZ backend
(i.e. no Windows). But note that I'll be travelling the next two weeks and
have reduced time and internet connectivity.

Berthold

[Dirk Hohndel]

> On Apr 10, 2018, at 2:40 PM, Berthold Stoeger <***@mail.tuwien.ac.at> wrote:
>
> The hard(er) part was setting up a server. Out of a number of options,
> this BlueZ-based server: https://github.com/nettlep/gobbledegook was the most
> successful. But it had some limitations: I couldn't set all the
> characteristics (IIRC the vendor string). Also, to advertise as the Aladin
> Sport, I had to set my hostname accordingly. :) At the time, this looked to me
> like BlueZ limitations. But I didn't investigate further, once Linus realized
> that it's simply a G2-variant.
>
> In summary, cloning the structure of a dive computer and catching the initial
> message of the mobile app can probably be automated rather easily with certain
> limitations. If there is interest, I could try this based on a BlueZ backend
> (i.e. no Windows). But note that I'll be travelling the next two weeks and
> have reduced time and internet connectivity.

That does sound reasonably hard to do in a generic way. And I'm guessing that
people are more likely to have an Android device than a Linux laptop with BLE
stack.

So maybe the better approach would be to figure out how to write a step by
step description how to get the characteristics with nRF Connect on Android.
And then figure out if we can use that information to get further in figuring out
the handshake with the dive computer. It's that part that I'm unclear about.

I'll play with this a bit in my infinite spare time...

/D

[Jef Driesen]

On 2018-04-10 18:44, Linus Torvalds wrote:
> On Tue, Apr 10, 2018 at 9:26 AM, Dirk Hohndel <***@hohndel.org> wrote:
>> What's our best bet to create a process to do this?
>> Ask people to send their dive computers to Linus? Tempting, but maybe
>> not as scalable as one might hope.
>
> Yeah. Especially since I wouldn't be very motivated by most dive
> computers. I've not been all that excited about the Mares ones I've
> seen: the Icon HD is ok, but I had issues with the screen.

In this case, the easiest option is probably to contact Mares, and ask
them for the info we need. They have supported us in the past, and I
assume that hasn't changed.

I'll send them an email.

Jef

[Allen Hall]

I believe these are the characteristics for the Mares BLE Adapter.


Server: 544e326b-5b72-c6b0-1c46-41c1bc448118

Write: 99a91ebd-b21f-1689-bb43-681f1f55e966

Notify: 1d1aae28-d2a8-91a1-1242-9d2973fbe571


I think logs of the BLE communications might be stored on the iPhone... I will do some digging, but it may be a bit. Let me know if there's anything else you need.


Sorry for responding to the wrong message -- I didn't subscribe to the list until some responses had already been posted.

[Linus Torvalds]

On Thu, Apr 12, 2018 at 10:52 AM, Allen Hall <***@hotmail.com> wrote:
> BLE communications log is attached. I may be able to tease out more verbose
> info if needed, but this looks pretty complete to me.

This looks like it does contain all the information. I won't have time
to look at it until next week, but maybe Jef will.

The one question I have, is what the iOS encoding is for the data. The
logs show the actual data transfers as strings like this:

"value":"BQAAAAAdAGgfAwBIAAAAAAAAAO8="

and I'm *guessing* that is just a base64 encoding, but it would be
good to validate in case somebody knows the iphone logging model..

If it's base64-encoded, then it decodes to 20 bytes :

0000000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
0000020 00 00 00 ef

and this all should be possible to figure out.

In fact, I wrote a really stupid script to turn that into something
slightly more legible:

zcat < mares_bluelink_pro_ble.log.gz |
grep '"value"' |
sed 's/^.*{/{/' |
while IFS=, read a b c d e f g h
do
val=$(echo "$d" | sed 's/"value"://' | tr -d '"')
echo "$c $e:"
echo $val | base64 -d | od -t x1
done | less -S

and it superficially looks like it's the standard Mares Icon HD
protocol to me. I see one-byte 'aa' responses (which is just the ACK
character). And I see sequences like this:

"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" "status":"written":
0000000 e7 42
0000002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 aa
0000001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" "status":"written":
0000000 78 ad 00 00 04 00 00 00
0000010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 78 13 00 00 ea
0000005
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" "status":"written":
0000000 e7 42
0000002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 aa
0000001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" "status":"written":
0000000 1c ad 00 00 5c 00 00 00
0000010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 f0 00 a3 01 79 00 02 00 14 00 0e 00 00 00 74 00
0000020 40 95 00 00
0000024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 1e 00 78 05 20 80 78 05 32 80 78
0000013
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
0000020 00 00 00 ef
0000024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef
0000020 18 ef 18 f7
0000024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 00 0d 01 cc 00 fa 00 00 00 00 00 00 00 00 00 00
0000020 00 00 00 00
0000024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
0000000 00 ea
0000002

where that "e7 42" is "device read", it gets "aa" back, then we send
eight bytes of data (address and length, little-endian 4-byte each),
then we get the data followed by "ea".

(The "status":"written" is the phone sending, the
"status":"subscribedResult" is the dive computer answering).

That all looks exactly like the Icon HD serial protocol.

Jef, any additional comments?

Anyway, I suspect it all might just automatically work if we just add
the Mares to the list of bluetooth targets. The BLE GATT layout looks
like the normal "hacky serial over GATT" and might even match what we
already try to do.

But I can't test myself without the hardware, so somebody would need
to do some hacked-up test binary. Next week I might have more time.

Linus

[Linus Torvalds]

On Thu, Apr 12, 2018 at 11:57 AM, Linus Torvalds
<***@linux-foundation.org> wrote:
>
> That all looks exactly like the Icon HD serial protocol.

Oh, I didn't realize, this, but the dive computer itself doesn't do
bluetooth, the whole "Bluelink Pro" is just the dongle that replaces
the cable, and does bluetooth.

So yes, it's almost certainly just the exact same serial protocol,
just encapsulated over BLE GATT.

Dirk - you had a Mares Puck, didn't you? Was it the "Puck Pro"?
Because then we could test this by just buying that "Bluelink Pro"
thing which seems to sell for $49.95.

Then we could test the thing.

Linus

[Dirk Hohndel]

I have a dead Puck.
But maybe we can find a Puck Pro somewhere. Let's see.

/D

On April 12, 2018 12:15:23 PM PDT, Linus Torvalds <***@linux-foundation.org> wrote:
>On Thu, Apr 12, 2018 at 11:57 AM, Linus Torvalds
><***@linux-foundation.org> wrote:
>>
>> That all looks exactly like the Icon HD serial protocol.
>
>Oh, I didn't realize, this, but the dive computer itself doesn't do
>bluetooth, the whole "Bluelink Pro" is just the dongle that replaces
>the cable, and does bluetooth.
>
>So yes, it's almost certainly just the exact same serial protocol,
>just encapsulated over BLE GATT.
>
>Dirk - you had a Mares Puck, didn't you? Was it the "Puck Pro"?
>Because then we could test this by just buying that "Bluelink Pro"
>thing which seems to sell for $49.95.
>
>Then we could test the thing.
>
> Linus
>_______________________________________________
>subsurface mailing list
>***@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

--
from my phone.

[Courtney Hall]

I’m happy to do any testing if someone sends me a patch. I can build on MacOS.

> On Apr 13, 2018, at 01:08, Dirk Hohndel <***@hohndel.org> wrote:
>
> I have a dead Puck.
> But maybe we can find a Puck Pro somewhere. Let's see.
>
> /D
>
>> On April 12, 2018 12:15:23 PM PDT, Linus Torvalds <***@linux-foundation.org> wrote:
>> On Thu, Apr 12, 2018 at 11:57 AM, Linus Torvalds
>> <***@linux-foundation.org> wrote:
>>>
>>> That all looks exactly like the Icon HD serial protocol.
>>
>> Oh, I didn't realize, this, but the dive computer itself doesn't do
>> bluetooth, the whole "Bluelink Pro" is just the dongle that replaces
>> the cable, and does bluetooth.
>>
>> So yes, it's almost certainly just the exact same serial protocol,
>> just encapsulated over BLE GATT.
>>
>> Dirk - you had a Mares Puck, didn't you? Was it the "Puck Pro"?
>> Because then we could test this by just buying that "Bluelink Pro"
>> thing which seems to sell for $49.95.
>>
>> Then we could test the thing.
>>
>> Linus
>> _______________________________________________
>> subsurface mailing list
>> ***@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
> --
> from my phone.
> _______________________________________________
> subsurface mailing list
> ***@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[Jef Driesen]

On 2018-04-12 20:57, Linus Torvalds wrote:
> On Thu, Apr 12, 2018 at 10:52 AM, Allen Hall <***@hotmail.com>
> wrote:
>> BLE communications log is attached. I may be able to tease out more
>> verbose
>> info if needed, but this looks pretty complete to me.
>
> This looks like it does contain all the information. I won't have time
> to look at it until next week, but maybe Jef will.
>
> The one question I have, is what the iOS encoding is for the data. The
> logs show the actual data transfers as strings like this:
>
> "value":"BQAAAAAdAGgfAwBIAAAAAAAAAO8="
>
> and I'm *guessing* that is just a base64 encoding, but it would be
> good to validate in case somebody knows the iphone logging model..
>
> If it's base64-encoded, then it decodes to 20 bytes :
>
> 0000000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
> 0000020 00 00 00 ef
>
> and this all should be possible to figure out.
>
> In fact, I wrote a really stupid script to turn that into something
> slightly more legible:
>
> zcat < mares_bluelink_pro_ble.log.gz |
> grep '"value"' |
> sed 's/^.*{/{/' |
> while IFS=, read a b c d e f g h
> do
> val=$(echo "$d" | sed 's/"value"://' | tr -d '"')
> echo "$c $e:"
> echo $val | base64 -d | od -t x1
> done | less -S
>
> and it superficially looks like it's the standard Mares Icon HD
> protocol to me. I see one-byte 'aa' responses (which is just the ACK
> character). And I see sequences like this:
>
> "characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966"
> "status":"written":
> 0000000 e7 42
> 0000002
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 aa
> 0000001
> "characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966"
> "status":"written":
> 0000000 78 ad 00 00 04 00 00 00
> 0000010
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 78 13 00 00 ea
> 0000005
> "characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966"
> "status":"written":
> 0000000 e7 42
> 0000002
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 aa
> 0000001
> "characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966"
> "status":"written":
> 0000000 1c ad 00 00 5c 00 00 00
> 0000010
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 f0 00 a3 01 79 00 02 00 14 00 0e 00 00 00 74 00
> 0000020 40 95 00 00
> 0000024
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 1e 00 78 05 20 80 78 05 32 80 78
> 0000013
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
> 0000020 00 00 00 ef
> 0000024
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef
> 0000020 18 ef 18 f7
> 0000024
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 00 0d 01 cc 00 fa 00 00 00 00 00 00 00 00 00 00
> 0000020 00 00 00 00
> 0000024
> "characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
> "status":"subscribedResult":
> 0000000 00 ea
> 0000002
>
> where that "e7 42" is "device read", it gets "aa" back, then we send
> eight bytes of data (address and length, little-endian 4-byte each),
> then we get the data followed by "ea".
>
> (The "status":"written" is the phone sending, the
> "status":"subscribedResult" is the dive computer answering).
>
> That all looks exactly like the Icon HD serial protocol.
>
> Jef, any additional comments?
>
> Anyway, I suspect it all might just automatically work if we just add
> the Mares to the list of bluetooth targets. The BLE GATT layout looks
> like the normal "hacky serial over GATT" and might even match what we
> already try to do.

I haven't looked at the logfile in detail, but based on your description
it looks indeed like the standard iconhd protocol. That's also what I
expected: same protocol but send over BLE instead of usb-serial.

The base64 encoding is probably done by the iOS logger. I see absolutely
no reason to use base64 encoding over ble. It's perfectly possible to
send binary data over ble, and the large base64 overhead (about 33%)
would only make the relative slow ble even slower.

Jef