False Leap Year error in Phoenix, Unicorn, Pegasus

PROBLEM:

Due to a binary to decimal conversion error inherent in the clock chip; the Phoenix, Unicorn, Pegasus units add the non-existent date of 02/29/2010 instead of moving to 03/1/2010. This adds a non-existent day to the calendar year of 2010.  Because the units add this data; the data being recorded and the unit clock are consequently one day off beginning on 03/1/2010, and records data for 02/29/2010.

NOTE: Units that have been continuously running and have not had the clock time adjusted since 12/31/2009 will correctly move from 02/28/2010 to 03/1/2010 without issue.  This has caused some confusion with some units having the error and not others.



SOLUTION:


The following steps are needed to resolve this issue in order correct the data and to resume normal data collection. Due to the nature of this issue it is critical to do the following steps in order.


Step # 1:  Patch Centurion Software

First, a Centurion software update patch has been deployed and is available through the Centurion Help Menu "Check For Software Updates" feature and via direct download from our website at  http://www.diamondtraffic.com/html/updates.html .   The update is required to allow the software to connect to the counter and download data properly due to the date error. The version required is 1.35 build 20 or greater.

Step # 2: Verify Unit Date (and error)

If the clock was set before 2010, the unit will not have had the error. Log on to the individual units and check the counter clock.  If the unit clock is a day behind then you must proceed to the following steps; if the date in the unit is correct, then you do not need to perform these steps.

Step #3: Reset Unit clock Date/Time

The unit Date will now be one day behind the actual date. To correct this, the unit needs to have the Clock updated. You must STOP COLLECTING data to adjust the clock. This will mean you will lose one interval of data in the unit. Once the unit has been stopped, you must set the clock (Set Clock) in the SHOW STATUS window.  With the clock updated, you may proceed to START COLLECTING and resume data collection in the unit.

image002.jpg

Step #4: Download Data (screenshots below)
Now that the unit has been restored to normal, the data that was collected needs to be downloaded, imported, and corrected.  Use the RETRIEVE/DELETE FILES window to DOWNLOAD UNRETREIVED FILES or all the files (except the open file) since 2/28/2010.

Once downloaded Centurion by default will import these files into the database unless you have your settings different from default (in which case you will need to manually import these files).  Because two files will be labeled 3/1/2010, a data overlay warning will appear. SKIP OVERLAY DATA is the option you want to use as the following steps will correct the date in the data.

NOTE: If steps 1 through 4 are not done correctly, the processing in Step #5 may have unexpected and unsuccessful results. Please make sure you have stopped collection, and re-set the clock in your units and imported all the data before proceeding.

image004.jpg

image005.jpg
image006.jpg


Step #5: Correct the Data in The Database
(screenshots below)
After the files have been imported you must now have Centurion correct the data.

  1. Open up the database list of sites.
  2. Right click on the site that has the incorrectly imported data and select “Leap Year Fix …” Note that you can tag and do more than one site at a time.
  3. Pick the year to fix, in this case “2010”. Note that the software will fix future problems in the year 2012, 2014, etc (every two years unless using an updated firmware).
  4. Click Start.

The fixing process is automatic. Centurion does the following when the counter incorrectly thinks a year is a Leap Year when it is not:

  1. Finds imports that begin at 00:00 on March 2nd through the next break in the data that is at least 1 day wide (indicating the user reset the time).
  2. Shifts all of these imports by +24 hours.
  3. Searches the Download\Archive directory for data for this site that truly belongs on March 2nd of this year. This will be the data that is saved as March 1st, but was not imported because the software shifted the incorrect Feb 29th data to March 1st.


If you pick to fix a year that is a leap year and the counter thinks it’s not (such as what will happen in 2012), the software does this instead:

  1. Finds imports that begin at 00:00 on March 1st through the next break in the data of any size.
  2. Shifts all of these imports by -24 hours.
image007.jpg  

image008.jpg

image009.jpg

image010.jpg

Step #6: Verify Data
It is recommended that you verify all the data you have downloaded to make sure the error was corrected without any other issues or failures. You can check the data by clicking on the Database List in Centurion and looking at the individual file imports to check that the data you have is labeled 3/1/2010 and that the data is indeed in the database.

image011.jpg

TROUBLESHOOTING:

Q: I get the following error in Centurion when I try to connect to my unit or download data:


image012.jpg

A: This error is due to an older version of Centurion not having the patch needed to communicate to the unit (Versions prior to 1.35 build 20). A Centurion update is required to correct this error.


Related Articles

No related articles were found.

Attachments

No attachments were found.

Visitor Comments

  1. Comment #1 (Posted by James Kramer )
    I understand the problem of the counter thinking it's aleap year when it isn't and I have already written a patch to fix that. But if I read this correctly the counter may also not recognize when it is a leap year. Is this correct? If so I need to write an additional patch to cover that problem. Jim
  2. Comment #2 (Posted by Colin Gibson (Diamond) )
    Jim, Yes, the counter will actually not calculate 2012 as a leap year even though it will be. However, updated firmware does correct this. Obviously all new units will not have the issue and old units can be upgraded to patch this issue altogether.
  3. Comment #3 (Posted by Jim Kramer )
    Another question. Our program automatically checks the Phoenix time and date every night and resets it if it's off more than a couple minutes. On a Leap Year and the Phoenix doesn't roll over to Feb 29 and my program goes in and resets it to Feb 29. What is the Phoenix going to do after that? Will it then roll over to March 1 the next night as it's supposed to and continue to work properly after that?
  4. Comment #4 (Posted by Colin Gibson (Diamond) )
    Correct, the unit will move from Feb 29th to Mar 1st without issue.

Post Comment for "False Leap Year error in Phoenix, Unicorn, Pegasus"

To post a comment for this article, simply complete the form below. Fields marked with an asterisk are required.

   Name:
   Email:
* Comment:
* Enter the code below:

 

Article Details

Last Updated
21st of October, 2011

Software
Centurion CC, Centurion Gold, Centurion Parks

Hardware
Pegasus, Phoenix, Phoenix RAX, Phoenix RAX II, Unicorn

Would you like to...

Print this page  Print this page

Email this page  Email this page

Post a comment  Post a comment

 Subscribe me

Subscribe me  Add to favorites

Remove Highlighting Remove Highlighting

Edit this Article

Quick Edit

Export to PDF


User Opinions

No users have voted.

How would you rate this answer?




Thank you for rating this answer.

Continue