Re: Mares Quad with BLE Interface

[Jef Driesen]

On 2018-04-12 20:57, Linus Torvalds wrote:
On Thu, Apr 12, 2018 at 10:52 AM, Allen Hall  
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":"BQAdAGgfAwBIAO8="

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 :

   000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
   020 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":

000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 78 ad 00 00 04 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 78 13 00 00 ea
005
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 1c ad 00 00 5c 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 f0 00 a3 01 79 00 02 00 14 00 0e 00 00 00 74 00
020 40 95 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 1e 00 78 05 20 80 78 05 32 80 78
013
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
020 00 00 00 ef
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef
020 18 ef 18 f7
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 0d 01 cc 00 fa 00 00 00 00 00 00 00 00 00 00
020 00 00 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 ea
002

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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[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  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 
>>  wrote:
>> On Thu, Apr 12, 2018 at 11:57 AM, Linus Torvalds
>>  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@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> -- 
> from my phone.
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[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 
 wrote:
>On Thu, Apr 12, 2018 at 11:57 AM, Linus Torvalds
> 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@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

-- 
from my phone.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[Linus Torvalds]

On Thu, Apr 12, 2018 at 11:57 AM, Linus Torvalds
 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@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[Linus Torvalds]

On Thu, Apr 12, 2018 at 10:52 AM, Allen Hall  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":"BQAdAGgfAwBIAO8="

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 :

   000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
   020 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":
000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" "status":"written":
000 78 ad 00 00 04 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 78 13 00 00 ea
005
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" "status":"written":
000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" "status":"written":
000 1c ad 00 00 5c 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 f0 00 a3 01 79 00 02 00 14 00 0e 00 00 00 74 00
020 40 95 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 1e 00 78 05 20 80 78 05 32 80 78
013
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
020 00 00 00 ef
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef
020 18 ef 18 f7
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 0d 01 cc 00 fa 00 00 00 00 00 00 00 00 00 00
020 00 00 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 ea
002

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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[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.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[Jef Driesen]

On 2018-04-10 18:44, Linus Torvalds wrote:

On Tue, Apr 10, 2018 at 9:26 AM, Dirk Hohndel  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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[Dirk Hohndel]

> On Apr 10, 2018, at 9:44 AM, Linus Torvalds  
> wrote:
> 
> On Tue, Apr 10, 2018 at 9:26 AM, Dirk Hohndel  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

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[Linus Torvalds]

On Tue, Apr 10, 2018 at 9:26 AM, Dirk Hohndel  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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Quad with BLE Interface

[Dirk Hohndel]

> On Apr 10, 2018, at 9:19 AM, Linus Torvalds  
> 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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface