- devel - libdivecomputer.org

Cochran DC Data Structures
by John Van Ostrand 03 Nov '14

03 Nov '14

The Cochran DCs have a distinct data download and format. Basic communication; Recent model Cochran computers (Commander, EMC and probably the Gemini) use a 3 pin interface to a custom USB<->RS-232 FTDI chip interface provided by Cochran. Initial connections to the device are made at 9600, n, 8, 2, with no flow control. The DC will not respond to commands until it is first prompted. Prompting the device with 1 flush of output queues and 6 flushes of input queues triggers the device to send a heartbeat byte of 0xAA every second. Commands sent before an AA byte is issued are ignored. Most commands respond using the same serial parameters as used to send the command however large data transfers like logbook and sample download responses are sent at a higher rate. The rate depends on the DC model. The EMC baud rate is 825,600bps while the Commander is 115,200. For example, to download a typical command, like a configuration block one would do this: Open port @ 9600, n, 8, 2, no fc Flush output Flush input (repeat 6 times) Wait to receive 0xAA heart beat byte send 0x96 0x00 receive 512 bytes However for a logbook download: Open port @9600, n, 8, 2, no fc Flush output Flush input (repeat 6 times) Wait to receive 0xAA heart beat byte send 0x15 (4 byte address) (4 byte size) 0x05 reconfigure port to 825600 receive bytes set port back to 9600 There is one exception to this protocol. To download the miscellaneous block of data we send one byte, wait for a heart beat then send the remaining command and wait for a response. The example shows opening the port for every command only to illustrate the settings. In practice the port is opened only once and all blocks of data can be downloaded. The series of reads are as such: 67 byte "id" block (cmd: 0x05, 0x9D, 0xFF, 0x00, 0x43, 0x00) if this id block doesn't have the string "(C)" then read another id block 67 byte "id" block (cmd: 0x05, 0xBD, 0x7F, 0x00, 0x43, 0x00) Read 2 or 4 config blocks 512 bytes "config" block (cmd 0x96, 0x00) 512 bytes "config" block (cmd 0x96, 0x01) 512 bytes "config" block (cmd 0x96, 0x02) 512 bytes "config" block (cmd 0x96, 0x03) Within the config block will be the settings of the computer. In some cases the owner's information is there. More importantly the first block contains the number of dives in computer memory. This number can be as high as 1024. A miscellaneous block can be read. 1500 bytes "misc" (cmd: 0x89, 0x05, 0xCA, 0xFD, 0x00, 0xDC, 0x05) Using information from the config we can read the logbook. Logs for each dive are 256 bytes for an older computer and 512 bytes for a new computer. Each log has a dive start section containing the information known at the dive start, like date/time, SIT, temp, starting tissue pressures, and much of the computer's configuration at the time the dive started. Importantly it contains the byte offset into sample memory where the dive samples begin. This start section is exactly half the size of the log so 128 or 256 bytes. The second half is the end-dive section that contains summary information about the dive itself. It contains the ending memory offset of the dive samples, dive time, avg depth, max depth, min temp, etc. NOTE: The cmd below shows an EMC command. The Commander command uses 3 byte addresses and sizes. ??? bytes "logbook" (cmd 0x15 (4 byte address), (4 byte size) 0x05 Sample data occurs every second during the dive, off-gassing seconds and inter-dive events like altitude and temperature changes and unit-on events. Sample data is delivered in either 2 bytes/second (commander) or 3 bytes/second (EMC). Bits 0-6 of the first byte is always the change in depth in 1/4ft increments, with bit 6 indicating negative.Bit 7 is a flag bit, 0 indicated a depth sample 1 indicates a dive event, like ascent warning, or gas change. The second byte varies. On the first sample it's the ascent rate/min in 1/4ft units. Bit 7 indicates a negative. On the second sample it's the temperature, in 1/2 degrees F above 20. These two alternate throughout the dive. On the EMC there is a third byte which is also overloaded. Twenty four seconds of samples are needed to assemble the third sample. The first 20 bytes of this sample contain the tissue pressures, the next four contain the NDL minutes (in 2 bytes) (if not in deco) or deepest stop deco time (2 bytes) plus the total deco time (last two bytes). So a full cycle of samples on an EMC takes 24 seconds which contains 24 depth samples, 12 ascent rate samples, 12 temp samples, one set of tissue pressures, and the NDL or Deco time remaining. ??? bytes "sample" (cmd 0x15 (4 byte address) (4 byte size) 0x05 There is more detail to this protocol but this describes the basics. Examples use EMC protocol. The base memory for samples and for logbook varies based on the model. The size of memory varies based on model and based on the features enabled for the model. The date format varies between models. I suspect that lots of other parts of memory can be read using these commands. I haven't explored that. -- John Van Ostrand At large on sabbatical

2 1

[PATCH 1/8] Added define so apps can tell if new functionality is there.
by John Van Ostrand 03 Nov '14

03 Nov '14

--- include/libdivecomputer/parser.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/libdivecomputer/parser.h b/include/libdivecomputer/parser.h index 0f7021b..4c4a77c 100644 --- a/include/libdivecomputer/parser.h +++ b/include/libdivecomputer/parser.h @@ -93,6 +93,9 @@ typedef enum parser_sample_event_t { /* For backwards compatibility */ #define SAMPLE_EVENT_UNKNOWN SAMPLE_EVENT_FLOOR +/* For apps to determine new functionality */ +#define SAMPLE_EVENT_BATTERY 1 + typedef enum parser_sample_flags_t { SAMPLE_FLAGS_NONE = 0, SAMPLE_FLAGS_BEGIN = (1 << 0), -- 1.8.3.1

1 7

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

[PATCH] parser: add DC_FIELD_DEVINFO field type for parse-time device information
by Linus Torvalds 23 Oct '14

23 Oct '14

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Wed, 22 Oct 2014 11:23:09 -0700 Subject: parser: add DC_FIELD_DEVINFO field type for parse-time device information This can be used to extend and override the device open-time DEVINFO callback information at dive parse time. If you leave the pointers NULL, nothing happens, but you can choose to individually fill in the fields as needed (or not). NOTE: The caller is supposed to clear the structure so that the divecomputer backends don't need to care about fields they don't support. So it's valid for a backend to just return DC_STATUS_SUCCESS and not do anything else as a reply to DC_FIELD_DEVINFO, although obviously that means that you won't be returning any new information either. Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- This is actually "PATCH 6/7" in my current series to support the new Suunto EON Steel dive computer, but it stands on its own as preparatory infrastructure, and I thought I should send it out as such. This simply implements the "DC_FIELD_DEVINFO" field, which allows a dive computer backend to - at parse time - give what amounts to a sanitized and extended version of the DC_EVENT_DEVINFO device event. In particular, it differs from DEVINFO in that: - it contains all strings (expected to be utf8, because we're not barbarians any more, but for Windows people you could just say "ASCII" to not confuse the poor souls) - it is expected to be called for each dive at parse time, and also thus allows a "dive id" string to be filled in. - if the dive computer backend doesn't have anything to add to the original DC_EVENT_DEVINFO, then the backend can just ignore this. The basic premise is simply that (a) strings are good and (b) we may have more information at parse-time than at the original DC_EVENT time.. This is trivially usable by subsurface - or any other user of libdivecomputer - in *addition* to the old interface, and I'll post another patch to show how subsurface does it. It doesn't replace or remove the old DC_EVENT_DEVINFO interface, it really just is a seamless extension of it with a better interface. As you can see, the patch itself is also really really trivial and small. So not only is this flexible and simple to use, the implementation really is trivial too. Comments? Btw, I'm in no way married to the particular fields. They are not at all everything that the EON Steel returns, but they seem to be fairly generic and useful in general. Side note: the "vendor/model" thing migth be too much repetition and I don't really use it for the EON Steel at all, but I added those because I think it might be useful for the case where the user doesn't specify the device very precisely, and one backend can handle many different models. In other words, this might be a good way to allow the back-end to give more precise information, without having the user having to care (ie if the backend can download from both a "Mares Icon" and a "Mares Icon HD", and the user doesn't need to specify *which* one it is, this would allow the dive log app to get the exact model name even if the user just said "Mares Icon". Comments? include/libdivecomputer/parser.h | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/include/libdivecomputer/parser.h b/include/libdivecomputer/parser.h index 65b18c9bb2fe..741803f4e256 100644 --- a/include/libdivecomputer/parser.h +++ b/include/libdivecomputer/parser.h @@ -53,9 +53,13 @@ typedef enum dc_field_type_t { DC_FIELD_GASMIX_COUNT, DC_FIELD_GASMIX, DC_FIELD_SALINITY, - DC_FIELD_ATMOSPHERIC + DC_FIELD_ATMOSPHERIC, + DC_FIELD_DEVINFO, } dc_field_type_t; +// Make it easy to test support compile-time with "#ifdef DC_FIELD_DEVINFO" +#define DC_FIELD_DEVINFO DC_FIELD_DEVINFO + typedef enum parser_sample_event_t { SAMPLE_EVENT_NONE, SAMPLE_EVENT_DECOSTOP, @@ -128,6 +132,17 @@ typedef struct dc_gasmix_t { double nitrogen; } dc_gasmix_t; +// You don't have to fill all of these in, you can leave them NULL +// but if you do fill them in, they override the device devinfo +typedef struct dc_field_devinfo_t { + const char *vendor; + const char *model; + const char *serial; + const char *hw_version; + const char *fw_version; + const char *dive_id; +} dc_field_devinfo_t; + typedef union dc_sample_value_t { unsigned int time; double depth; -- 2.1.2.452.gd5ca7ae

1 2

First cut at EON Steel patches
by Linus Torvalds 22 Oct '14

22 Oct '14

Ok, this is very much incomplete, and it doesn't send things like the DC_EVENT_VENDOR or DC_EVENT_DEVINFO stuff at all. Which means that you don't get serial numbers etc. Part of that is that I'm *really* frustrated with the libdivecomputer crap wrt firmware versions and serial numbers. This goes back *years*: the fact that libdivecomputer still seems to think that they are unsigned integer values. They are *not*. They are strings. But libdivecomputer doesn't have a sane interface to report strings. The firmware version I have is 1.0.7. The serial number I have is "#p1437019". Neither of them is a number (and yes, I'm serious, the characters '#' and 'p' are part of the serial number: both as the dive computer reports it, and printed on the dive computer itself). But apart from the fact that this is *still* completely broken in libdivecomputer, these two patches get at least a usable profile out of the Eon Steel. Let me know if you find something fundamentally broken here, Linus

3 4