Atmos ai Dec 31, 2009 Problem

[derouyag]

There we are, in Nanaimo, BC doing the longest dive of the year. We go in the water at 11:45 pm Dec 31 and get out of the water in the New Year.

I went back home with my two computers; Atmos ai and the XR2. I dove both computers for the entire trip. I tried to download the dives from my primary computer; the Atmos ai. I never checked the last dive date, but downloaded blindly. This was a big mistake... all of my dives went out of synch... what a mess.

I am a systems analyst/programmer. I proceeded to analyze the problem. I even got into the Microsoft Access (dlg) file to check the raw files. Sure enough I spotted a problem...

I erased ALL of my records; fortunately only 14 old ones. Started the download process for the new 8 dives to find that the Atmos ai shows the last dive to be done on Dec 31, 2000. The second last dve was done on Dec 31, 2009. Ouch! There is a really big problem.

Well then... let's check the XR2. I erased all of the records again because you can't download the same dive info from two computers into the software. Started the download for the XR2 and found that the XR2 handles this problem properly. Dive 8 shows Dec 31, 2009!

Atmos ai firmware is 2a
XR2 firmware is 1a

So the big question is... Is the Atmos ai capable of handling 2010 records? Or is this just an anomoly of diving on New Year's Eve?

I bought 2 Atmos ai's about a year ago. This is obviously a manufacturing software issue.

I sent emails today to AERIS. I hope to get a response within the next week and resolved quickly there after. I will post updates as they become available.

 

[kvp]

I had the same type of problem with my Epic.

I did a dive on 12/31 and it imported as 2009. Then I did a dive on 1/1 and it imported as 2000. 3 more dives on 1/2, still 2000. 3 more on 1/3, still 2000.

THere must be a bug in their download software as my computer is showing the correct 2010 date.

Ken

 

[derouyag]

From what I have looked into and tested, I figure this will be a firmware issue. They might be able to tweak the software to handle it for specific computers. Strange how the XR2 handles it correctly.

I wonder if Oceanic computers have a similar problem?

 

[gbirch]

Derouyag,
I don't think that this is a boundary condition caused by you diving as the calendar turned to the new decade. I did a New Year's Day dive with my Atmos AI and when I downloaded it, it came in as a January 2000 dive. In fact, on the download software it lists the dives as 01/01/00. I too am in software dvelopment... it looks like they have a bug

 

[derouyag]

I read a few other posts in the Oceanic threads as well. It seems this is going to be a Y10k bug. My understanding is that the year field comes across as a single digit (according to one post). If that is the case, the programmers never thought to check the year of the computer downloading the dives. This might have helped them figure out what year is really being downloaded.

I presume this is a waiting game now... for new software update or a computer recall. (Computer recall... not bloody likely but good for a chuckle.)

 

[bperrybap]

I read a few other posts in the Oceanic threads as well. It seems this is going to be a Y10k bug. My understanding is that the year field comes across as a single digit (according to one post). If that is the case, the programmers never thought to check the year of the computer downloading the dives. This might have helped them figure out what year is really being downloaded.

I presume this is a waiting game now... for new software update or a computer recall. (Computer recall... not bloody likely but good for a chuckle.)

The computer itself is actually tracking the full year internally (up to 2039 anyway), and this year issue doesn't affect the use or capabilities of the computer while diving.
It is only an issue for downloading, so I doubt that this would necessitate a recall.

There are 2 "logbooks" stored internally. One that is used for the history function and one that is use for downloading to the host PC. The on board history logbook function should be reporting the year correctly.

So it is actually more complicated than simply not providing the 10s digit of the year.
The start date/time of a dive (which includes the year) is tracked and stored in multiple locations and in different formats.

While most of the Pelagic models store the download dive summary information in their internal memory in a very similar format, it is not stored exactly the same way across all the models.

The download dive summary information is what Oceanlog/ACI reads and uses to post the initial dialog to determine the date/time information for downloading.
It contains only basic dive information such as date/time, repetitive dive #, and the memory locations for where the profile data starts and ends.

Some DC models do not store the 10's digit in the download dive summary information and some do. Some store the 10's digit in the dive summary information but the current host software does not interpret it correctly on certain year boundaries. 2010 being one of the "interesting" year boundaries. (there are other "interesting" year boundaries)

On the DC models that do store the 10's digit in the dive summary, it should be an easy fix to update the host software to correctly grab the additional year information.

For the models that don't store anything but the lower year digit in the dive summary, the workaround/update/fix is not so easy.

There is no "simple" test for the year that can be done as the product lifespan for a dive computer can be over 10 years. By product lifespan I mean from the time the product is introduced until nobody ever uses that model ever again.
Given this, there is no simple way to compare the lower year digit the Dive computer gives in its download dive summary against the current year in the host PC and determine much of anything if all you have is the lower digit of the year.
You can't add 2000 to the digit then you get 2000 instead of 2010.
Roll the clock ahead 4-5 years to the year 2015 and do download.
If the host software were to see a year digit of 5 would that be a dive from 2005 or 2015?
And you can't just assume it is the same as the current 10s digit on the PC otherwise you end up with a a dive done in 2009 showing up as a being done in 2019.
Yes there is a tricky method that can be used to correctly "guess" a decade if you assume a diver uses his dive computer at least once per decade.
I spent quite a bit of time on this when I was writing my own downloader software and you can "guess" correctly nearly all the time.

Eventually I was able to determine that the year information was available elsewhere.
So luckily, on the few models I've played with that don't store the year in the dive summary information, the information is available in other memory locations.

So a host software work around is definitely possible - at least on the models I've been able to test against.


--- bill

 

[derouyag]

The recall stuff was not likely... hence the chuckle.

Now I guess the easiest way for anyone at this time is to adjust the Access Database manually. Changing the "DIVEDATE" in the "DiveData" table is fairly simple. Then you ultimatly need to change the sequence of the "LIFETIMEDIVENO" to the correct sequence. That is a little annoying for every dive download in 2010 and beyond. For me it is only a single dive...

 

[bperrybap]

The recall stuff was not likely... hence the chuckle.

Now I guess the easiest way for anyone at this time is to adjust the Access Database manually. Changing the "DIVEDATE" in the "DiveData" table is fairly simple. Then you ultimatly need to change the sequence of the "LIFETIMEDIVENO" to the correct sequence. That is a little annoying for every dive download in 2010 and beyond. For me it is only a single dive...

I don't think manually patching the database is necessary.

You can modify the date of any dive using ACI/Oceanlog.
Simply find the dive you want to modify.
Then change the year in the "DATE" field.
Click on the [next dive] button (little triangle pointing to right on the top bar)
and when it asks you if you want to save the changes say yes and then the date
for that dive is modified in the database and all the LTD number for all the dives
in the logbook are automatically recalculated and sorted based on the date/times
of all the dives in the database.

I have verified that this works on ACI 2.2.2 (latest)
OceanLog 2.2.5 and 2.2.6 (latest)


--- bill

 

[gbirch]

Good news!

I reported the problem to Aeris Tech Support 3 days ago. Yesterday I received an e-mail saying that they were working on the problem. Today I received another saying that they had a fix and will soon update the version on their Tech Support website for download. They pointed me to a pre-release version (Version 2.2.2 of the Aeris Computer Interface) which I downloaded, tested and it works like a charm! All the '10 dives came in perfectly.

Kudos to Aeris for turning this around quickly and for the friendly, helpful tone in their e-mails from Tech Support!

 

[SandyUT]

The 2.2.2 works, but I dont on 3.1.10 and the Aeris ai loged it as 2.29.10 & the 2.2.2 dive log skipped these dives as the date does not exist!

I am moderately concered about the leap year on the wrong year.

So basically the actual computer has the same issue as the software.

Anyone see this?

Will this reoccure every 4 years?!