devel

devel@libdivecomputer.org

3 participants
290 discussions

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 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

← Newer
1
...
17
18
19
20
21
22
23
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel