uwatec time format suggestion

[Jef Driesen]

On 12/23/2011 07:08 PM, Kurt wrote:
> By way of introduction I will say that I have been writing Aladin readers and
> logs for my own use since the prior century. I still have a working Palm
> Pilot and home made cable.  Alas, the Palm platform and SDK changed too
> frequently to make publishing worthwhile.  I also wrote my own reader for the
> Smart and was quite excited/disappointed to see that you got  no further
> decoding Smart Com/Pro than I did. (c:

If you explain in more detail why you are disappointed with the decoding, we can 
maybe fix it?

As far as I am aware most of the important information (eg. maxdepth, divetime, 
profile data, etc) is available. Of course there is room for improvement, but 
please note that one of our main goals is to provide a common interface for all 
supported devices. The consequence is that we can't support every single piece 
of information that a particular device supports. That's the compromise I have 
to make because there is simply too much difference between all those devices 
out there.

The idea is that you should be able to build a generic application that's not 
tied to a specific type of device. If you intend to create an application for 
just a single device, then you can still use the libdivecomputer library, but 
you'll have to do some of the decoding manually.

> I don't know why, but everyone since time immemorial has wanted to complicate
> the calculation of Uwatec time by attempting to attach it to an epoch. It
> changes from model to model and becomes problematic with battery changes and
> other malfunctions, though it will will seem to work most of the time.
>
> I believe this  is the wrong approach.
>
> The Aladin computers since the days of MemoMouse have utilized a 500 ms
> counter (2 tics/second). It is not attached to any particular epoch though it
> may appear that way since the factory has to initialize the counter with
> _something_.  However, battery changes and other vagaries may change that.
>
> Each dive has a four byte tic count (UInt32)
>
> Each *download* also specifies the tic count at the time of download in the
> old MemoMouse, or you explicitly retrieve the Dive Computer Time (in tics) as
> outlined in the Uwatec Smart protocol page.
>
> The difference between the two divided by two: (
> DiveComputerTimeInTics-DiveTimeInTics )>>  1 is the total number of seconds
> since the dive began.
>
> This is perfectly clean number that is completely independent of epoch,
> timezone or platform.
>
> It is also independent of Aladin platform, be it plain, Nitrox, ultra, tech
> or smart. You don't need any +/- 1800 adjusters magic numbers or anything of
> that sort.
>
> The introduction of epochs and timezone adjustments are then left to the
> implementor and platform as they should be.
>
> This also generally reduces time errors since the difference between ticsnow
> and ticsthen, is much smaller quantity of tics to be operated on and time
> interpretation accuracy will depend on the host computer time source instead
> of the dive computer.

I have no idea why you bring this up, because the method you explain is exactly 
what we are using in the libdivecomputer library. Have you actually looked at 
the source code? It reads:

ticks = parser->systime - (parser->devtime - timestamp) / 2;

Note that there is some complication because some Uwatec Smart/Galileo models 
have a timezone setting. But I haven't figured out yet how it's really used. 
Smarttrak does something weird with it.

Jef