On Fri, Oct 31, 2014 at 3:25 PM, Jef Driesen jef@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