October 2014 - devel - libdivecomputer.org

Re: Patches to add basic support for the Suunto EON Steel
by Jef Driesen 24 Nov '14

24 Nov '14

Linus, 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. There has been quite some discussion on the new string based api for libdivecomputer. I'll need some more time to go through this whole discussion and give its some more thoughts. Therefore, I propose we target for a first version of the eonsteel backend without any of those string based api changes. So that's basically your 0001 patch. Those are not critical features, and trying to rush things is always a bad idea. So what I consider mandatory to fix before I'll commit your patches are: 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. Working build on Windows. I have attached a patch that does the necessary casts (and a few other things) to get the mingw and msvc builds to work. In most places, I simply added casts wherever the compiler complained, without checking whether that was the right thing to do. Many of those casts can probably avoided by using the correct type (unsigned instead of signed). Even the gcc compilers spits out tons of warnings, so you don't even need msvc to locate the type mismatches. 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. Proper integration with the libdivecomputer logging functions. The other ones I can live with and/or fix later. (more inline comments below) On 28-10-14 17:51, Linus Torvalds wrote: > On Tue, Oct 28, 2014 at 8:43 AM, Jef Driesen <jef(a)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. 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. > 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. I guess everyone does printf logging at some point. Me too :-) >> 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. The logged info doesn't need to be useful for the user. The user only needs some super easy way to get the log and then send it back to someone that does understand what's inside. There are also multiple loglevels, which the application can control. ERROR and WARNING are self explanatory. INFO is used for logging the communication protocol (e.g. raw data packets), and DEBUG is for whatever else you would like to log. >> 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 very rarely need void pointers. Probably only for very generic functions like memcpy and friends. For byte arrays unsigned char's are perfect, and they also avoid the whole void pointer arithmetic problem. >> 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. 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 :-) This timestamp is also a good candidate for use as the libdivecomputer fingerprint! > (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. Your data files where too large for the list. I got them, but if you want I can still manually approve your mail. > 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"). A small pressure chamber might be even more convenient: no need to have a pool around. Jef

3 17

[PATCH] Support for Cochran EMC and Commander Air import
by John Van Ostrand 17 Nov '14

17 Nov '14

Specifically tested with EMC-20H and Commander Air_Nitrox this commit should support the families for the most part however there are may be differences in the DC signature, memory size, and other factors that will prevent opening the device and obtaining a clean import. Try it with other EMC and Commander devices and check library ERRORs for the signature information needed to add support. Also missing is tank pressure (for Gemini) and support for logbooks that have rolled old dives off. There is support for dive samples that have rolled off. John Van Ostrand (1): Added support for Cochran EMC and Commander Air import examples/Makefile.am | 6 +- examples/cochran_download.c | 299 +++++++++++++ examples/universal.c | 8 +- include/libdivecomputer/Makefile.am | 3 +- include/libdivecomputer/cochran.h | 61 +++ include/libdivecomputer/common.h | 3 + include/libdivecomputer/parser.h | 20 +- src/Makefile.am | 7 +- src/cochran_cmdr.c | 66 +++ src/cochran_cmdr.h | 83 ++++ src/cochran_cmdr_parser.c | 202 +++++++++ src/cochran_common.c | 861 ++++++++++++++++++++++++++++++++++++ src/cochran_common.h | 109 +++++ src/cochran_common_parser.c | 157 +++++++ src/cochran_common_parser.h | 80 ++++ src/cochran_emc.c | 67 +++ src/cochran_emc.h | 180 ++++++++ src/cochran_emc_parser.c | 399 +++++++++++++++++ src/descriptor.c | 3 + src/device.c | 7 + src/libdivecomputer.symbols | 2 + src/parser.c | 7 + 22 files changed, 2617 insertions(+), 13 deletions(-) create mode 100644 examples/cochran_download.c create mode 100644 include/libdivecomputer/cochran.h create mode 100644 src/cochran_cmdr.c create mode 100644 src/cochran_cmdr.h create mode 100644 src/cochran_cmdr_parser.c create mode 100644 src/cochran_common.c create mode 100644 src/cochran_common.h create mode 100644 src/cochran_common_parser.c create mode 100644 src/cochran_common_parser.h create mode 100644 src/cochran_emc.c create mode 100644 src/cochran_emc.h create mode 100644 src/cochran_emc_parser.c -- 1.8.3.1

2 12

Re: Patches to add basic support for the Suunto EON Steel
by Linus Torvalds 04 Nov '14

04 Nov '14

Ok, this reply didn't go to the mailing list, because the dive log attachments made it too big. So I'm just quoting the text here for mailing list posterity, I'm assuming Jef got the actual attachments and hopefully nobody else cares (and maybe I shouldn't make my dive data that public anyway). Linus On Tue, Oct 28, 2014 at 9:51 AM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > On Tue, Oct 28, 2014 at 8:43 AM, Jef Driesen <jef(a)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

5 18

Connection with Smart Z hangs
by Martin Lang 03 Nov '14

03 Nov '14

Hi, since my Windows machine stopped working and I cannot read out my Uwatec Smart Z computer anymore on this computer, I tried doing directly with my Ubuntu workstation. Unfortunately subsurface hangs always during import of the dive logs. So I tried the test application from libdivecomputer. >martin@Asterix:~/Downloads$ ./smart /dev/ttyS1 >DATETIME 2014-10-22T09:19:17Z (1413969557) >VERSION 0.5.0-devel (61e9847196b4e7f4e2c80e47dd6cd7070c9c4418) >uwatec_smart_device_open >INFO: Discover: address=ebd76f01, name=Aladin Smart Z, charset=00, hints=8000 >INFO: Connect: address=ebd76f01, lsap=1 After that the window freezes and the smart application hangs. The system is an Ubuntu 14.10 system. Any help is highly appreciated.

5 4

New trial at EON Steel support - with DC_FIELD_STRING
by Linus Torvalds 29 Oct '14

29 Oct '14

Ok, this is a re-done set of patches that uses DC_FIELD_STRING instead of DC_FIELD_DEVINFO. I've also changed "eon_steel" to "eonsteel" throughout (unless I missed something) as per Jef. Also, to show how DC_FIELD_STRING allows other things, I added "Deco algorithm", "Battery before dive" and "Battery after dive" parsing to the EON Steel backend, although right now my subsurface patch just simply ignores that extra data. We'll need a way to show it, or at least save/restore it sanely, so that will take a bit of effort. But it's there, and it works (tested by printing the values out to stderr - that "debugging" is not in this series of patches, though). Anyway, I think Dirk was right, the DC_FIELD_STRING model is nicer than showing it as samples, although it did make the subsurface interface a bit different: since we don't get all the version and dive ID data together as one "devinfo", we actually need to save them off individually and then at the end add it to our dive computer database. But that's probably a good idea anyway, since we very likely *should* save at least fw version per-dive rather than per divecomputer (since the same dive computer can have multiple firmware versions over time). Whatever. The subsurface patch is still pretty small and straightforward, although to save/show generic strings will definitely take more effort. But battery information is apparently something people have been asking for, so I think it's all good. I could have done inter-diffs from the previous version, but with the big renames of "eon_steel" to "eonsteel", that diff wouldn't really have been very useful anyway, and it's not like the previous version was applied, so this is an all-new series. Three patches for libdivecomputer, and one patch for subsurface. Linus

2 1

Wisdom 3
by Dirk Hohndel 29 Oct '14

29 Oct '14

Hi there, I see that both MacDive and DivingLog claim Wisdom 3 support... Looking at the dump from a Wisdom 3 its reply to the version command is "WISDOM R3B 512K" and the model at address 0x0008 is 0x4458 which we don't appear to have covered in src/oceanic_atom2_parser.c Has anyone sat down and looked at which parser layout is correct for the Wisdom 3? We have a bug report where most everything seems to work, but the temperature readings during the dive are off. Given the insanity of how Oceanic stores temperatures... it seems entirely possible that they did yet another minor "tweak" there. But if someone else has worked this out already I'd love to just get this fixed in libdivecomputer :-) Thanks /D

2 3

Patches to add basic support for the Suunto EON Steel
by Linus Torvalds 28 Oct '14

28 Oct '14

Ok, I re-organized my patches a bit, and here are four patches to support the basic dive log download of the new Suunto EON Steel dive computer. I combined some of my basic support patches into one, since I didn't feel like I needed to show the odd history of having implemented some things in stages (ie the second attachment was originally four patches that didn't do anything useful unless combined).. Three of the patches are for libdivecomputer: - patch 1/3: the preparatory parser support patch - patch 2/3: the basic core dive data downloader for the EON Steel - patch 3/3: the small addition to parse more than the basic data Patch 2/3 works on its own, but means that you *just* get the core dive data (with full dive profiles and cylinder pressures). Patch 3/3 gives you the serial number and firmware version etc, but that relies on 1/3. The fourth patch (1/1) is the patch to subsurface to actually use the new parser support in libdivecomputer, so that you can get the EON Steel serial numbers etc. This makes your Suunto EON Steel quite usable with subsurface. There is more we could do, but it's all fairly secondary stuff. I'd like to get this all accepted before I even bother starting to look at the other things I can do with the dive computer. Of course, since apparently the EON Steel won't really be *available* until Nov 15th or so, right now these patches are useful mainly to people with preproduction models like me. But wouldn't it be nice if we could just say that we support the thing before it's even available for sale? Linus

3 5

A300CS
by Dirk Hohndel 28 Oct '14

28 Oct '14

Hey Jef, just checking in to report that the A300CS support in master seems to work fine. Sadly I don't have the deco dives on there anymore (grmbl), but I'll rectify that soon. /D

1 0

Support for older Cochran computers
by John Van Ostrand 26 Oct '14

26 Oct '14

Hi, Is there any reason for me to work on adding support for older Cochran computers like the Aquanox or lifeguard? Has anyone inquired about support? -- John Van Ostrand At large on sabbatical

2 1

RFC: add larger pagesize read to Atom2 backend
by Dirk Hohndel 26 Oct '14

26 Oct '14

So after all the back and forth I'm not 100% sure where we wanted to end up with the larger pagesize read support. Here's something really simple, really straight forward (I think) that should not impact any of the other backends (unless there's a bug in my code, always a possibility). It should be trivial to extend this for other models that have a 128 byte pagesize and support unaligned reads. It doesn't mess with the multipage code, it doesn't change any of the calling code to do alignment for us - so on average this will use about twice the number of reads that better optimized code would use - but still only about 1/8 of the reads that the current code would use. Let me know what you think. And yes, this turns into patch #5 after the four existing A300CS patches and should applied with the four of them together, in case you like it. /D

2 1