libdivecomputer does not return water temperature for uwatec aladin pro

Jef Driesen jef at libdivecomputer.org
Mon Jan 27 02:40:44 UTC 2014


On 2014-01-26 16:07, Dirk Hohndel wrote:
> On Sun, 2014-01-26 at 09:52 +0100, Jef Driesen wrote:
>> On 25-01-14 14:15, vavincavent wrote:
>> > I have try an other time to extract temperature from aladin pro.
>> > I've clone libdivecomputer :
>> >
>> > $ git clone git://git.libdivecomputer.org/libdivecomputer
>> > $ cd libdivecomputer
>> > $ git checkout release-0.4
>> > $ autoreconf --install
>> > $ ./configure --disable-shared
>> > $ make
>> > $ sudo make install
>> >
>> > I've clone subsurface :
>> >
>> > $ git clone git://subsurface.hohndel.org/subsurface.git
>> > $ cd subsurface
>> > $ qmake
>> > $ make
>> > $ sudo make install
>> >
>> > And the result is :
>>  >
>> > [screenshot omitted]
>> >
>> > anything about temperature...
>> > watec Aladin Pro register the minimal temperature for a dive.
>> 
>> As I explained in my previous email. Parsing the temperature in the 
>> dive header
>> isn't supported yet. That's something on my todo list. Currently only
>> temperature in the sample data is parsed, but your dive computer 
>> doesn't record
>> that.
> 
> But it's something that a motivated developer could add on the
> Subsurface side, isn't it? You do give us access to the raw data which
> we can use to extend things. We already do that for the tank 
> information
> stored in the header by the Atomics Aquatics Cobalt...
> 
> Look at libdivecomputer.c get_tanksize() if you are interested to go
> that route, vavincavent

It's probably a lot easier to implement this on the libdivecomputer 
side. You basically need to add a new DC_FIELD_TEMPERATURE to the enum, 
along with the necessary code in the backends.

It's not terrible difficult. The main reason why I kept my hands off 
doing it myself so far, is that to be really useful, it should be 
implemented for all backends. With about 20 parser backends (and many 
more due to device specific formats) that means quite some effort and 
time (reverse engineering, reading documentation, testing, etc). Since I 
already have plenty of work with bugfixing and maintenance, adding 
support for new devices, etc there is barely time left for new features.

But if someone is willing to put some effort in this, I'm happy to 
accept patches. Even if it's initially just for one or a few backends. I 
wouldn't even mind if the exact semantics aren't well defined at this 
point (e.g. Which temperature is this? Minimum, maximum, average or even 
something else?). Having something to start with is better than nothing. 
We can always improve along the way.

The same also applies for example to features like begin/end tank 
pressure. This are all features I would like to support anyway, and have 
been on my todo list for way too long already.

Jef


More information about the subsurface mailing list