KDG Telemetry

Year-2K Compliance: DT500, 600 and 700

This page reflects work-in-progress. It will presently be updated to include details of the test procedures we are applying, however this is complicated by the fact that most of the requests we have received are framed in slightly different terms.

To summarise the remainder of this document, our equipment is designed to function from 1980 to 2079, and will give no problems at the transition from 1999 to 2000 provided that the current firmware is fitted.

Before anything else, it is worth pointing out that none of the Dialtone outstations is based on PC technology, so a large part of what is written about the Year-2K problem does not apply since the units' firmware has little in common with a PC's BIOS. Having said that, in common with the majority of PCs the DT500, 600 and 700 models do use a 146818 real-time clock chip which is now understood to have certain peculiarities:

The year is stored as two digits, usually BCD, with a further two digits representing the current century being applied by software. The result of this is that any year where the last two digits are 00 will be treated as a leap year by the clock chip i.e. whilst 2000 is correctly recognised as a leap year, 1900 and 2100 will be as well which is not correct. There is no easy work-around for this other than hard-coding the current century into the firmware or application code which handles date expansion.

There are known times (23:59:58 and 23:59:59) to which the clock should not be set during the last few days of any month since this can cause an incorrect date rollover.

We do not make use of the daylight-saving feature of this device since this would make it impossible to obtain an unambiguous time between 01:00:00 and 01:59:59 on the last Sunday of October.

A statement of our current position is as below:

Equipment older than the DT500:

Outstations which pre-date the DT500, i.e. all variants of the DT100, DT200 and DT300 together with Dialarm units and any engineering "specials" derived from these, do not store or refer to the date in any way, therefore they are inherently Year-2K compliant. However, these products are no longer supported since in some cases component parts are unobtainable, and whilst we will do our best to keep customers running we normally recommend that any of these units which remain in service should be replaced by DT600s which are currently our entry-level model.

DT500, 600 and 700:

We have tested and do not anticipate any problems with the date roll-over or leap-year determination on outstations that maintain their own real-time clock and calendar, i.e. the DT500, 600 and 700; provided that these are fitted with the current version of firmware:

DT600 (UK operation, with speech)	I0.20
DT600 (non-UK operation, external modem)	X0.18

In other words, we expect that there will be no interruption to normal operation at the point where the year changes from 1999 to 2000, and that the year 2000 will be correctly identified as a leap year.

Timestamp calculations in the data-logging memory do not make use of the year value, and provided that the time and date setting of the outstation has not been changed manually timestamps are guaranteed to be monotonic, i.e. there will be a single transition between 31/12/99 and 1/1/00 which represents the century rollover. This is accommodated by the protocol handler in the System 100 CAMM masterstation which assumes that any two-digit year less than 80 is in the 21st century, whilst years >= 80 are in the 20th.

We suggest that in cases where the outstation's logging facilities are used that the following precautions should be taken during the last few months of 1999 if the time or date are to be decremented:

Retrieve the logged data.

Adjust the time and date as required.

Re-initialise the logstore using the LINT command.

There is a known problem in firmware revisions older than 0.16 which affects the rollover of the date from the 31st December 1999 to 1st January 2000, instead it displays a date of 1900. This is basically a cosmetic failure affecting only the DATE command since as noted above the more significant digits of the year are neither transferred as part of the data-transfer protocol nor used in the calculation of internal timestamps. We believe that all DT600s fitted with revision 0.16 (or later) firmware will function correctly, i.e. outstations shipped after the middle of 1996. With all firmware versions the year 2000 is correctly identified as a leap year.

We believe that the above points apply to all released firmware revisions, however this is subject to any modifications that the manufacturers of the real-time clock devices may have introduced during the lifetime of these models.

Operation will be as expected until around 2080, whereupon the apparent date will revert to 19xx rather than 20xx. With all current revisions of firmware the year 2100 will be incorrectly reported to be a leap year (i.e. the firmware takes no special steps to correct the bug in the real-time clock chip). In all cases the year is entered as two digits with any surplus discarded, i.e. Saturday 1st January 2000 should be entered as DATE=7/01/01/00 rather than as 7/01/01/2000 which would be interpreted as 2020.

Instation:

This comprises DT500 CPU and modem cards and is used to expand logged data from the reduced form in which it is transferred from a DT500, 600 or 700. Unlike a DT500 it does not have a real-time clock chip, and applies no time-related operations to the data it handles other than reproducing the value of the last received timestamp where required.

Last updated: 27th July 2006

KDG Telemetry is based in West Sussex, with key personnel working from their chosen location.
tel: +44 (0)1293 525151 fax: +44 (0)1293 547900 email: jamesFP.in@telemetry.co.uk