Table of Contents

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 table below shows some examples for the assignments of the 3rd digit. Even though these assignments refer to IRIG-B, the coding of the 3rd digit also applies e.g. to IRIG-A and IRIG-G frame formats, etc.,

3rd digit / Code Name Included Data
0 IRIG-B000/B120 TOY + CF + SBS
2 IRIG-B002/B122 TOY only
3 IRIG-B003/B123 TOY + SBS
5 IRIG-B005/B125 TOY + 2 digit year number + CF
6 IRIG-B006/B126 TOY + 2 digit year number
7 IRIG-B007/B127 TOY + 2 digit year number + SBS
IEEE 1344 TOY + 2 digit year number + SBS + UTC offset, DST and Leap Second flags, Time Quality indicators, ...
IEEE C37.118 TOY + 2 digit year number + SBS + UTC offset, DST and Leap Second flags, Time Quality indicators, ...
AFNOR NF S87-500 TOY + 2 digit year number + optional month, day-of-month, day-of-week + optional SBS


Modulated Versus Unmodulated Codes

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:

Unmodulated vs. Modulated Time Code

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.

Data Fields Included In Time Codes

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.

Time Of Year

The Time of Year (TOY) data field is included in all time code formats, and is often referred to as BCD or TOY. It includes the day-of-year as well as the hours, minutes, and seconds of that day, and in fact this is the only time information provided by some code formats. See Choosing A Code Format for more information.


Straight Binary Seconds

The optional SBS field (SBS) contains the second of the day, which can also easily be computed from the hours, minutes, and seconds in the TOY field, so this is some redundant information.


Year Number

Some newer IRIG time code formats (Bxx6, Bxx7) as well as the IEEE 1344 and C37.118 codes and the AFNOR NF S87-500 code provide a 2 digit year number, i.e. the year-of-the-century, but some older, commonly used formats don't provide this.

The year number is very helful to determine if the current year is a leap year, or not, and hence if February 29 has to be accounted for when converting the transmitted TOY to a calendar date, or not.

So when choosing a code format for an application a code format providing a year number should be used preferably.


Control Field

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.


AFNOR NF S87-500 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

AFNOR Code Extensions

Optionally the AFNOR signal can also include the day-of-week number (1..7, 1 = Monday), the calendar date (month and day-of-month), and an SBS number like the IRIG code formats.


IEEE 1344 And C37.118 Codes

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

IEEE Code Extensions

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

IEEE Discrepancies On UTC Offset

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.

Details On The IEEE Discrepancies On UTC Offset

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

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.

To substantiate the statements above here are some quotes from the original and revised IEEE standards. In both documents the explanation for the time offset bits in the control bit assignment table F.1 reads:

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)

This is consistent with the descriptive text in IEEE standard 1344-1995:

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.

In IEEE standard C37.118-2005 the explanation for the time offset bits in the control bit assignment table F.1 is exactly the same as in IEEE 1344-1995, but the descriptive text says:

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.

So obviously the original standard consistently says:

IRIG time + UTC offset = UTC

whereas the revised standard from 2005 states in the descriptive text:

IRIG time – UTC offset = UTC

which leads to a wrong UTC time if the IRIG generator applies to the original standard and the IRIG receiver to the revised standard, or vice-versa.


Leap Second Considerations

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.


Code Compatibility

Choosing A Code Format

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