Timing and Sync: An Epic on Epochs
Wes Simpson SMPTE recently published two new standards about timing and synchronization that are poised to have a significant impact on the way timing is handled for devices in professional broadcast applications. The basic idea is that each device can generate an accurate clock that is frequency- and phase-aligned to other devices in the network, eliminating the need for a “house clock” or “genlock” sync signal distribution system. This helps simplify the cabling needed to support cameras that are spread around a venue while still allowing them to have frame-accurate time-codes and synchronized video and audio recording and outputs. All that is required is a (very) accurate time reference at each location.
DEFINED PROFILE
The key underlying technology is IEEE- 1588 Precision Time Protocol, which enables an Ethernet network to distribute a highly accurate clock across a local area network. The basic technology of IEEE-1588 was described in my column in the Sept. 3, 2014 issue (“Using IEEE 1588 PTP in Video Networks”). Nodes must be synchronized to an accuracy of better than 1 microsecond, which is perfect for today’s digital studio applications.
Because IEEE-1588 defines a broad range of features and capabilities, the standard requires a profile to be defined for each application space to allow interoperability between devices. SMPTE has done just that, with the release of ST 2059-2:2015 “SMPTE Profile for use of IEEE-1588 Precision Time Protocol in Professional Broadcast Applications.” New products that support 2059-2 clocking will be coming on the market in the near future.
What’s an epoch, and why do we need one? In order to tell time, you need two things: a working clock, and a reference for setting the clock. For many of us, the local time zone is an adequate reference point (mobile phones are actually pretty accurate timepieces). However, in order to achieve the level of accuracy needed to genlock a group of cameras or microphones, a much more accurate time reference is needed.
This is the purpose of an “epoch,” which is a (very) specific point in time that can serve as a common time reference for multiple signals. The SMPTE standard ST 2059- 1:2015 “Generation and Alignment of Interface Signals to the SMPTE Epoch” provides this reference point, which happens to be precisely 1970-01-01T00:00:00 TAI.
Fig. 1: A network made up of multiple devices that all share a common clock using PTP derived from GPS. So it’s reasonable to ask “Why all this precision?” The answer is that with an epoch, it becomes possible to calculate the phase of any periodic signal that can be referenced to that epoch. So, by defining the phase of various common video and audio signals to a common reference point or epoch, it becomes possible to figure out the phase of that signal at any other point in time. This in turn allows each device to align itself to a common, aligned reference simply by knowing the (precise) current time, as referenced to a common epoch. Fig. 1 shows a network made up of multiple devices that all share a common clock using PTP derived from GPS. Using this clock, each device can be referenced to the SMPTE epoch, and hence to each other, without any need for an overlay clock distribution network. Contrast this with a traditional setup, which would have required separate sync distribution paths for each type of video and another one for audio. Clearly, the PTP-based solution is much simpler.
OTHER EPOCHS AND LEAP SECONDS
The SMPTE epoch is identical to the one used for IEEE-1588, which is referenced to the TAI (International Atomic Time) epoch used by labs worldwide with the most accurate atomic clocks. Another epoch that is commonly used is the Global Positioning System epoch, which is 0000 UT (midnight) on Jan. 6, 1980, and is offset from TAI by a constant 19 seconds. The epoch used for Coordinated Universal Time (UTC) is closely related to TAI, except that the epoch for UTC is 1972-01-01T00:00:00Z, or exactly 63,072,010 seconds later than the SMPTE epoch. The Network Time Protocol (NTP) is also based on UTC. The difference between UTC and SMPTE/PTP time is not fixed; it changes every time a leap second occurs.
Leap seconds are used to match a clock to the speed of the Earth’s rotation. A normal day is 86,400 seconds (60 x 60 x 24), but in reality, it takes the Earth an extra millisecond or so to complete a full revolution. The amount of deviation isn’t constant— some days the Earth revolves faster and other days slower, depending on the season, earthquakes and a host of other natural processes.
Adjusting for leap seconds can cause headaches for different applications, so the SMPTE system does not use them. Instead, the clock used for measuring time from the SMPTE epoch increases linearly, with no leap seconds added.
UTC takes a different approach, and adds leap seconds whenever they are needed by designating a single day to last 86,401 seconds. The next leap second will occur at midnight UTC between June 30 and July 1, 2015. Before this date, the difference between TAI time and UTC is 35 seconds, and after this date it will be 36 seconds.
Over time, as more devices adopt these new standards, it will become much easier to synchronize clocks for video, audio and any other function in the studio. This could be an example of using time to save time.
Wes Simpson has recently developed classes for both IEEE BTS and SMPTE on IP Video as used in broadcast applications. Comments and questions are most welcome at wes.simpson@gmail.com.
Get the TV Tech Newsletter
The professional video industry's #1 source for news, trends and product and tech information. Sign up below.
Wes Simpson is President of Telecom Product Consulting, an independent consulting firm that focuses on video and telecommunications products. He has 30 years experience in the design, development and marketing of products for telecommunication applications. He is a frequent speaker at industry events such as IBC, NAB and VidTrans and is author of the book Video Over IP and a frequent contributor to TV Tech. Wes is a founding member of the Video Services Forum.