On 2016-08-05 00:03, Thomas Gschwind wrote:

I am using Subsurface and it reports all my salt water dives deeper than they really are. So I downloaded the latest libdivecomputer sources and looked at the code. The tec2g_header claims that the salinity setting of this dive computer is not supported.

After looking at the dumps included in my SmartTRAK log where the dives are correctly reported (SmartTRAK is nice enough to store the original dc data), I am most certain to have located the salinity field in byte 62 of the header. Another indication is that it is also bit 0x10 as it is for the others (see get water in uwatec_smart_parser_cache).

Just tried out setting the salinity field to 62 and works perfectly fine for me.

Similarly, the timezone field most likely is 16. However, that one I cannot test so well because the immersion time seems to be relative to the dive computers system time which seems to be missing in the SmartTRAK logs. But manually looking at the time zones, it matched for the first 50+ of my dives.

I also figured out the max ppo2 configuration and partially the tissue saturation before the dive --- if anybody is interested that data as well. See http://tomsblog.gschwinds.net/2016/08/uwatec-smarttrak-and-aladin-tec2g/ for details.

Your investigation for the timezone and salinity fields appear correct to me. Will you submit a patch?

BTW, in your blog you write libdivecomputer "prefers to read the data from the dive computer itself", but parsing dives "offline" is fully supported too. Take a look at libdivecomputer's dctool application:

$ dctool help parse Parse previously downloaded dives

Usage: dctool parse [options] <filename>

Options: -h, --help Show help message -o, --output <filename> Output filename -d, --devtime <timestamp> Device time -s, --systime <timestamp> System time -u, --units <units> Set units (metric or imperial)

The "devtime" and "systime" options are there to synchronize the device and system (host) clocks. During a download libdivecomputer will get those two values, and take care of them internally. But when you intend to parse the dives at a later time, you should preserve those two values yourself. As you already discovered, smarttrak doesn't do that (it stores the parsed date/time, so it no longer need those two clock synchronization values). But there is no reason why you can't use the values of another download.

# Download the dives: dctool -l dctool-download.log -f smart download -f raw -o dive.%n.bin

# Get the clock synchronization values: grep -e systime -e devtime dctool-dowload.log

# Parse the dives (or the ones in your smarttrak database): dctool -l dctool-parse.log -f smart parse -d $DEVTIME -s $SYSTIME -o dctool.xml dive.%n.bin

Jef