- devel - libdivecomputer.org

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

Can't connect with Pro Plus 2 on Fedora 20
by John Williams 30 Sep '14

30 Sep '14

Hi, Firstly, thanks for your work on this very useful software! But, I've tried using the vtpro and universal clients to connect to my Pro Plus 2 on Fedora 20, but get the undesirable response below. I've followed the instructions to execute: modprobe ftdi_sio vendor=0x0403 product=0xF460 and also put options ftdi_sio vendor=0x0403 product=0xF460 in /etc/modprobe.d/options The device is owned by root, and has group dialout. My non-root user (john) belongs to this group. Is there anything else I can do to track down the cause of this error? (And yes, my Pro Plus 2 displays "PC" and executes the 120 second countdown.) Thanks again, John ============================================================ [john@lounge Downloads]$ ./universal -b vtpro /dev/ttyUSB0 DATETIME 2014-09-30T07:34:17Z (1412062457) VERSION 0.5.0-devel (6845d9b77c81185a50a855c73a9c9f7989ad434c) Opening the device (Oceanic Versa Pro, /dev/ttyUSB0). ERROR: Failed to receive the answer. [in ../../source/src/oceanic_vtpro.c:189 (oceanic_vtpro_init)] ../../source/examples/universal.c:681: Error opening device. Result: Timeout

2 1

[PATCH] Added support for parsing temperature in the dive header
by Calle Gunnarsson 25 Sep '14

25 Sep '14

And implemented this for Cressi Leonardo, see the attached patches. //Calle

10 37

[ALADIN SQUARE]
by vavincavent 22 Sep '14

22 Sep '14

Hi, I will send all informations i can have for helping in Scubapro Aladin Square transfert by libdivecomputer. http://www.scubapro.com/en-US/USA/instruments/computers/products/aladin-squ… I am with Ubuntu OS I have virtualbox with windows installed and Scubapro LogTRAK program installed. I can transfert from and to Aladin Square with LogTRAK. I have USBpcap (sniffer USB) installed (http://desowin.org/usbpcap/index.html) and i can capture to make ".pcap" files With Ubuntu, i have Wireshark installed, so i can open ".pcap" files. I think we need hidapi to work with (http://www.signal11.us/oss/hidapi/) I try and have connected my Aladin Square with hidapi test program. That's what i have to test. I'm not a programmer, but i can compile and use libdivecomputer with Subsurface. Who can help me and the world to make it possible to transfert ALADIN SQUARE data with libdivecomputer? Jef doesn't have enougth time and need help for this. Vavincavent

1 1