IRIG-B is still one of the most commonly used methods of transmitting time on a network, despite being one of the oldest. Let's take a brief look at how it works and why it's still in use. For a more in-depth eBook, see here
IRIG works by sending pulses that are encoded with time data. There are many different forms of IRIG. This is because there can be variations in the number of pulses per second (or minute), the type of pulse used, the frequency of the pulse and the data encoded into the message. The most common type of pulse we see is IRIG-B004, a DCLS signal with no carrier wave that sends out 100 pulses per second.
BCD- Binary Coded Decimal Notation in days, hours, minutes and seconds
SBS- Straight Binary Seconds
CF- Control Functions
Each format has a varying number of control functions. These are outlined in the table below.
Control functions are a group of user-defined inputs that are outside of the IRIG Standard. They can be used to define several key fields such as the health of the clock, whether a leap second is pending or the daylight saving offset. The AFNOR and C37.118.1 Standards define these fields.
How it encodes
With 100 pulses per second, each pulse can be used to convey a different piece of time information. Below is an example of what a full second of encoded data looks like at 100pps:
As can be seen in the diagram each piece of time information is encoded to correspond to changes in electrical current. The way this information is encoded can be determined by what format the IRIG signal is transmitted on. The table below shows how the bits of data are encoded when using IRIG-B and what each bit of data represents.
You might be asking, if this is so old and outdated then why are people still using it? Different organizations will have their own reasons, but the most common are the deterministic properties, standardization, and cost. Let’s start with the deterministic properties. An IRIG channel can either be transmitting or not transmitting. This makes it easy to determine whether a signal is being transmitted, and when that signal should arrive at its destination. Ethernet can also determine whether a signal is being transmitted, but there is no guarantee that it is a timing signal or just a network signal. Ethernet will not natively queue the signals, making it more difficult to predict when a message arrived (using networks protocols and software can mitigate this issue).
Standardization is another reason, because IRIG has been around such a long time it has become the standard for analog timing and synchronization. Most intelligent electronic devices (IEDs) are capable of receiving and interpreting an IRIG signal.
Lastly, cost. This is probably the biggest block when it comes to moving away from IRIG. IRIG is so ingrained that to move away from using it can be a huge task. Not only does this require the clock to change, but also cabling, IEDs, and network interfacing need reworking.
For more about IRIG, see our whitepaper here
If you have your own reasons for continuing to use IRIG-B we would love to hear why. Please leave your thoughts in our Linkedin group https://www.linkedin.com/groups/13680175/