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