Mares Quad with BLE Interface

[Linus Torvalds]

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