Patches to add basic support for the Suunto EON Steel

[Linus Torvalds]

On Fri, Oct 31, 2014 at 3:25 PM, Jef Driesen <jef at libdivecomputer.org> wrote:
>
> According to Dirk the plan is to have a subsurface beta ready before the
> eonsteel is available on the market. And thus is would be convenient to have
> a first version included in libdivecomputer. I'll do my best to meet that
> deadline.

It's not a big deal. I'd love to be able to say that subsurface
supports the EON Steel, but if it's just a preliminary build of
subsurface with a temporary hack for the dive computer, that's fine.
I'd prefer for there to be device ID's (and that needs the string
patches, even if it might then be implemented another way later),
because without that the dive matching is much less reliable.

Anyway, my point being that it certainly doesn't need to be some
"final released form". More of a "Suunto gave me access to an EON
Steel, so here's a random build of subsurface that you can use if you
want to".

> Naming conventions for entry point functions and the private device and
> parser structures. I know you don't like these long names, but that's the
> convention in the libdivecomputer codebase, and I'll insist on following
> existing practice. See the 0001 patch.

All patches look fine to me. Although I think Dirk had another patch
for some Windows issue. I doubt Dirk cares one way or another.

> BTW, if the goal is to demo a build to Suunto, then I think we should not
> only compile test on Windows, but actually try a Windows build too. They are
> probably using Windows.

Dirk had that working already, afaik. Although he uses gcc and
cross-compiles, so he didn't hit some of the issues your build would
have.

> Proper integration with the libdivecomputer logging functions.

I'll take a look, today has been Linux work for me (and will be
halloween later().

> No idea why you needed sys/types.h, fcntl.h, etc. Most of the other ones are
> also no longer necessary if the custom logging is removed.

The sys/types.h and fcntl.h etc are for "open()".  I suspect unistd.h
was for similar direct access. Remember, my EON steel debug
application was stand-alone.

> I very rarely need void pointers.

It's not about "need". It's about "the right thing".

The fact that C++ screwed up "void *" is a sad commentary on the crap
that is C++.

"void *" is simply the right type to use when the type is some opaque
generic byte stream. Exactly because it doesn't need pointless casts.

> For byte arrays unsigned char's are perfect

The thing is, it's not always a "byte array". Sometimes it's a
constant string (which is *not* "unsigned char"). Sometimes it might
be a packed structure. Etc etc.

"void *" does that right, in ways that "unsigned char *" does not.

Of course, if you have to use C++ because of Windows breakage, you
don't ever see this, because you're fighting language bugs.

>> 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.
>
>
> That looks very reasonable. Is it always a 32bit number? If it could be a
> 64bit timestamp, then it might be safer to reserve 8 bytes here. One Y2038
> problem less :-)

It's actually always a 32-bit number, and it's encoded on the computer
as a 8-byte hex string.

The Suunto EON Steel filesystem looks suspiciously like a FAT
filesystems. Names are case-insensitive and of type "8.3" (even if
they just look like strings in the protocol). The dive directory is
"0:/dives", but I checked, and "a:/dives" actually also works ;)

So the dive files on the device are actually named "%08x.LOG".

And yes, I realize that this means that Suunto expects to redesign
something before 2038 rolls around. We'll see how they do it. It may
be that by then, we'll have to actually parse the string-format date.
Or maybe they'll change their filesystem (the packet-based path
interface is *not* limited to 8.3 names, so they could do it without
breaking things).

I suspect one reason for the 32-bit timestamp is just Suunto's own DM5
application too. It shows some limitations in other forms: it shows
temperature in whole degrees Celsius, even though the EON Steel
actually returns things in tenth of a degree. I suspect there's a lot
of legacy code there for the older Suunto dive computers, which (if I
recall correctly) also do a 32-bit timestamp in seconds since 1970.

> This timestamp is also a good candidate for use as the libdivecomputer
> fingerprint!

I actually use not the timestamp, but the time *string* as the
fingerprint. You should be able to see it from the log-files I sent
you: the 4-byte timestamp is what I use for time, but therre;'s
actually this (inconvenient) "Header.DateTime" thing that gives date
and time as a string with *milliseconds*. I give that as the "Dive ID"
string, and then generate the dive fingerprint by hashing that string.

And that better fingerprint is not available until after parse time,
once more. The parsing is a bit complex, as you probably saw, with
embedded dynamic type information (well, _some_ of it is dynamic,
including the DateTime string, while some of the simpler fields seem
to be encoded in a static form - the type is a two-byte entity, and it
looks like the upper byte is "static vs dynamic". So a type of
"0x0010" is a static type and has had the same meaning in all the
dives I've seen, while a type of 0x0110 is dynamic and seems to depend
on the dive - so the types really have to be parsed on a dive-by-dive
basis).

I actually really like the Suunto marshaling of data, but simple it is
not. Nothing is at fixed offsets etc.

> Your data files where too large for the list. I got them, but if you want I
> can still manually approve your mail.

No, I don't think anybody else really needs them. If somebody asks,
I'll forward them. Or you can, if somebody asks you for test-cases.
It's not like they are secret or contain sensitive information, but no
need to put them on the list if nobody asks for them.

> A small pressure chamber might be even more convenient: no need to have a
> pool around.

Oh agreed. I don't have one, though. I'd love to, but I suspect
anything that would be automatically controllable runs in the
thousands of dollars. The "dip into the pool" is an arduino and a
motor, and can be built by crazy Intel engineers without any fear of
explosions.

                      Linus