Patches to add basic support for the Suunto EON Steel

Tue Oct 28 09:51:58 PDT 2014

On Tue, Oct 28, 2014 at 8:43 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
>
> There are also some header files like unistd.h which don't exist on windows.

Hmm. I wonder why I included them.

Part of it is probably that the whole back-end started out as this
"suunto hacking tool" that did a lot of "print hex information of the
packets". That's also why there was no libdivecomputer infrastructure,
this thing was entirely stand-alone for just trying to gather traces
and recreate them, and figure out what the things did.

I got no actual information from Suunto, but the fact that many things
are just text helped. Seeing filenames etc in the dumps etc.. And the
actual dive dumps have this interesting "each data has its type
associated with it, and each type has a human-readable type
descriptor". Which meant that I never needed to guess what the actual
data means - the problem was figuring out the odd marshaling of the
data, and the odd packet protocol.

(For example, in the attached dive files, you don't see the crazy
packet protocol artifacts, because "read_file()" has cleaned it all
up. Just looking at the textual parts of the packets confused me
initially, because it turns out that the dive computer re-uses the
buffer it uses for sending the USB packets, and only fills in the
parts it needs for a possible partial packet. So the HID packets will
contain random garbage from the *previous* packet at the end etc etc.
And while the packets are 64 bytes, the two first bytes of the packet
is "packet information", so each packet contains just 62 bytes of
actual payload, yadda yadda).

> Libdivecomputer doesn't log anything on its own. The actual logging is done
> by the application. That's on purpose. That's for example how subsurface is
> able to generate a libdivecomputer log directly from the GUI. I believe
> that's a very useful feature, which certainly doesn't sucks :-)

So the logging I have is for protocol errors, or surprising things.
Not useful to users. It's more of a protocol verification, I would
*not* want it to show up in applications.

> Why do you need void pointers here? You're parsing a byte array, which is by
> definition an unsigned char array. So where do you get void pointers from?

"void *" is the "random byte area" type. It's one of the things C++
completely screwed up.  It's very useful when you use the helper
function on random data (that may be embedded in structures etc, or
give pointers to "uint32_t" etc when you convert from little-endian to
big-endian etc.

But if there are no cases of that left over, maybe you can convert
them all to "unsigned char *" ..
> I know it doesn't support a standard memory dump. But a dump of one dive is
> fine too. I can use the parser standalone.

I hacked up subsurface to just dump the per-dive data to a
"dive-%08x.log" file. That's *fairly* close to what the computer does
internally, although this dumped data contains the date in the first
32-bit word, which is what the parser expects. On the dive computer,
the date is encoded in the filename - see the

    dc_buffer_append(file, buf, 4);

in eon_steel_device_foreach() where I append it to the data buffer
instead, since the parser doesn't have access to the filename.

(The dive date is *also* encoded in the dive data, but in a very
inconvenient format with a dynamic type, so I wanted the data from the
filename for simplicity).

So here are the dumps of the dives I have on that dive computer so
far, in that "parser format".

That first dive is just me lowering the dive computer into the
neighbors pool. The other 21 dives are the ones we did in Bonaire.

Dirk has one of the Intel engineers create a contraption to lower the
thing into the pool multiple times, so that I can see what happens to
the directory listing when it no longer fits in one "readdir" reply
(the packets may be 64 bytes each, but they are chained up to be
replies that can apparently be up to 1kB in size - at least I haven't
seen anything bigger than that yet. And I don't know what happens when
the directory listing is bigger than that, because the 22 dives I have
so far create only about 460 bytes of "readdir reply").

                          Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5422daf7.log
Type: text/x-log
Size: 6459 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0022.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5433c203.log
Type: text/x-log
Size: 15512 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0023.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5433f7ce.log
Type: text/x-log
Size: 13569 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0024.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5434ffe3.log
Type: text/x-log
Size: 12739 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0025.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5436be9b.log
Type: text/x-log
Size: 14528 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0026.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5436d1a7.log
Type: text/x-log
Size: 11498 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0027.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5437a208.log
Type: text/x-log
Size: 13982 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0028.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5437b9d9.log
Type: text/x-log
Size: 13283 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0029.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5437d0ff.log
Type: text/x-log
Size: 21186 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0030.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5438ee19.log
Type: text/x-log
Size: 13840 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0031.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-54340f04.log
Type: text/x-log
Size: 13818 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0032.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-54364d35.log
Type: text/x-log
Size: 13717 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0033.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-54393ad6.log
Type: text/x-log
Size: 13632 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0034.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-543679a3.log
Type: text/x-log
Size: 13995 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0035.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-543827eb.log
Type: text/x-log
Size: 13745 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0036.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-543902a8.log
Type: text/x-log
Size: 12751 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0037.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5435473b.log
Type: text/x-log
Size: 12423 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0038.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5435823d.log
Type: text/x-log
Size: 12318 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0039.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-5438173d.log
Type: text/x-log
Size: 13157 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0040.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-54351776.log
Type: text/x-log
Size: 12571 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0041.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-54366401.log
Type: text/x-log
Size: 13690 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0042.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dive-54391534.log
Type: text/x-log
Size: 13560 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141028/7ab1e8f2/attachment-0043.bin>