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

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