WMRA Homepage Technical Info on WMRA website Photo Tour Site Info & Coverage The LINKY page
By William Fawcett
Let's face it, Y2K is getting a lot of press. A recent House panel predicted that more than one-third of the most important systems won't be fixed in time. One system that broadcasters need to be concerned about is the Emergency Alert System (EAS).
In investigating this problem an amazing amount of circular reasoning has surfaced. Several months ago FCC EAS head Frank Lucia made inquiry to all EAS manufacturers. He was told that there would be no problem. On the basis of that report, others have informed me that it is not an issue. The actual fact of the matter is that there are known problems with the majority of units, and that appropriate upgrades have not yet been issued.
On the surface, the EAS system would appear to be immune to year-related issues. After all, the data-stream protocol uses a date/time format "JJJHHMM", where JJJ represents the day of the year. No year information is actually transmitted. The problem arises in the translation of the JJJ date into a date which includes the year in the units user interface (typically a printout). The three digit date code (sequential day number of the year), for dates after February 28, will differ by one when comparing a leap year date to a normal year.
The user interface issues become even more complex when the printout includes a day-of-the-week. In that case, the date returned will be incorrect if the unit processes a date in a year "00" or later as if it occurred in the early 1900's.
According to Frank Lucia, a date scheme which would have used the format DDMMYYYY was considered, but the more concise JJJ format was chosen, not to shorten the data stream but instead to stay with currently existing Weather Service SAME protocol.
Some vendors might define Y2K compliance as meeting FCC specifications. It is important to note that ALL FIVE units met FCC specifications at the time they were released, and it can be said, to this date, that they STILL meet those specifications. It is possible that a unit may continue to receive and automatically relay messages but return incorrect information through the user interface. This is a critical situation for stations that do not use fully-automatic operation.
The "selling points" of the various units were the additional features not required by the FCC. They (or the lack of them) were likely crucial in your purchasing decisions. Therefore, all features of a unit must be reviewed in order to make an enlightened assessment. Full Y2K compliance means that the unit is completely unaffected by the Y2K problem, not that the unit essentially functions in most respects.
Some broadcasters have set their units to December 31, 1999, and have observed the clock successfully roll over into the new millenium. That is NOT a valid Y2K test. Besides the leap year problem, and a few other known glitches, there are more crucial functions that must be tested.
You must make sure to observe how ALL functions operate, such as how the unit reports dates for logged events. A legitimate test would involve closed circuit tests between at least TWO units, and the best testing situation would be to conduct a test sending and receiving between all 5 approved units. Unfortunately the FCC's Laurel, Maryland lab no longer has current versions of the five units on hand.
An attempt has been made to gather information on the current EAS units, and also to undertake some informal testing. There may indeed be additional problems not uncovered by this survey.
A curious leap-year problem, not directly related to Y2K, has been discovered. When interrogating the unit for logged events, the unit will printout the day the event was received (or transmitted) correctly, but will process the day stated in the duration of the event according to the present year, which is not necessarily the year the event occurred in. This is hard to explain but important to understand.
Remember that each data string for an event includes a Julian date/time code in the format JJJHHMM. Day 251 (JJJ=251) is September 8 in a normal year, but is September 7 in a leap year.
So, if the present year is a leap year, and you printout a logged event that occurred in the previous (normal) year, the date listed in the duration will be incorrect (if the event occurred between March 1 and December 31). The same thing should occur with leap year events printed out in a normal year.
Operationally, this is a minor problem, and again is only vaguely related to Y2K. The same problem would have occurred in 1996 (a leap year) if the EAS had been operational at the time. It is only coincidence that the year 2000 is also a leap year.
The Version 1.0 Burk unit demonstrates both a Y2K problem and a leap-year problem. When the unit is set to the Year "00" the printout returns the date "2000", but calculates the day of the week as if it were "1900". For years "01" and beyond, the printout and day-of-week calculations both process the dates in the 1900's. Figure 1 shows an event logged in 1998 and interrogated in 2000. The tapes demonstrate the leap-year problem, and the Y2K problems, to wit: it returns the wrong year (2000 s/b 1998) and interprets the day of the week according to the year 1900.
It is conceivable that the Burk unit would continue to relay messages in 2000 and beyond, but having the wrong day of the week on the printout would cause undue confusion. The Burk unit gives a lot more information on the printout than is required, and this has become their undoing. We have been told that the upgrade will actually supply even more information on the printout.
UPDATE
HollyAnne states: "HollyAnne Corporation EAS equipment is year 2000 compliant. This includes equipment built or distributed by HollyAnne Corporation.
The method of testing followed the guidelines of Y2K compliance analysis including "leap and non-leap" year functionality. The day tracking analysis was also completed successfully. Additionally the "9999" September 9, 1999 data failure analysis was completed successfully. "
Although HollyAnne's statement lists several pieces of equipment, but excludes the HU-961 unit, a HollyAnne spokesman indicated that the HU-961 unit is compliant.
Skip White at MTS has stated that all the functions of the EAS 3000 are Y2K compliant, including the 486 motherboard and Bios that is the platform for the unit.
UPDATE
As "historical events" are stored as a text file, no leap-year interpretation problems would be anticipated.
Jim Gorman states that all units with firmware newer than 6.4 are Y2K compliant (which means the early units were not). There have been several upgrades recently, current firmware is 8.1, and Gorman users should ensure that their units are current.
"The SAGE Endec MAX 1822 will continue to receive and transmit properly encoded EAS alerts through the year 2000 with the current firmware version 5.88 as pursuant to FCC parts 11 rules.
EAS alerts as specified in FCC Part 11.31 (3) (c) do not include the year. The protocol requires that all EAS alerts be encoded with only the Julian day, hour and minute"
The Sage Endec displays the year information for user convenience. When viewing the "menu.alerts.view" alert log function, an anomaly will occur for the display of years 2000 [will be 100], 2001 [will be 101], 2002 [will be 102], etc. for firmware versions lower than 5.103, including 5.88."
What this statement does not tell you is that the Sage unit will demonstrate the same leap-year problem as noted with the Burk unit.
When interrogating the unit for logged events (VIEW ALERTS LOG), the unit will process the day stated in the duration of the event according to the present year, which is not necessarily the year the event occurred in.
So, if the present year is a leap year, and you printout a logged event that occurred in the previous (normal) year, the date listed in the duration will be incorrect (if the event occurred between March 1 and December 31). This is demonstrated in Figure 2., which shows a 1998 Sage printout above the same event printed in the year 2000. Note that the sage unit has re-interpreted Julian day 251 as Thursday, September 7 instead of Tuesday, September 8. A similar problem might occur with leap year events printed out in a normal year.
As we stated in our review of the Burk EAS unit, this is a minor problem, and again is only vaguely related to Y2K. The same problem would have occurred in 1996 (a leap year) if the EAS had been operational at the time. So while this is not technically a "Y2K" problem, it is a serious engineering flaw.
Harris has indicated that Firmware version 5.103 is available (at a cost of $50 ) to correct the Y2K problem. It remains to be seen if the upgrade will repair the leap-year bug that they have not officially acknowledged.
TFT had previously stated that "all of its products, (those) that are currently shipping and those shipped previously, will not be affected by any year 2000 issues. Specifically, the EAS 911 series of EAS Encoders and Decoders and the EMAS series distributed by Federal Signal Corporation will accommodate the rollover to the year 2000 and that for any dates from January 1, 1995 to December 31, 2094."
Once again the leap-year bug has reared its ugly head. As a result of our investigations TFT's Darryl Parker has confirmed that the TFT unit (version V*.820) has "a problem with annotating the year correctly to received messages". That's just another way of stating the TFT unit exhibits the same manifestations of the leap-year bug that has afflicted the Sage and Burk units.
UPDATE
So what do we do? Broadcasters should continue to pressure the vendors to make repairs at no charge for manufacturing defects. This is a hot issue for many, and there are quite a few broadcasters who still feel that they were coerced into purchasing expensive equipment that was never fully defined by the FCC to start with.
Right now, large cable operators are having to gear up for EAS. Other broadcasters might be replacing equipment as consolidation takes place, and it is possible that some have not yet attained compliance. Steps should be taken to protect your investment in any equipment (including EAS) that has date processing functions. A simple but expedient procedure is to attach the a statement similar to that in Figure 3. to any purchase order
UPDATE
Unfortunately, Y2K is not the only problem. The QDI patent issue is hot topic right now. On top of that, some equipment doesn't compensate for Daylight time, and will process incoming events as expired until the clock is manually reset. This leaves a vulnerable period each April where the EAS system is basically shut down for certain unattended stations. And then there is the county sub-division fips code problem......
(Courtesy of the Commonwealth of Virginia)
YEAR 2000 COMPLIANT WARRANTY: The Contractor warrants that all software, firmware and hardware product(s) delivered to purchaser under any agreement, and which is used in accordance with the product documentation provided by the Contractor, shall be 4-digit Year 2000 compliant. All products shall accurately process all date-change data from start to finish, including, but not limited to, twentieth, twenty-first centuries and leap year calculations. Any product provided under this Agreement discovered not to be compliant after acceptance shall be corrected by the Contractor at no additional cost to the purchaser. Failure to correct the deficiency shall subject the Contractor to default action.
Place this statement on all Purchase Orders for any date-sensitive equipment you purchase.
For current information from the manufactuer's websites, check these links.
Notice: Listing of equipment information does not constitute any endorsement of any manufacturer or vendor by the Virginia S.E.C.C. or the Commonweath of Virginia.
William Fawcett
is director of engineering at the Center for Public Broadcasting at James
Madison University and president of Mountain Valley Broadcast Service
in Harrisonburg, VA. Photo of the Gates remote control is from the collection
of Chuck Leavens. |
Burk tells us forthrightly that the Burk EAS unit is NOT Y2K compliant, but that a software upgrade that will address this is almost complete and is slated for released in the near future. The promised but not yet evident first revision has been in the "almost ready" stage for at least a year.
Sage Endec units are distributed and serviced by Harris Corporation. Harris has issued a statement which says:
According to Jim Woods (Vice president for Radio at Harris) the $50 charge is defensible because it was a "convenience issue". Sage users will have to determine for themselves if they bought the unit only because it met FCC requirements (as did the other 4 approved units), or if they bought it on the basis of its proprietary features and user interface. Obviously the latter was the approach encouraged by Harris; one early Sage brochure stated: "All EAS encoders and decoders are NOT created equal. While they all have to meet minimum FCC requirements, the new Sage ENDEC, alone, provides user-friendly operation". Harris continues to use this statement in their current website advertising.