When transmitting an image from a sender to a receiver some notion of synchronization is required. In the 1860s Giovanni Caselli invented the Pantelegraph (a fax) that used a pendulum clock to regulate the transmitter’s scanning stylus and the receiver’s writing stylus.
In our day, “black-burst sync” and “tri-level sync” were used to align video signals in a facility. Now with Ethernet/IP taking the reins, synchronization may be achieved with common nodal clocks. The essence is for a “slave node” to lock its clock to a “master node” clock. Common node clocks can be used to create sync as will be shown. The SMPTE ST 2059 family of standards and the IEEE-1588 V2 Precision Time Protocol (PTP) standard are the basis for facility clocking and signal synchronization using IP networks.
The fundamental metrics of synchronization are time, frequency and phasing. From Fig. 1, each node has an individual clock with a time of day (ToD with date) that is governed by a frequency source or “time base.” By way of example, the time base may be 60 cycles per second (Tp = 1/60) or some other constant value. The signal is shown as a sine wave, but other periodic signals will do. Clock 1 is typically locked to a GPS time source in some manner.
The focus of the diagram is to replicate the Node 1 time and frequency metrics inside Node 2 (or Node K) using only IP/Ethernet networking connectivity and associated protocols. There are no custom sync cables; all is network-based.
It turns out that if we can do this for clock time at Node 2, then frequency locking is straightforward.
There are two protocol methods needed to set Clock 2 based on Clock 1. The first step is for Node 2 to determine the Clock 1 time of Node 1. This process is sometimes called “time transfer.” This can be achieved by Node 2 asking Node 1: “Excuse me, do you have the time?” Node 1 responds with, “Yes, it’s ToD/Date.”
If the roundtrip network delay (ΔT) is zero and the nodal internal processing delays are likewise zero, then Node 2 could set the value of Clock 2 = Clock 1 precisely (the picture shows them offset at first). However, ΔT is not zero and is usually about 10–20 uSec or more. So, a second method is required. Node 2 first measures the roundtrip network transit delay and then corrects its Clock 2 value by ΔT/2 (one-way) to account for the offset.
Simplified view of a time transfer scenario
Click on the Image to Enlarge
The mechanism to measure ΔT is based on an echo of sorts. Imagine a hiker in a canyon hollering and listening for the echo. The time delay of echo receipt is proportional to the distance to the canyon wall. Likewise, if Node 2 asks Node 1 to “reflect” a ping command, then Node 2 can measure ΔT and thereby adjust its Clock 2 value from step 1. Simple! Not really.
The value of ΔT may change often based on network loading and other factors. Plus, the internal delays of the node’s operating system are not deterministic and this creates havoc for determining ΔT.
One way to improve the determination of ΔT is to measure it, say 32 times per second, then apply statistics to get a maximum likelihood value. Also, hardware timestamps can be generated in the network cards and switches to deterministically remove select “processing delays.” The Precision Time Protocol from the IEEE and SMPTE’s efforts have codified the algorithms, steps and settings to achieve time transfer in a media facility.
Is this mature? No, but it is the future and many vendors are beavering away on products and interoperability testing, (see wikipedia.org/wiki/Precision_Time_Protocol).
Each node has an internal time base (F_ source). This is the signal that sets the clock’s speed much like a 32,768 Hz quartz-based oscillator drives a wrist watch. After many repeated sequences to determine the ToD and ΔT values, Node 2 can slowly adjust F_source_2 to track F_source_1. This keeps Clock 2 neither slower nor faster than Clock 1. Ideally, Clock 2 can accurately free run even if the network connection is lost for hours.
Nodal clocks can be used for a variety of purposes including (1) timestamping of real-time media IP signals; (2) SMPTE timecode values; (3) controlling events at future time Tc; (4) logging events; (5) sync generation and more. Next, let’s discuss video sync creation.
How can a clock’s time/date values be used to generate a video sync signal? Imagine a periodic sync waveform that initially started precisely at midnight Jan. 1, 1970 (the Epoch time). Assume a frame rate of 60 per second. So, at 8 a.m. on the same day, exactly 28,800 (= 60*60*8) frames would have elapsed since midnight. So knowing when a signal starts allows its state to be known at any future time/date.
Assume a node desired to start generating a sync signal on Jan 1, 2016 at 8 a.m. The duration since the Epoch time would be 1,451,635,200 seconds. So the next frame’s starting sync time begins precisely at Jan. 1, 2016 at 8 a.m.
However, if the sync frame rate is not 60 but rather the common 59.94(…) then at 8 a.m. on Jan. 1, 2016, 87,011,100,899.1009 frames would have passed. So, the sync state is known and the next frame would begin about 15 ms after 8 a.m.
The key is defining the fixed Epoch time “when all periodic sync pulses start.” This is Jan. 1, 1970 at midnight as defined by SMPTE. So, no more black-burst; just precise time/date at all nodes in a system and each can create any frame/sync rate(s) as needed. Really, this is a thing of beauty.
This discussion is a simplified view of the processes to implement time transfer and sync creation. Of course, the details are more complex. Nonetheless, networked methods will become the basis for time and sync inside all media facilities coexisting with existing sync methods for several years.
Al Kovalick is founder of Media Systems consulting in Silicon Valley and a SMPTE Fellow. For a complete bio and contact information, visit www.theAVITbook.com.