- 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

Re: Petrel data problems [was Re: Crash when opening log file]
by Jef Driesen 24 Nov '14

24 Nov '14

On 23-11-14 16:25, Dirk Hohndel wrote: > On Sun, Nov 23, 2014 at 11:39:55AM +0100, Henrik Brautaset Aronsen > wrote: >>> >>> I did a new fresh import from my Petrel on the latest master and >>> saved it. >>> This time the saved petrel2.xml [1] does not contain the empty >>> <cylinder >>> /> statements. But id does contain cylinders with something in them, >>> even >>> on gauge dives: >>> >>> <cylinder o2='52.0%' /> >>> <cylinder o2='18.0%' he='45.0%' /> > > I haven't used my Petrel in gauge mode (that's one heck of an expensive > gauge...). It would make sense that it doesn't support any gases in > that > mode, but libdivecomputer doesn't know that the Petrel was in gauge > mode > so it tells us about those gases as they are present in the dive > header. > I am making a lot of assumptions here - but since I know a little bit > about the Petrel data format I think these are reasonable assumptions. > > Jef, can you confirm this analysis? Yes, your analysis is correct. I just checked the documentation, and the gauge mode isn't mentioned anywhere. So either it's just missing in the documentation, or it's not recorded. The Petrel (and Predator too) is also one of the devices where the dive mode is stored in the sample data, and not the dive header. I assume that's done because you can switch between OC/CC during the dive. But that makes it also rather difficult to tell whether a dive is OC or CC (e.g. what should we do if there are mixed samples?). And thus what libdivecomputer does is just return all gas mixes. >>> I tried to do a data dump, but both subsurface and the >>> libdivecomputer >>> dump app doesn't cooperate: > > IIRC, the Petrel doesn't support dumps. > >> Result: Unsupported operation The Petrel protocol doesn't support memory dumps. The Petrel also supports the older Predator protocol. That one supports memory dumps, but is only capable of downloading the last 128K of memory. For protocols without support for memory dumps, I usually dump the individual dives, using this patch for the universal app: http://www.libdivecomputer.org/tmp/universal_dump_dives.patch Jef

1 0

Re: Petrel data problems [was Re: Crash when opening log file]
by Henrik Brautaset Aronsen 23 Nov '14

23 Nov '14

Henrik Brautaset Aronsen wrote: > Dirk Hohndel wrote: >> >> On November 22, 2014 9:52:42 PM Miika Turkia <miika.turkia(a)gmail.com> >> wrote: >> >> > > I'll need to poke at that and figure out what's happening. I'm quite >> > > pressed for time right now, hopefully I'll get to it after the >> weekend. >> > > >> > >> > The XML contains po2 values. Isn't that currently enough to make >> Subsruface >> > treat the dive as a CCR dive? >> >> I believe you are correct >> > > I did a new fresh import from my Petrel on the latest master and saved > it. This time the saved petrel2.xml [1] does not contain the empty > <cylinder /> statements. But id does contain cylinders with something > in them, even on gauge dives: > > <cylinder o2='52.0%' /> > <cylinder o2='18.0%' he='45.0%' /> > > I tried to do a data dump, but both subsurface and the libdivecomputer > dump app doesn't cooperate: > > $ examples/universal -l petrel2.log -m petrel2.bin -v -n "Shearwater > Petrel" /dev/tty.Petrel-SerialPort > DATETIME 2014-11-23T10:29:31Z (1416738571) > VERSION 0.5.0-devel (e307227b808186beccc00461103477156e97f5e4) > Opening the device (Shearwater Petrel, /dev/tty.Petrel-SerialPort). > INFO: Open: name=/dev/tty.Petrel-SerialPort > INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=1, > flowcontrol=0 > INFO: Timeout: value=3000 > INFO: Sleep: value=300 > INFO: Flush: queue=3, input=0, output=0 > Registering the event handler. > Registering the cancellation handler. > Downloading the memory dump. > universal.c:793: Error downloading the memory dump. > INFO: Write: size=9, data=FF0105002E902000C0 > Result: Unsupported operation > > (at this point, the Petrel immediately drops out of the upload dive mode) The same thing happens with the universal app from http://libdivecomputer.org/builds/macosx/ as well. Any ideas, Jef? $ ~/Downloads/universal -l petrel2.log -m petrel2.bin -v -n "Shearwater Petrel" /dev/tty.Petrel-SerialPort DATETIME 2014-11-23T10:37:18Z (1416739038) VERSION 0.5.0-devel (5e88cf749475377fe21d2dd2b4d60fce6542127c) Opening the device (Shearwater Petrel, /dev/tty.Petrel-SerialPort). INFO: Open: name=/dev/tty.Petrel-SerialPort INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=1, flowcontrol=0 INFO: Timeout: value=3000 INFO: Sleep: value=300 INFO: Flush: queue=3, input=0, output=0 Registering the event handler. Registering the cancellation handler. Downloading the memory dump. ../../source/examples/universal.c:802: Error downloading the memory dump. INFO: Write: size=9, data=FF0105002E902000C0 Result: Unsupported operation -H

1 0

OSTC3 firmware upgrades
by Anton Lundin 21 Nov '14

21 Nov '14

Hi! This is is a RFC series of patches to add support for firmware upgrades on the OSTC3. The code have bin tested both against a "pcb" by HW and against my OSTC3 so it works and does the right things. JeanDo's ostc-companion[1] have bin the reference implementation I've looked at when I wrote this code. There are still a couple of pain-points that I would like some feedback on: How to start the device in service mode: To get access to the necessary commands for service mode, we can't INIT the device with INIT(0xBB), we need to INIT it with a special service mode sequence(0xAA, 0xAB, 0xCD, 0xEF). Now the INIT is sent in hw_ostc3_device_open, so how do you suggest that we refactor the code to allow another sequence after open? The current quite crude hack is to just EXIT(0xFF) the device and re-init it after a 6s sleep. This won't work against the OSTC Sport. The timing between command and data in write_block: The current hw_ostc3_device_write_block is a bit of copy-paste from hw_ostc3_transfer, to be able to send the data buffer to the device, without a additional copy. Library triggered closed state: The device reboots when it gets the FLASH_FIRM-command so how can we "not fail" when the application then tries to talk to the device afterwards, or even call hw_ostc3_device_close? There are also a couple of other FIXME's in the code, which I plan on cleaning up, but I thought that I should send out a first RFC patch series to get some additional feedback going. Any other ideas about how the code looks? //Anton 1. https://bitbucket.org/JeanDo/ostc-companion/ -- Anton Lundin +46702-161604

3 15

[PATCH 1/4] Cochran: unused variable cleanup.
by John Van Ostrand 19 Nov '14

19 Nov '14

--- src/cochran_commander.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/cochran_commander.h b/src/cochran_commander.h index 8fa6228..95d4da4 100644 --- a/src/cochran_commander.h +++ b/src/cochran_commander.h @@ -89,8 +89,6 @@ typedef struct cochran_data_t { unsigned int sample_data_offset; unsigned int sample_size; - unsigned int last_interdive_offset; - unsigned int last_entry_offset; cochran_config_t conf; } cochran_data_t; -- 1.8.3.1

1 3

[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

[PATCH] Added Cochran support for max and surface temps
by John Van Ostrand 09 Nov '14

09 Nov '14

Also fixed up off-by-one pointers into logbook data. Signed-off-by: John Van Ostrand <john(a)vanostrand.com> --- src/cochran_cmdr_parser.c | 16 ++++++++++------ src/cochran_commander.h | 10 +++++++--- src/cochran_emc_parser.c | 28 ++++++++++++++++++++-------- 3 files changed, 37 insertions(+), 17 deletions(-) diff --git a/src/cochran_cmdr_parser.c b/src/cochran_cmdr_parser.c index 7cfd650..de25912 100644 --- a/src/cochran_cmdr_parser.c +++ b/src/cochran_cmdr_parser.c @@ -50,16 +50,20 @@ cochran_cmdr_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, if (value) { switch (type) { - case DC_FIELD_TEMPERATURE: - *((unsigned int*) value) = log[CMD_START_TEMP]; + case DC_FIELD_TEMPERATURE_SURFACE: + *((unsigned int*) value) = ((float) log[CMD_START_TEMP] - 32) / 1.8; + case DC_FIELD_TEMPERATURE_MINIMUM: + *((unsigned int*) value) = ((float) log[CMD_MIN_TEMP] / 2 + 20 - 32) / 1.8; + case DC_FIELD_TEMPERATURE_MAXIMUM: + *((unsigned int*) value) = ((float) log[CMD_MAX_TEMP] / 2 + 20 - 32) / 1.8; case DC_FIELD_DIVETIME: *((unsigned int *) value) = array_uint16_le (log + EMC_BT) * 60; break; case DC_FIELD_MAXDEPTH: - *((double *) value) = array_uint16_le (log + CMD_MAX_DEPTH) / 4 * FEET; + *((double *) value) = (float) array_uint16_le (log + CMD_MAX_DEPTH) / 4 * FEET; break; case DC_FIELD_AVGDEPTH: - *((double *) value) = array_uint16_le (log + CMD_AVG_DEPTH) / 4 * FEET; + *((double *) value) = (float) array_uint16_le (log + CMD_AVG_DEPTH) / 4 * FEET; break; case DC_FIELD_GASMIX_COUNT: *((unsigned int *) value) = 2; @@ -72,9 +76,9 @@ cochran_cmdr_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, break; case DC_FIELD_SALINITY: // 0 = low conductivity, 1 = high, maybe there's a 2? - water->type = ( log[CMD_WATER_CONDUCTIVITY] == 0 ? DC_WATER_FRESH + water->type = ( (log[CMD_WATER_CONDUCTIVITY] & 0x3) == 0 ? DC_WATER_FRESH : DC_WATER_SALT ); - water->density = 1000 + 12.5 * log[CMD_WATER_CONDUCTIVITY]; + water->density = 1000 + 12.5 * (log[CMD_WATER_CONDUCTIVITY] & 0x3); break; case DC_FIELD_ATMOSPHERIC: *(double *) value = ATM / BAR * pow(1 - 0.0000225577 diff --git a/src/cochran_commander.h b/src/cochran_commander.h index d16de42..1b040de 100644 --- a/src/cochran_commander.h +++ b/src/cochran_commander.h @@ -113,11 +113,13 @@ typedef struct cochran_device_t { #define CMD_START_DEPTH 56 // 2 byte, /4=ft #define CMD_ALTITUDE 73 // 1 byte, /4=Kilofeet #define CMD_END_OFFSET 128 // 4 bytes -#define CMD_MIN_TEMP 153 // 1 byte, F +#define CMD_END_TEMP 153 // 1 byte, F #define CMD_BT 166 // 2 bytes, minutes #define CMD_MAX_DEPTH 168 // 2 bytes, /4=ft #define CMD_AVG_DEPTH 170 // 2 bytes, /4=ft #define CMD_O2_PERCENT 210 // 8 bytes, 4 x 2 byte, /256=% +#define CMD_MIN_TEMP 232 // 1 byte, /2+20=F +#define CMD_MAX_TEMP 233 // 1 byte, /2+20=F // EMC log fields #define EMC_SEC 0 @@ -127,17 +129,19 @@ typedef struct cochran_device_t { #define EMC_MON 4 #define EMC_YEAR 5 #define EMC_START_OFFSET 6 // 4 bytes -#define EMC_WATER_CONDUCTIVITY 25 // 1 byte, 0=low, 2=high +#define EMC_WATER_CONDUCTIVITY 24 // 1 byte, 0=low, 2=high #define EMC_START_DEPTH 42 // 2 byte, /256=ft #define EMC_START_TEMP 55 // 1 byte, F #define EMC_ALTITUDE 89 // 1 byte, /4=Kilofeet #define EMC_O2_PERCENT 144 // 20 bytes, 10 x 2 bytes, /256=% #define EMC_HE_PERCENT 164 // 20 bytes, 10 x 2 bytes, /256=% #define EMC_END_OFFSET 256 // 4 bytes -#define EMC_MIN_TEMP 293 // 1 byte, F +#define EMC_END_TEMP 293 // 1 byte, F #define EMC_BT 304 // 2 bytes, minutes #define EMC_MAX_DEPTH 306 // 2 bytes, /4=ft #define EMC_AVG_DEPTH 310 // 2 bytes, /4=ft +#define EMC_MIN_TEMP 403 // 1 byte, /2+20=F +#define EMC_MAX_TEMP 407 // 1 byte, /2+20=F dc_status_t cochran_packet (cochran_device_t *device, diff --git a/src/cochran_emc_parser.c b/src/cochran_emc_parser.c index 37089a7..10d87a0 100644 --- a/src/cochran_emc_parser.c +++ b/src/cochran_emc_parser.c @@ -41,6 +41,7 @@ struct dive_stats { float max_depth; float avg_depth; float min_temp; + float max_temp; }; @@ -59,29 +60,38 @@ cochran_emc_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, dc_salinity_t *water = (dc_salinity_t *) value; unsigned int dive_time; - float max_depth, avg_depth, min_temp; struct dive_stats stats; if (value) { switch (type) { - case DC_FIELD_TEMPERATURE: + case DC_FIELD_TEMPERATURE_SURFACE: + *((unsigned int*) value) = ((float) log[EMC_START_TEMP] - 32) / 1.8; + break; + case DC_FIELD_TEMPERATURE_MINIMUM: + if (data->corrupt_dive) { + cochran_emc_parse_dive_stats(abstract, &stats); + *((unsigned int*) value) = stats.min_temp; + } else + *((unsigned int*) value) = ((float) log[EMC_MIN_TEMP] / 2 + 20 - 32) / 1.8; + break; + case DC_FIELD_TEMPERATURE_MAXIMUM: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = min_temp; + *((unsigned int*) value) = stats.max_temp; } else - *((unsigned int*) value) = (log[EMC_START_TEMP] - 32) / 1.8; + *((unsigned int*) value) = ((float) log[EMC_MAX_TEMP] / 2 + 20 - 32) / 1.8; break; case DC_FIELD_DIVETIME: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = dive_time; + *((unsigned int*) value) = stats.dive_time; } else *((unsigned int *) value) = array_uint16_le (log + EMC_BT) * 60; break; case DC_FIELD_MAXDEPTH: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = max_depth; + *((unsigned int*) value) = stats.max_depth; } else *((double *) value) = array_uint16_le (log + EMC_MAX_DEPTH) / 4 * FEET; @@ -89,7 +99,7 @@ cochran_emc_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, case DC_FIELD_AVGDEPTH: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = avg_depth; + *((unsigned int*) value) = stats.avg_depth; } else *((double *) value) = array_uint16_le (log + EMC_AVG_DEPTH) / 4 * FEET; @@ -106,7 +116,7 @@ cochran_emc_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, break; case DC_FIELD_SALINITY: // 0 = low conductivity, 2 = high, maybe there's a 1? - water->type = ( log[EMC_WATER_CONDUCTIVITY] == 0 ? DC_WATER_FRESH + water->type = ( (log[EMC_WATER_CONDUCTIVITY] & 0x3) == 0 ? DC_WATER_FRESH : DC_WATER_SALT ); water->density = 1000 + 12.5 * (log[EMC_WATER_CONDUCTIVITY] & 0x3); break; @@ -341,6 +351,7 @@ void cochran_emc_parse_dive_stats (dc_parser_t *abstract, stats->max_depth = 0; stats->min_temp = 999; stats->avg_depth = 0; + stats->max_temp = 0; while (offset < size) { s = sdata + offset; @@ -384,6 +395,7 @@ void cochran_emc_parse_dive_stats (dc_parser_t *abstract, temp = (temp - 32.0) / 1.8; if (temp < stats->min_temp) stats->min_temp = temp; + if (temp > stats->max_temp) stats->max_temp = temp; } time ++; -- 1.8.3.1

1 0

[PATCH] Fixed reference to DC_FAMILY_COCHRAN in universal.c
by John Van Ostrand 09 Nov '14

09 Nov '14

I'm not sure why this wasn't changed. Signed-off-by: John Van Ostrand <john(a)vanostrand.com> --- examples/universal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/universal.c b/examples/universal.c index 8672605..bb289b6 100644 --- a/examples/universal.c +++ b/examples/universal.c @@ -102,7 +102,7 @@ static const backend_table_t g_backends[] = { {"predator", DC_FAMILY_SHEARWATER_PREDATOR}, {"petrel", DC_FAMILY_SHEARWATER_PETREL}, {"nitekq", DC_FAMILY_DIVERITE_NITEKQ}, - {"cochran", DC_FAMILY_COCHRAN}, + {"cochran", DC_FAMILY_COCHRAN_COMMANDER}, }; static dc_family_t -- 1.8.3.1

1 0

small fix for Cobalt
by Dirk Hohndel 09 Nov '14

09 Nov '14

This seems like a fairly obvious fix, even though I don't have a Cobalt anymore to test it... /D

1 0

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