devel

devel@libdivecomputer.org

3 participants
290 discussions

[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

[PATCH 1/2] Corrected the sample start address for EMC 14 computers.
by John Van Ostrand 25 Dec '14

25 Dec '14

The emc14 sample memory start address had been set to 0x94000 and should be 0x20000. --- src/cochran_commander.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cochran_commander.c b/src/cochran_commander.c index 895c859..a1be22f 100644 --- a/src/cochran_commander.c +++ b/src/cochran_commander.c @@ -382,7 +382,7 @@ cochran_commander_get_config (const unsigned char *model, { conf->model = COCHRAN_MODEL_EMC_14; conf->log_size = 512; - conf->sample_memory_start_address = 0x94000; + conf->sample_memory_start_address = 0x20000; conf->dive_num_ptr = 0x56; conf->dive_count_ptr = 0xD2; conf->dive_count_endian = COCHRAN_LE_TYPE; -- 1.9.3

1 1

Re: C# and libdivecomputer
by Vincent de Vries 24 Dec '14

24 Dec '14

Hi Jef, I have been looking for a port of libdivecomputer for C#. I'm very interested in the wrapper you have created (or were working on), is there a location from where I can download it? In the ideal case I would like to port the entire library to C#, but for now that might be a bit ambitious. Thanks, Vincent

4 4

Re: [PATCH v2 12/15] Firmware upgrade for OSTC3
by Jef Driesen 22 Dec '14

22 Dec '14

On 2014-12-17 23:11, Anton Lundin wrote: > +dc_status_t > +hw_ostc3_device_fwupdate (dc_device_t *abstract, const char *filename) > +{ > + [...] > + > + // Make sure the device is in service mode > + if (device->state == OPEN) { > + rc = hw_ostc3_device_init_service(abstract); > + if (rc != DC_STATUS_SUCCESS) { > + free (firmware); > + return rc; > + } > + } else if (device->state != SERVICE) { > + free (firmware); > + return DC_STATUS_INVALIDARGS; > + } I've been playing with the idea of merging this functionality into the hw_ostc3_check_state_or_init() function. This is what I came up with: static dc_status_t hw_ostc3_device_init (hw_ostc3_device_t *device, hw_ostc3_state_t state) { dc_status_t rc = DC_STATUS_SUCCESS; if (device->state == state) { // No change. rc = DC_STATUS_SUCCESS; } else if (device->state == OPEN) { // Change to download/or service mode. if (state == DOWNLOAD) { rc = hw_ostc3_device_init_download(device); } else if (state == SERVICE) { rc = hw_ostc3_device_init_service(device); } else { rc = DC_STATUS_INVALIDARGS; } } else if (device->state == SERVICE && state == DOWNLOAD) { // Switching between service and download mode is not possible. // But in service mode, all download commands are supported too, // so there is no need to change the state. rc = DC_STATUS_SUCCESS; } else { // Not supported. rc = DC_STATUS_INVALIDARGS; } return rc; } What do you think? From my point of view, the main advantage is that all state changes are now done in a single function, where it's easy to see what kind of state transitions are allowed or not. > + // Programing done! > + progress.current++; > + device_event_emit (abstract, DC_EVENT_PROGRESS, &progress); > + > + // Finished! > + return DC_STATUS_SUCCESS; > +} There is a memory leak here. You forgot to free the firmware structure. PS: I have already implemented most of the improvements and bugfixes I mentioned in this and the 3 other emails. So there is no need to spend any time on them. If you're fine with those changes, just tell me, and I'll just squash them onto your commits. I fixed a few style issues too (e.g. whitespace, signed vs unsigned int, and dc_device_t vs hw_ostc3_device_t in function parameters). Jef

2 4

← Newer
1
...
14
15
16
17
18
19
20
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel