Mares Smart Dive Computer + Bluelink pro

Linus Torvalds torvalds at linux-foundation.org
Wed Sep 26 14:14:20 PDT 2018


On Wed, Sep 26, 2018 at 1:20 PM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> It then tried to do a 4-byte read at offset 12,  and *that* failed.
>  But the communication actually was successful: you
> can see how the dive computer returned AA to the command (that's
> "ACK") and then EA to the length/offset (that's EOF). It just didn't
> return the four bytes we actually asked for.

Looking at the original bluetooth capture file from the Mares App, it
uses the very same E742 command to read data, and seems to have the
exact same format for offset/length.

It doesn't actually seem to ever read that exact serial number from
that address, though. The mares app did the following offset/length
reads (this is all little-endian, so "1e1d0100" means offset
0x00011d1e, and length "00010000" is 0x00000100, aka 256.

00000000 10000000
00600000 4d000000
00200000 59000000
...

but there are definitely 4-byte reads in there later. And that first
read is a 16-byte read from offset 0, which would *cover* the 4-byte
read we do at offset 12.

When it did that 16-byte read at offset zero, it got

  10 00 00 00 ee 05 01 00 02 00 00 00 b5 e9 00 00

back, so the serial number would *seem* to be those b5 e9 00 00 bytes
(which would be 59831 in 32-bit LE format). But when we do that 4-byte
read at offset 12, we get nothing at all.

So I don't see why that data read seemed to fail and not return any
information. Everything else looked really good, and the Mares app
seems to use the exact same command set, just slightly different
offset/length values.

Jef, do you have any ideas? Have you seen anything like this before?

                Linus


More information about the subsurface mailing list