- devel - libdivecomputer.org

Mares Nemo via IRIS (RS232)
by Stefano Mersi 06 Jan '15

06 Jan '15

Hello, I have a Mares Nemo and an IRIS RS232 interface. If anyone is interested in helping the debug here, I thank them in advance. More detailed info follow. I have tried to download all the dives from my Mares Nemo via the IRIS interface (the old one, which connects through RS232). It apparently did not work using subsurface, so I rolled back to the debug tools in libdivecomputer, following the instructions to obtain all the needed info. The download with the 'universal' test went smoothly from 0% to 100%, but I get periodic warnings: "[6.324485] WARNING: Only the first packet has a correct checksum. [in mares_nemo.c:257 (mares_nemo_device_dump)]" every ~ 100 packets). If anyone is interested in looking into this, I attach all the debug info. Thanks in advance Stefano

2 1

Re: Switch to msvc 12 (VS 2013) and stop jumping hoops?
by Jef Driesen 06 Jan '15

06 Jan '15

On 30-12-14 18:56, Anton Lundin wrote: > I know that Jef cares about msvc compatibility, and thus we are jumping > hoops to try to keep libdivecomputer building with old msvc versions. > > As far as i read from the project file, its targeting msvc 9.0 aka > VS 2008 which is quite old. I just had a chat with some friends of mine > who works (fights) with VS on a daily basis, and according to them VS > 2013 works quite fine, and is a pretty standard compliant c99 compiler. > > > Is it intentionally libdivecomputer is targeting msvc 9.0 or can we > bump > that version to msvc 12.0 and stop (at least to lesser degree) jumping > hoops for msvc support? The reason why I'm using msvc 9 is because that was the current version back than and freely available (express edition). I certainly don't mind switching to a newer version if they have better C99 support. The only requirement on my side is that it needs to run on Windows XP, and that might be a problem. I'm well aware that Windows XP is discontinued, but that's what I'm currently running in my Windows VM's. Portmon and some (older) manufacturer applications work fine there. I'm not sure whether that's still true for more recent windows version. So I'm a bit stuck with Windows XP for that reason. Jef

1 0

[PATCH] Add EON Steel gas change event parsing
by Linus Torvalds 04 Jan '15

04 Jan '15

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Fri, 2 Jan 2015 22:23:40 -0800 Subject: [PATCH] Add EON Steel gas change event parsing The really sad part is that the EON Steel handles gas change events correctly, by actually saying which cylinder it switches to. But the libdivecomputer interfaces are broken, and only contain the gas *mix* you switch to, which is ambiguous since you could have the same mix in multiple cylinders. Maybe we could put the one-based cylinder index into the "flags" field? With zero meaning "unknown". That would be a straightforward extension. Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- It's really sad how this loses the cylinder number information, but other than that it seems to work for me. There's a lot of other events that I don't parse, and that I now have that Don took the EON Steel down to 200 ft with trimix and sharks, but this is the primary missing one. src/suunto_eonsteel_parser.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index 6c4f4aba3d39..d5bfb0e74942 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -291,6 +291,25 @@ static void sample_cylinder_pressure(struct sample_data *info, unsigned char idx if (info->callback) info->callback(DC_SAMPLE_PRESSURE, sample, info->userdata); } +static void sample_gas_switch_event(struct sample_data *info, unsigned short idx) +{ + suunto_eonsteel_parser_t *eon = info->eon; + dc_sample_value_t sample = {0}; + int o2, he; + + if (idx < 1 || idx > eon->cache.ngases) + return; + + // Horrible, broken, gas change events + o2 = 100 * eon->cache.gasmix[idx-1].oxygen; + he = 100 * eon->cache.gasmix[idx-1].helium; + + sample.event.type = SAMPLE_EVENT_GASCHANGE2; + sample.event.value = o2 | (he << 16); + + if (info->callback) info->callback(DC_SAMPLE_EVENT, sample, info->userdata); +} + static int traverse_samples(unsigned short type, const struct type_desc *desc, const unsigned char *data, int len, void *user) { struct sample_data *info = (struct sample_data *) user; @@ -311,6 +330,9 @@ static int traverse_samples(unsigned short type, const struct type_desc *desc, c case 0x000a: // cylinder idx in first byte, pressure in next word sample_cylinder_pressure(info, data[0], array_uint16_le(data+1)); break; + case 0x001d: + sample_gas_switch_event(info, array_uint16_le(data)); + break; } return 0; } -- 2.2.1.212.gc5b9256

3 3

[PATCH] Extend SAMPLE_EVENT_GASCHANGE2 to have cylinder index in 'flags' field
by Linus Torvalds 04 Jan '15

04 Jan '15

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sat, 3 Jan 2015 17:21:05 -0800 Subject: [PATCH] Extend SAMPLE_EVENT_GASCHANGE2 to have cylinder index in 'flags' field A value of zero (which is the normal legacy one) remains "unknown", but the divecomputer backend can now give both gasmix and cylinder number this way. Currently only the EON Steel backend does that, but it should be easy enough to extend others too. Also, fix the user-visible cylinder numbering in the cylinder change tooltip to use a human-friendlier one-based numbering (ie first cylinder is "cyl 1", not "cyl 0") Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- This is the subsurface side to take advantage of the gas index in the "flags" field of SAMPLE_EVENT_GASCHANGE2. The main downside is that nobody historically looked at the "flag" field before, it is possible that some libdivecomputer backend doesn't fill it with zero. But a quick check seems to imply that all backends properly clear it (most with an explicit "flag = 0" right around that SAMPLE_EVENT_GASCHANGE2, and the Suunto D9 parser that doesn't do that has a dc_sample_value_t sample = {0}; to initialize the whole sample with zero, so it all looks fine. NOTE! In subsurface itself, when we then *save* the data, it looks like we don't save a cylinder index of 0 in the git save state. So we lose the explicit cylinder value for the first cylinder. I'll take a look at that later, but it's independent of this particular patch. It's also not clear that subsurface should necessarily bother to save the cylinder index at all if it's unambiguous and can be calculated from the gas mix. None of this code has really gotten much testing, since the whole "explicit cylinder index" is all new, and basically nobody has data with it (since libdivecomputer imports haven't had the data). The fact that we showed the cylinder index zero-based in the newly added tooltip text is very much an example of that kind of lack of data leading to lack of test coverage. This fixes that too (we internally number our gas indexes from 0..7 because they are C array indexes, and "unknown" is thus -1. But obviously from a human readability we should call the first cylinder "cyl 1" rather than "cyl 0". Ho humm. We probably have tons of small issues like this in this area. dive.c | 7 ++++++- qt-ui/profile/diveeventitem.cpp | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/dive.c b/dive.c index 32ac25e2ae83..711392c5adc1 100644 --- a/dive.c +++ b/dive.c @@ -57,6 +57,7 @@ int event_gasmix_redundant(struct event *ev) struct event *add_event(struct divecomputer *dc, int time, int type, int flags, int value, const char *name) { + int gas_index = -1; struct event *ev, **p; unsigned int size, len = strlen(name); @@ -79,11 +80,15 @@ struct event *add_event(struct divecomputer *dc, int time, int type, int flags, case SAMPLE_EVENT_GASCHANGE2: /* High 16 bits are He percentage */ ev->gas.mix.he.permille = (value >> 16) * 10; + + /* Extension to the GASCHANGE2 format: cylinder index in 'flags' */ + if (flags > 0 && flags <= MAX_CYLINDERS) + gas_index = flags-1; /* Fallthrough */ case SAMPLE_EVENT_GASCHANGE: /* Low 16 bits are O2 percentage */ ev->gas.mix.o2.permille = (value & 0xffff) * 10; - ev->gas.index = -1; + ev->gas.index = gas_index; break; } diff --git a/qt-ui/profile/diveeventitem.cpp b/qt-ui/profile/diveeventitem.cpp index 4294dfb29589..1a5e29dda1ee 100644 --- a/qt-ui/profile/diveeventitem.cpp +++ b/qt-ui/profile/diveeventitem.cpp @@ -106,7 +106,7 @@ void DiveEventItem::setupToolTipString() /* Do we have an explicit cylinder index? Show it. */ if (internalEvent->gas.index >= 0) - name += QString(" (cyl %1)").arg(internalEvent->gas.index); + name += QString(" (cyl %1)").arg(internalEvent->gas.index+1); } else if (type == SAMPLE_EVENT_PO2 && name == "SP change") { name += QString(":%1").arg((double)value / 1000); } else { -- 2.2.1.212.gc5b9256

1 0

[PATCH 2/2] EON Steel: expose the gas switch cylinder in the "flags" field
by Linus Torvalds 04 Jan '15

04 Jan '15

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sat, 3 Jan 2015 17:09:45 -0800 Subject: [PATCH 2/2] EON Steel: expose the gas switch cylinder in the "flags" field This seems to be the simplest extension to the SAMPLE_EVENT_GASCHANGE2 format: the "value" remains the oddly encoded gas mix, but the "flags" value (if non-zero) now contains the actual cylinder number we switch to. This will need a trivial patch to subsurface to take advantage of the new data too. But then we can actually distinguish between cylinders that have the same gas mix. Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- Hey, it sure is simple. src/suunto_eonsteel_parser.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index 6296b2642ba0..40e3feb02a35 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -325,6 +325,7 @@ static void sample_gas_switch_event(struct sample_data *info, unsigned short idx sample.event.type = SAMPLE_EVENT_GASCHANGE2; sample.event.value = o2 | (he << 16); + sample.event.flags = idx; if (info->callback) info->callback(DC_SAMPLE_EVENT, sample, info->userdata); } -- 2.2.1.212.gc5b9256

1 0

[PATCH 1/2] Add EON Steel personal adjustment parsing
by Linus Torvalds 04 Jan '15

04 Jan '15

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sat, 3 Jan 2015 17:07:38 -0800 Subject: [PATCH 1/2] Add EON Steel personal adjustment parsing Suunto calls it "Conservatism" in the dump, but "Personal adjustment" in at least some of the documentation. That's what we expose it as. Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- So a "Personal adjustment" of "P-2" looks a bit odd, but that's how Suunto shows it on the dive computer (with the explanation "More aggressive"), and it matches older Suunto computers that called their personal adjustments P0 .. P2. src/suunto_eonsteel_parser.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index d5fe9f8ca7f2..6296b2642ba0 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -21,6 +21,12 @@ #include <stdlib.h> #include <string.h> +#include <stdio.h> + +/* Wow. MSC is truly crap */ +#ifdef _MSC_VER +#define snprintf _snprintf +#endif #include <libdivecomputer/suunto_eonsteel.h> @@ -756,6 +762,15 @@ static int traverse_header_fields(suunto_eonsteel_parser_t *eon, const char *nam if (!strcmp(name, "Diving.DiveMode")) return add_string(eon, "Dive Mode", data); + /* Signed byte of conservatism (-2 .. +2) */ + if (!strcmp(name, "Diving.Conservatism")) { + char buffer[10]; + int val = *(signed char *)data; + + snprintf(buffer, sizeof(buffer), "P%d", val); + return add_string(eon, "Personal Adjustment", buffer); + } + return 0; } -- 2.2.1.212.gc5b9256

1 0

[PATCH 3/3] Parse EON Steel notification and state changes
by Linus Torvalds 03 Jan '15

03 Jan '15

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sat, 3 Jan 2015 15:23:35 -0800 Subject: [PATCH 3/3] Parse EON Steel notification and state changes The EON Steel notifications and states match the libdivecomputer ones very badly, but this tries to make sense of the ones that match. And puts the infrastructure in to do others in the future. Signed-off-by: Linus Torvalds <torvalds(a)linux-fouindation.org> --- I'll double-check, but I think this ends up finishiong off the obviously useful parts of the EON Steel information. There are more things that the EON Steel reports, but they tend to be pretty esoteric. src/suunto_eonsteel_parser.c | 89 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index 368769675e0f..a31c1a7e9b68 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -228,6 +228,7 @@ struct sample_data { dc_sample_callback_t callback; void *userdata; unsigned int time; + unsigned char state_type, notify_type; }; static void sample_time(struct sample_data *info, unsigned short time_delta) @@ -310,6 +311,82 @@ static void sample_gas_switch_event(struct sample_data *info, unsigned short idx if (info->callback) info->callback(DC_SAMPLE_EVENT, sample, info->userdata); } +/* + * The EON Steel has two different sample events: "state" and "notification". + * Both end up having two fields: type and a boolean value. + * + * The type enumerations are available as part of the type descriptor, and we + * *should* probably parse them dynamically, but this hardcodes the different + * type values. + * + * For event states, the types are: + * + * 0=Wet Outside + * 1=Below Wet Activation Depth + * 2=Below Surface + * 3=Dive Active + * 4=Surface Calculation + * 5=Tank pressure available + */ +static void sample_event_state_type(struct sample_data *info, unsigned char type) +{ + info->state_type = type; +} + +static void sample_event_state_value(struct sample_data *info, unsigned char value) +{ + /* + * We could turn these into sample events, but they don't actually + * match any libdivecomputer events. + * + * unsigned int state = info->state_type; + * dc_sample_value_t sample = {0}; + * sample.event.type = ... + * sample.event.value = value; + * if (info->callback) info->callback(DC_SAMPLE_EVENT, sample, info->userdata); + */ +} + +static void sample_event_notify_type(struct sample_data *info, unsigned char type) +{ + info->notify_type = type; +} + + +static void sample_event_notify_value(struct sample_data *info, unsigned char value) +{ + dc_sample_value_t sample = {0}; + static const enum parser_sample_event_t translate_notification[] = { + SAMPLE_EVENT_NONE, // 0=NoFly Time + SAMPLE_EVENT_NONE, // 1=Depth + SAMPLE_EVENT_NONE, // 2=Surface Time + SAMPLE_EVENT_TISSUELEVEL, // 3=Tissue Level + SAMPLE_EVENT_NONE, // 4=Deco + SAMPLE_EVENT_NONE, // 5=Deco Window + SAMPLE_EVENT_SAFETYSTOP_MANDATORY, // 6=Safety Stop Ahead + SAMPLE_EVENT_SAFETYSTOP, // 7=Safety Stop + SAMPLE_EVENT_CEILING_SAFETYSTOP, // 8=Safety Stop Broken + SAMPLE_EVENT_NONE, // 9=Deep Stop Ahead + SAMPLE_EVENT_DEEPSTOP, // 10=Deep Stop + SAMPLE_EVENT_DIVETIME, // 11=Dive Time + SAMPLE_EVENT_NONE, // 12=Gas Available + SAMPLE_EVENT_NONE, // 13=SetPoint Switch + SAMPLE_EVENT_NONE, // 14=Diluent Hypoxia + SAMPLE_EVENT_NONE, // 15=Tank Pressure + }; + + if (info->notify_type > 15) + return; + + sample.event.type = translate_notification[info->notify_type]; + if (sample.event.type == SAMPLE_EVENT_NONE) + return; + + sample.event.value = value ? SAMPLE_FLAGS_BEGIN : SAMPLE_FLAGS_END; + if (info->callback) info->callback(DC_SAMPLE_EVENT, sample, info->userdata); +} + + static int traverse_samples(unsigned short type, const struct type_desc *desc, const unsigned char *data, int len, void *user) { struct sample_data *info = (struct sample_data *) user; @@ -330,6 +407,18 @@ static int traverse_samples(unsigned short type, const struct type_desc *desc, c case 0x000a: // cylinder idx in first byte, pressure in next word sample_cylinder_pressure(info, data[0], array_uint16_le(data+1)); break; + case 0x0013: + sample_event_state_type(info, data[0]); + break; + case 0x0014: + sample_event_state_value(info, data[0]); + break; + case 0x0015: + sample_event_notify_type(info, data[0]); + break; + case 0x0016: + sample_event_notify_value(info, data[0]); + break; case 0x001d: sample_gas_switch_event(info, array_uint16_le(data)); break; -- 2.2.1.212.gc5b9256

1 0

[PATCH 2/3] Add EON Steel dive mode and transmitter ID information
by Linus Torvalds 03 Jan '15

03 Jan '15

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sat, 3 Jan 2015 14:43:46 -0800 Subject: [PATCH 2/3] Add EON Steel dive mode and transmitter ID information This adds the divemode name (Nitrox, Trimix, Gauge, or whatever custon name) and the transmitter ID as extra string information when downloading from the EON Steel. Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- Patch 1/3 was the "Add EON Steel gas change event parsing" patch I sent yesterday, but it hasn't changed and I'm not resending it here, so if you wonder why you only get 2/3 and 3/3, that's why. Holler if you don't see yesterday's patch, and I'll send that one too. src/suunto_eonsteel_parser.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index d5bfb0e74942..368769675e0f 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -569,6 +569,9 @@ static int traverse_header_fields(suunto_eonsteel_parser_t *eon, const char *nam if (!strcmp(name, "Diving.Algorithm")) return add_string(eon, "Deco algorithm", data); + if (!strcmp(name, "Diving.DiveMode")) + return add_string(eon, "Dive Mode", data); + return 0; } @@ -614,6 +617,9 @@ static int traverse_fields(unsigned short type, const struct type_desc *desc, co case 0x000f: // Helium percentage in first byte add_gas_he(eon, data[0]); break; + case 0x0011: // Transmitter ID + add_string(eon, "Transmitter ID", data); + break; default: // The types with the high byte set seem to be dynamic // although not all of them seem to change. But let's -- 2.2.1.212.gc5b9256

1 0

Switch to msvc 12 (VS 2013) and stop jumping hoops?
by Anton Lundin 30 Dec '14

30 Dec '14

Hi. I know that Jef cares about msvc compatibility, and thus we are jumping hoops to try to keep libdivecomputer building with old msvc versions. As far as i read from the project file, its targeting msvc 9.0 aka VS 2008 which is quite old. I just had a chat with some friends of mine who works (fights) with VS on a daily basis, and according to them VS 2013 works quite fine, and is a pretty standard compliant c99 compiler. Is it intentionally libdivecomputer is targeting msvc 9.0 or can we bump that version to msvc 12.0 and stop (at least to lesser degree) jumping hoops for msvc support? //Anton -- Anton Lundin +46702-161604

1 0

Re: [PATCH] Cochran_commander refactoring
by John Van Ostrand 30 Dec '14

30 Dec '14

On Mon, Dec 22, 2014 at 2:48 PM, Jef Driesen <jef(a)libdivecomputer.org> wrote: > On 22-12-14 20:33, John Van Ostrand wrote: > >> On Mon, Dec 22, 2014 at 10:38 AM, Jef Driesen <jef(a)libdivecomputer.org> >> wrote: >> >> On 19-12-14 21:23, John Van Ostrand wrote: >>> >>> I did more investigating of setting commands and encoding. I've updated >>>> the >>>> trac wiki with the full information. It should be complete but it's not >>>> tested or strongly verified. There may be mistakes. >>>> >>>> I did some testing today reading raw data to see if I could download a >>>> usable memory dump for the dump function and avoid all that work done in >>>> _dump and eliminate the need for cochran_download.c. >>>> >>>> The read command (0x15 <start> <bytes> 0x05) only reads logbook and >>>> sample >>>> data. I suspected that the gap between logbook and sample contained >>>> config >>>> or other data but that isn't the case. There is no gap between Commander >>>> logbook and samples and the EMC has no data of significance there. >>>> >>>> Also, when asked to read past the end of data on the Commander, It >>>> returns >>>> 0xFF for data that doesn't seem to be there. For example, the Commander >>>> I >>>> have has rolled the sample data buffer so all the memory has been >>>> written. >>>> Sample data stops at 0x100000 (1MB). When I asked for 8MB of data I got >>>> 7MB >>>> of 0xFF. >>>> >>>> Unless i discover a new command to read data I won't be able to deliver >>>> a >>>> raw memory dump. >>>> >>>> I'm also no closer to deciphering the feature data from the computer so >>>> I >>>> don't know how much memory is present and enabled. >>>> >>>> >>> I'm not sure I'm understand what you're saying here. First you say you >>> can >>> download 1MB of data. But then you say you can't download a memory dump? >>> I >>> don't know what you consider a memory dump, but I would say it's that 1MB >>> of data! Combined with the id, misc and config blobs that has everything >>> we >>> need. I have no idea what else you want. >>> >>> >> What I meant was that I could not produce a contiguous segment of memory >> that contained everything, which seemed to be what you thought would be >> ideal for _dump(). >> > > Now I'm even more confused. If I'm right, then for the commander the > logbook ringbuffer is from address 0x0 to 0x20000. And the profile > ringbuffer is from address 0x20000 to 0x100000. So that's one continuous > block of 1M in size. That would be perfect for a memory dump. > > Am I missing something here? > When I say "everything" I mean info, config and misc data too. That can't be read the same way log and sample data is. > > PS: Can you send me the data from your Commander too. If you have data >>> from the other models, I would like to have a look at that too. >>> >>> >> I'll send a separate email. >> > > Thanks. > > If you're interested in the source code for my libdivecomputer simulator, > then let me know and I'll package it for you. > > I would be interested. > Is it possible to install the Analyst software on my side, and make it > talk to the simulator, or load the corresponding CAN files? That would help > a lot. But I can only find a demo version, which seems to have the > communication disabled The software is an extra charge (with cable) and I recall but it seemed to call home to authorize or log an activation. Do you want screen dumps? I can also run a USB log and export to CSV. The file would include lots of collateral data but it's parseable. The CAN files are weaklly encrypted and I finished and submitted the Subsurface code to read CAN files. The CAN file contains log entries followed by the dive sample data in raw format. Since the addresses in the log don't apply to the relocated sample data my code uses something similar to corrupt dive parsing. -- John Van Ostrand At large on sabbatical

2 1