devel October 2014

devel@libdivecomputer.org

10 participants
18 discussions

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

22 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

RFC: support for deco algorith and parameter fields
by Dirk Hohndel 17 Oct '14

17 Oct '14

Hi Jef, as "promised", here's another little feature that I frequently get asked about by some tech divers: show which algorithm / which paramters where used on a dive. There are quite a few dive computers for which we can return at least some viable data (I almost apologize for the last patch in the series... technically it is correct, and I think adding it makes it simpler for consumers of libdivecomputer to use this API). I'm calling this an RFC because I want feedback if this is the right API... this was straight forward to do, but I wonder if you would prefer a complex data structure and a single API entry point: DC_FIELD_DECO_INFO and struct dc_deco_information_t { unsigned int algo; unsigned int param1; /* e.g. GFhigh or GFS */ unsigned int param2; /* e.g. GFlow */ unsigned int param3; /* currently unused */ }; /D

5 9

Re: RFC: support for deco algorith and parameter fields
by Jef Driesen 17 Oct '14

17 Oct '14

On 2014-10-16 20:06, Dirk Hohndel wrote: > On Thu, Oct 16, 2014 at 03:43:11PM +0000, wrob311(a)gmail.com wrote: >> On Thu Oct 16 2014 16:09:06 GMT+0100 (IST), Jef Driesen wrote: >> [...] >> > >> > +typedef enum dc_deco_alg_t { >> > >> > I'm not really in love with the "deco_alg" abbreviation. But >> > "deco_algorithm" becomes pretty long. Maybe just "algorithm", or >> > "decomodel"? Other suggestions are welcome too. >> >> While 'algorithm' is used quite often, the 'model' is more correct, >> IMHO. Quite often a simple change to deco model parameters causes its >> name change i.e. ZHL-16B vs. ZHL-16C. Calling them two different >> algorithms does not make sense. > > Yeah, I like dc_deco_model_t I'm fine with that too. Thus to summarize we now have something like: DC_FIELD_DECO_MODEL DC_FIELD_DECO_PARAMS enum dc_deco_model_t { DC_DECO_MODEL_NONE, DC_DECO_MODEL_BUHLMANN, DC_DECO_MODEL_BUHLMANN_GF, DC_DECO_MODEL_VPM, DC_DECO_MODEL_VPM_GFS, DC_DECO_MODEL_DSAT, DC_DECO_MODEL_RGBM, }; struct dc_deco_params_gf_t { unsigned int low; unsigned int high; }; For the GF extension, we could also consider to re-use the base enum value (e.g. DC_DECO_MODEL_BUHLMANN), and then get the actual GF values through the params. For pure Buhlmann we can then return 100/100 as GF's. Then we don't need an explicit DC_DECO_MODEL_BUHLMANN_GF variant. Just an idea. >> > + DC_DECO_ALG_BZH, /* Buehlmann ZH, no GF */ >> > + DC_DECO_ALG_BZHGF, /* Buehlmann ZH, with GF */ >> > >> > The BZH name sounds a bit cryptic to me. How about naming it BUHLMANN >> > instead? >> >> If I am not mistaken Buhlmann was calling his models ZHL-XY, i.e. >> ZHL-16C. There are Buhlmann models with different number of tissue >> compatments than 16... > > I thought about that - but given how incredibly sloppy many of the > implementations are (often due to limited processing power), it seems > that > even if the vendor were to tell you exactly which model they use (as > some > do), there is very limited benefit in knowing that. More importantly, I > believe in most cases we don't know which exact model has been > implemented. Some don't even tell you if they use gradient factors (and > which ones). See my other email. >> > > DC_FIELD_DECO_INFO >> > > >> > > and >> > > >> > > struct dc_deco_information_t { >> > > unsigned int algo; >> > > unsigned int param1; /* e.g. GFhigh or GFS */ >> > > unsigned int param2; /* e.g. GFlow */ >> > > unsigned int param3; /* currently unused */ >> > > }; >> > >> > I'm not really sure what would be the best solution here. Are there any >> > other algorithms besides the GF that have parameters that make sense to >> > support? One concern is that with an integrated structure, we can't add >> > new parameters if that's ever necessary. I'm not really in love with >> > placeholder fields either. While with a separate DC_FIELD_DECOPARAMS >> > type, we can introduce different data structures for each deco >> > algorithm. For example: >> > >> > struct dc_decoparams_gf_t { >> > unsigned int low; /* e.g. GFhigh or GFS */ >> > unsigned int high; /* e.g. GFlow */ >> > }; >> >> You are basically opening a can of worms. :) Manufacturers like to add >> their own parameters it seems. Look at OSTC custom functions where >> ZHL-16C is extended with desaturation/saturation multipliers ( note: >> non-GF version). > > Both versions, I believe. > >> Also there are parameters which I find hard to classify. Is >> calculating >> your deco 1m deeper than you are part of deco model extension or a >> safety feature? And these are probably specific to a dive computer >> manufacturer. > > And most of those are not really well specified or documented. > > I get specific requests from tech divers to show the gradient factor > used > by their dive computer on specific dives - I think that's because > Subsurface shows the GF we use for our own deco calculations and people > want to be able to compare. I have not received any other requests for > paramters. I simply made this somewhat more generic when I saw in the > Shearwater documentation that they have the fused VPM-GSF where they > basically take the lower ceiling of VPM or Buehlmann with that > parameter > as surface GF (so basically GFhigh). Well, I think that we should stick to those parameters which are a defacto standard (like GF's), and ignore everything else. All highly manufacturer specific stuff is basically out of scope for libdivecomputer. At least that's my opinion. So we leave the can of worms closed :-) Jef

2 1

Oceanic / Aeris A300CS multipage patches
by Dirk Hohndel 16 Oct '14

16 Oct '14

Hi Jef, as discussed earlier today, here are patches that implement aligned multipage reads and mixed blocksize reads ONLY for dive computers that support 256 byte page reads. So far that appears to be only the A300CS but my guess is that we'll see more such dive computers in the future. This way we should get performant downloads from the A300CS without risking to break older dive computers. /D

2 4

first stab at Aeris A300CS support
by Dirk Hohndel 12 Oct '14

12 Oct '14

This implements fairly basic support for the A300CS - adds a cached reading function that supports transparent caching of 16 byte reads, implemented as 256 byte reads (I cannot get the A300CS to respond to the B1 command, but with B8 I can read 256 bytes; so I implemented a neat little caching layer that makes 16 byte reads available to the upper layers while in fact reading the larger pages that contain the 16 byte block and caching them for later use). - adds support for an oceanic_atom2 open function that gets passed the model information, since the A300CS needs us to toggle DTR and RTS twice before it's willing to talk to us. The old oceanic_atom2 open function remains unchanged in order not to break apps that might be using it directly (tsk, tsk, tsk, your're not supposed to...) - adds the necessary changes to the parser to deal with the different locations for various information; it supports the basics: date, time, duration, max depth, gasmixes plus depth, temperature and sensor pressure from the samples Missing / issues: - there is a TON more information available. Some I know where it is, but can't easily pass it back because of libdivecomputer architecture issues (e.g. the firmware version). Others are clearly there but I haven't figured out where (e.g. the deco state). - the 256 byte read uses a two byte crc and I haven't been able to figure out the algorithm. I'm sure it's obvious and I'm just being stupid, but for now the check is commented out This has been tested with Linus' new computer which has all of six dives on it - and those six dives are rather homogeneous. This needs a lot more testing, obviously. But so far so good - it works well from Subsurface :-) /D PS: Jef, I looked at the multiblock support. It adds more complexity for no benefit - so I decided not to add this to my patches. The reduced number of calls to the read function really makes no difference whatsoever, but the changes make the code more complex and (IMHO) more fragile. The caching read on the other hand is easy, straight forward, and reasonably obviously correct (famous last words).

2 24

[PATCH] Add wrappers to read and write Vyper settings
by Anton Lundin 10 Oct '14

10 Oct '14

This adds symbols that is exported from libdivecomputer for programs who would like to read and write settings. Signed-off-by: Anton Lundin <glance(a)acc.umu.se> --- include/libdivecomputer/suunto_vyper.h | 6 ++++++ src/libdivecomputer.symbols | 2 ++ src/suunto_vyper.c | 12 ++++++++++++ 3 files changed, 20 insertions(+) diff --git a/include/libdivecomputer/suunto_vyper.h b/include/libdivecomputer/suunto_vyper.h index a730b95..17f6814 100644 --- a/include/libdivecomputer/suunto_vyper.h +++ b/include/libdivecomputer/suunto_vyper.h @@ -42,6 +42,12 @@ suunto_vyper_extract_dives (dc_device_t *device, const unsigned char data[], uns dc_status_t suunto_vyper_parser_create (dc_parser_t **parser, dc_context_t *context); +dc_status_t +suunto_vyper_device_config_read(dc_device_t *abstract, unsigned int config, unsigned char data[], unsigned int size); + +dc_status_t +suunto_vyper_device_config_write(dc_device_t *abstract, unsigned int config, const unsigned char data[], unsigned int size); + #ifdef __cplusplus } #endif /* __cplusplus */ diff --git a/src/libdivecomputer.symbols b/src/libdivecomputer.symbols index 14a96a8..cf902cc 100644 --- a/src/libdivecomputer.symbols +++ b/src/libdivecomputer.symbols @@ -50,6 +50,8 @@ reefnet_sensusultra_parser_set_calibration uwatec_memomouse_parser_create uwatec_smart_parser_create suunto_vyper_parser_create +suunto_vyper_device_config_read +suunto_vyper_device_config_write suunto_solution_parser_create suunto_eon_parser_create suunto_d9_parser_create diff --git a/src/suunto_vyper.c b/src/suunto_vyper.c index b259259..09c7a14 100644 --- a/src/suunto_vyper.c +++ b/src/suunto_vyper.c @@ -570,3 +570,15 @@ suunto_vyper_extract_dives (dc_device_t *abstract, const unsigned char data[], u return suunto_common_extract_dives (device, layout, data, callback, userdata); } + +dc_status_t +suunto_vyper_device_config_read(dc_device_t *abstract, unsigned int config, unsigned char data[], unsigned int size) +{ + return suunto_vyper_device_read(abstract, config, data, size); +} + +dc_status_t +suunto_vyper_device_config_write(dc_device_t *abstract, unsigned int config, const unsigned char data[], unsigned int size) +{ + return suunto_vyper_device_write(abstract, config, data, size); +} -- 1.9.1

2 2

Puck 2 download error
by Richard Fuchs 02 Oct '14

02 Oct '14

Hey guys, I have a Mares Puck (Puck 2 model) that I've previously successfully downloaded dives from, in fact I downloaded dives just a few days ago. But downloading the most recent dives fails with the following error at the very end: Event: model=31 (0x0000001f), firmware=0 (0x00000000), serial=102663 (0x00019107) ERROR: Calculated and stored size are not equal. [in mares_iconhd.c:519 (mares_iconhd_extract_dives)] And no dives come across. Is there anything I can do to fix this? cheers

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel October 2014