IRIG Time Code Basics

The frequently used term IRIG signals refers to a whole group of serial time codes which use a continuous stream of binary data to transmit information on date and time. Individual IRIG code formats are distinguished by names consisting of a letter followed by a 3-digit number. The individual name determines the transmission speed and frame rate, whether the time code is modulated or unmodulated (DC level shift, DCLS), and the kind of information included in the transmitted data.

Back in 1956 the TeleCommunication Working Group (TCWG) of the American Inter Range Instrumentation Group (IRIG) was mandated to standardize different time code formats, resulting in IRIG Document 104-60 which was published in 1960. Over the years there have been a number of revisions and extensions to the original specification. The current version of the document is IRIG Standard 200-04 which was published in 2004 and is available for download at the U.S. Range Commander Council's publications web page:
https://www.wsmr.army.mil/RCCsite/Pages/Publications.aspx

Beside the original IRIG time codes there are additional standards like IEEE 1344 or IEEE C37.118, published by the Institute of Electrical and Electronics Engineers (IEEE), as well as AFNOR NF S87-500 published by the French standardization organization Associacion Française de Normalisation (AFNOR). The time codes defined by these standards are based on specific IRIG codes, but include some useful extensions.

Which particular time code should be used preferably for an application depends on the specific requirements of that application. For example, all the popular IRIG-B codes are based on a 100 PPS frame rate, while e.g. IRIG-A and IRIG-G use different frame rates. However, even though often used in device specifications, a name like IRIG-B alone doesn't tell whether the signal is modulated, or DCLS, and which pieces of time information are included.

For IRIG-B, the first 2 digits determine if a signal is modulated (B12x), or unmodulated (B00x), and the 3rd digit x determines which data is included.

All IRIG time code formats include the time-of-day and day-of-year information anyway, which is often referred to as BCD or TOY.

Optional extensions include a Control Field (CF), and a Straight Binary Seconds (SBS) field. Some newer code formats also provide a 2 digit year number.

The chapter Choosing A Code Format provides some guidelines which code formats should be used preferably, if possible.

The raw time code is a continuous stream of binary data transmitted at a given rate. Optionally this binary data stream can be modulated onto a sine wave carrier of a particular frequency. The image below shows both types of signal, the unmodulated signal in the upper area, and the modulated signal in the lower area:

Since the logic levels of the raw data stream are often represented by DC voltage levels, the unmodulated code frames are also called DC Level Shift signals, or DCLS signals.

Due to its nature as digital signals the DCLS time codes have well-defined slopes. Also, the propagation delays of digital line drivers and receivers are usually pretty constant, so it is easy to generate an accurate trigger signal from a DCLS slope and thus yield a high accuracy from a received DCLS time code.

For modulated signals the exact start of a signal frame is bound to the zero-crossing of the carrier signal, i.e. the carrier phase. On the receiver side it requires much more effort to detect the exact zero crossing point of a modulated sine-wave signal than capturing a digital slope. Also, modulated time codes often use filters, transformers, automatic gain control (AGC) circuits, etc., in the signal transmission path causing a delay of the analog signal. It also requires some effort to compensate such signal delays and yield an accuracy and precision from a modulated time code signal which is in the same range as the accuracy and precision of a DCLS signal. For Meinberg devices the difference is usually a few microseconds.

On the other hand, it's easier to distribute a modulated signal than a DCLS signal. A single modulated signal output can usually drive the inputs of several time code receivers by just using coaxial cabling and T-connectors. Also, time codes modulated onto a tone frequency carrier signal can easily be transmitted over a telephone line, can be recorded on magnetic tape, etc.

DCLS signals can be transmitted via digital transmission lines like RS-422/RS-485, fiber optics, or something else, but the voltage levels, polarity, and other electrical characteristics need to be defined accurately to get things working reliably, and eventually converters need to be inserted, e.g. for fiber optics.

Such connections are usually point-to-point only, i.e. one output should drive exactly one receiver input only. Wiring 1 output signal to e.g. 3 inputs may eventually work and can probably be used temporarily in a laboratory environment, but such setup should not be used for rough production environments. The proper solution to distribute DCLS signals is to use a kind of diplexer appropriate for the particular physical signal, which increases the overall effort and costs.

In the text of the originally published standards the pieces of data included in the transmitted signal are called Coded Expressions.

Some coded expressions are included in all time code formats, while other coded expressions are only provided by certain code formats.

All coded expressions are encoded as BCD data, even though the standards often say BCD when just refering to the Time Of Year information.

The Control Field (CF) refers to a set of data bits in a code frame which isn't otherwise used for specific data.

If the CF is supported then the meaning of each bit transmitted in this bit field is always application defined. This means, a particular time code generator could put some specific information into those bits which is useful for a specific application, and a specific receiver can extract those bits and interpret the CF bits according to what has been specified for this application, without affecting the transported time.

If the CF is not supported by the code format, or simply not used by the generator, then all of these bits in the code frame are simply 0. On the other hand, if the CF should be filled with some information by the generator, a standard time code receiver wouldn't know how to interpret these bits anyway.

Since the content of the applicaton-specific CF isn't required to decode the current date and time from the time code, it makes no difference for Meinberg time code receiver (TCR) devices whether the received time code contains a CF, or not. The receivers simply decode all data bits received from the generator but don't try to interpret the CF.

The decoded data bits including the CF bits can be retrieved from a Meinberg TCR PCI card using a public Meinberg API call, so an application can retrieve and decode the CF bits, if required.

As an example CF usage, a 3rd party IRIG generator could put some count down time into the CF field of a B122 code, so both the true current time and the count down time could be transmitted together, in a single code frame.

The user's application should know how the CF bits have been assigned, so the application could retrieve the raw data bits from the card via an API call and decode the current count down time. This is transparent for the TCR card and doesn't affect the normal timekeeping.

The size and location of the CF in a code frame varies with the code format.

For example, IRIG-B122 has a large number of bits which can be used as CF, but in IRIG-B126 a part of these bits are being used to transport a 2 digit year number, i.e. have a well-defined meaning, so the remaining CF is smaller.

The IEEE time codes use all of the B122's CF bits in a well-defined way to transport additional, very useful timing information, so in practice there is no more CF area left in the IEEE codes. However, time code receivers configured for an IEEE code can benefit from the additional information since the assignment of the extension bits is well-defined, and not specific to an application.

Basically the same is true for the AFNOR code extensions, but the IEEE codes contain even more information than the AFNOR code.

Back in 1987 the French standardization organization Associacion Française de Normalisation (AFNOR) already published a French standard AFNOR NF S87-500 which defines a time code signal similar to IRIG signals. That AFNOR code also transports the current time and day-of-year, but has been defined to always include a 2 digit year number.

This time code can be used as an unmodulated signal, or amplitude modulated onto a 1 kHz carrier frequency, so today it is basically similar to IRIG-B006/B126. However, these IRIG signals have only been defined in 2004, i.e. some years after AFNOR NF S87-500 has been published.

Unlike the original IRIG standards the AFNOR standard also defines the electrical signals to transport the unmodulated time code, which should be according to RS-422 / RS-485 specifications.

The publication can be purchased following the links on the AFNOR home page:
https://www.afnor.org

In 1995 a working group of the Institute of Electrical and Electronics Engineers (IEEE) published IEEE standard 1344-1995 about Synchrophasors for Power Systems, which also includes the specification of a time code. This time code is based on a IRIG-B122/B123 code but used most bits of the control field (CF) in a well-defined way to transport some additional information useful to overcome some limitations of the original IRIG time codes.

In 2005 the IEEE standard 1344-1995 was revised and the revised version was published as IEEE standard C37.118-2005, which defines the same extensions for the time code as the original IEEE 1344 standard, but unfortunately the way to handle the UTC offset was completely messed up in the revised version. See IEEE Discrepancies On UTC Offset for details.

In 2011 another revision of the IEEE standard determined that the last 3 spare bits of the time code could be used as Continuous Time quality (CTQ) indicator. Fortunately this was done in a way which is compatible with older versions.

The publications of these standards can be purchased following the links on the IEEE home page:
https://www.ieee.org

The so-called IEEE extensions of the time code include:

• A 2 digit year number to be able to determine if a year is a leap year or not, thus allowing for an unambiguous conversion of the day-of-year number to a calendar date.

• Leap Second Information:
  • An announcement bit which is set up 59 seconds before the leap second event
  • A leap second indicator which is set during the leap second

• Daylight Saving Time (DST) Information:
  • An announcement bit which is set up to 59 seconds before DST status changes
  • A DST indicator which is set while DST is active

• UTC offset information. If local time is transported by the IRIG frame then this parameter can be used to determine UTC time.
  Warning: there are discrepancies both in the different standards, and in existing implementations, about the way the UTC offset has to be applied.
  See below.

• A 4 bit Time Figure Of Merit (TFOM) code which allows the IRIG generator to pass an accuracy specifier to IRIG receivers, where TFOM 0 means highest accuracy, and TFOM 15 (0F hex) means unsynchronized.

• A 3 bit Continuous Time Quality (CTQ) code, defined in IEEE C37.118.1-2011, compatible with older standards.

Care must be taken if the IEEE 1344 or IEEE C37.118 time codes are used to transfer local time instead of UTC. Both standards define the same bit field in the time code to transfer a UTC offset, but unfortunately in IEEE C37.118 the way the transferred UTC offset has to be applied has been reversed.

Most IRIG devices manufactured by Meinberg support both the IEEE 1344 time code and the newer IEEE C37.118 code. The only difference between these settings is the way the UTC offset is handled.

If the transferred time is anyway UTC then everything is fine since the UTC offset is 0.

If local time is transferred using an IEEE code and only Meinberg devices are involved then everything works well, too, if all devices have been configured to use the same IEEE code, either 1344 or C37.118.

Unfortunately there are 3rd party IRIG devices out there which claim to support IEEE 1344 extensions, but in fact apply the UTC offset as specified in C37.118. If e.g. a generator transmits a -6h UTC offset to be *added* to the transmitted time to yield UTC, but the receiver *subtracts* this offset instead, or vice versa, then the resulting UTC time is obviously wrong.

So if 3rd party time code generators or receivers are involved, and local time is transmitted, then care must be taken that the resulting UTC time on the receiver is correct. Eventually the configuration setting on a Meinberg time code generator or receiver can just be changed from 1344 to C37.118, or vice versa, according to the requirements.

Both the IEEE 1344 and the IEEE C37.118 standards contain two pieces of text describing how to handle the UTC offset parameter:

• A table describing the assignment of the control bits, including an explanation how to handle the time offset bits
• A chapter of descriptive text explaining how UTC offsets are to be handled, including an example for the computation

In the IEEE standard 1344-1995 both pieces of text consistently and unambiguously explain how to handle the UTC offset.

In the IEEE standard C37.118-2005 only the chapter of descriptive text has been modified and now says that to convert the transferred time to UTC the UTC offset has to be subtracted rather than added.

The associated computation example in the text has been modified accordingly. While it is generally not wise to change specifications in this way, things are even worse since the explanation text in the control bit assignment table has not been updated accordingly and is still the same as in the original standard from 1995.

So the IEEE C37.118-2005 standard contains two pieces of text which define two contradictory ways to handle the UTC offset.

Offset from coded IRIG-B time to UTC time.
IRIG coded time plus time offset (including
sign) equals UTC time at all times (offset will
change during daylight savings)

F.3.4 Local time offset

The local time offset is a 4 b binary count with a sign bit. An extra bit is included for an
additional 1/2 h offset used by a few countries. The offset gives the hours difference (up to ±
16.5 h) between UTC time and the IRIG time (both BCD and SBS codes). Adding the offset
to the IRIG-B time using the included sign gives UTC time (e.g., if the IRIG-B time is
109:14:43:27 and the offset is -06 given by the code 0110 (.0), then UTC time is
109:08:43:27). The local time offset should always give the true difference between IRIG
code and UTC time, so the offset changes whenever a daylight savings time change is made.
Keeping this offset consistent with UTC simplifies operation of remote equipment that uses
UTC time.

F.1.4.4 Local time offset

The local time offset is a 4-bit binary count with a sign bit. An extra bit has been included
for an additional 0.5 h offset used by a few countries. The offset gives the hours difference
(up to ± 16.5 h) between UTC time and the IRIG-B time (both BCD and SBS codes).
Subtracting the offset from the IRIG-B time using the included sign gives UTC time. [For
example, if the IRIG-B time is 109:14:43:27 and the offset is –06 given by the code 0110
(.0), then UTC time is 109:20:43:27.] The local time offset should always give the true
difference between IRIG code and UTC time, so the offset changes whenever a DST change
is made. Keeping this offset consistent with UTC simplifies operation of remote equipment
that uses UTC time.

IRIG time + UTC offset = UTC

IRIG time – UTC offset = UTC

One advantage of the IEEE code formats over all other time code formats is that the IEEE codes also include leap second warning bits.

The leap second handling of standard IRIG code formats is limited to the transmission of a second with number 60 to indicate an inserted leap second. This may be appropriate for dumb wall clock displays, but e.g. computer time synchronization including proper leap second handling requires the announcement of an upcoming leap second.

Unfortunately the announcement interval is very short. According to the IEEE standards the leap second warning bit is only set up to 59 s before the leap second occurs. This is usually sufficient if only the computer's system time is to be disciplined, but if the computer should e.g. also act as an NTP server then this announcement interval is too short to pass the leap second warning down to NTP clients reliably.

Anyway, the IEEE codes are the only time codes which support this at all.

Accuracy requirements or the availability of signal transmission infrastructure (cables or similar) can often help to prefer some modulated or DCLS time code. However, also the kind of information transported by a specific code has to meet the requirements of an application.

All types of time code signals discussed here contain the day-of-year number and the current time of that day. This is sufficient to drive wall clocks which simply display the time transmitted by the time code signal, but this may not be sufficient e.g. to synchronize a computer's time. For example, if the system time of computers is to be disciplined in a reliable way using a time code signal then the time code receiver needs to be able to derive both the correct calendar date and the current UTC time from the incoming signal.

Unfortunately most basic IRIG signal frame types like B002 or B122 neither include the year number, nor do they provide any information telling whether the transmitted time is UTC, or some local (DST or standard) time with a certain offset to UTC.

If only a day-of-year number is provided by the received time code signal then obviously the conversion from day-of-year to calendar date is ambiguous after February 28, since the next day can be either March 1, or February 29, depending on whether the current year is a leap year, or not.

Thus the time code receiver needs to know the current year number, either by configuration, or preferably by using a time code format providing the year number.

Also, if the time transmitted by a time code signal is to be converted to UTC in order to discipline a computer's UTC time then the receiver needs to know whether the transmitted time is UTC or local time, and if it is local time it needs to know the UTC offset. Of course it is easily possible to configure the UTC offset on the receiver side, but at the beginning or end of DST the UTC offset will jump back or forth by the amount of the DST offset, in which case the converted UTC time would also step back and forth, and so would the system UTC time of the computer to be disciplined. Such steppings of the computer system time are very error prone and can have severe side effects, e.g. on database applications, and thus should be avoided in any case.

Newer time code formats are usually compatible with the old basic formats, but in addition include some or all of the required information in well-defined extensions placed in the bit field which is used as application-defined control field by the original IRIG frame formats.

A reliable way to synchronize the computer time is to use at least a time code which includes the year number (e.g. IRIG-B126, AFNOR NF S87-500, or one of the IEEE formats), and let the time code generator transmit UTC time.

If also the local time has to be transmitted in the same time code signal (e.g. to drive wall clocks) then the IEEE time codes are the best choice. The signals are compatible with the popular IRIG-B122 format, so e.g dumb wall clocks can simply decode the B-122 code, while time code receivers which need to compute UTC time can do this easily since the UTC offset is also transmitted in the IEEE extension fields. Care must be taken, however, that both the time code transmitter and the time code receiver handle the UTC offset with the same sign. See IEEE Discrepancies On UTC Offset for details.

— Martin Burnicki 2019-02-27