Synchronization

Precise synchronization between show systems, especially those involving ride vehicles, is one of the biggest challenges faced in themed entertainment applications. Doing this properly involves achieving two critical conditions:

Phase-locked Clocks -- All clocks must operate at the same rate to avoid 'drifting' from one another
Precise Triggering - All systems must start playback simultaneously with extreme precision

The unique design of the SyncCore technology integrated into V16X, BinloopX, and RidePlayer enables these products to easily achieve both conditions and ensure precise synchronization between all on-board and off-board show systems throughout the entire attraction.

Phase-locked Clocks

Let's say you and a friend buy identical wristwatches and set both to the exact same time. When you meet up again a week later, you might be surprised to see that the watches are likely many seconds off from one another. Why? Well, there are many contributing factors such as crystal frequency precision, temperature, mechanical tolerance, etc. Bottom line... the watches run at slightly different rates and this difference compounds over time. The same concept also holds true with the audio and video clocks used as the basis for AV playback. Without a shared reference clock, all AV components will play at slightly different rates and drift from one another over time.

The solution to this problem is to phase-lock these clocks with each other. This generally involves one piece of equipment serving as the clock 'master' and distributing its clock to other 'slave' devices. The 'slave' devices then speed up or slow down their clocks to stay in perfect time with the 'master' device.

SyncCore allows AV clocks to be phase-locked by any of the following methods:

PTP (IEEE-1588)
GPS
Genlock

The graphic below demonstrates the benefits of phase-locked clocks. If you were to plot the framerate clocks of multiple devices on a graph, the alignment of unsynchronized clocks will be completely random and will drift from each other since they are free-running. Synchronized clocks, however, will be perfectly aligned and maintain that alignment at all times.

Precise Triggering via Time Lock

No matter how perfectly synchronized two clocks may be, it doesn't do much good if you can't start playback at the same time. To illustrate by example, let's walk through a typical dark ride system that requires synchronized on-board audio and wayside video. To keep things nice and simple, let's say we have an audio clip and a video clip of a certain length that are designed to be played synchronously with each other like so:

On-board Audio and Wayside Video Clips

If the on-board audio starts playing 300ms late, it's going to be off consistently for 300ms the entire time. There are several common factors that make this a challenging problem to contend with.

Playback Latency

First, most AV playback devices are not capable of triggering consistently upon command. This is especially true for PC-based hardware running operating systems that are often busy running unpredictable tasks. Let's say you send a command to play audio and playback begins about 100ms after the command is issued. Repeat this same process, and next time it might take 200ms. It is simply impossible to ensure synchronization between two (or more) devices when playback reaction time is not consistent.

When you combine this variable reaction time with variable network latency, you get very volatile results:

Network Latency + Inconsistent Playback Device

Network Latency

Specialized AV playback equipment can greatly improve this situation by offering consistent reaction time. Let's say that this equipment guarantees that playback will begin exactly 100ms after a command is received. The idea is that you send the same command to two different devices and they both start after exactly 100ms. Viola! They are synchronized! The catch is that those commands must be received by both devices at exactly the same time for this concept to work. This is quite challenging, especially via wireless networks where packet latency can easily exceed 100ms.

Network Latency + Consistent Playback Device

Scheduled Playback

To overcome these common problems, SyncCore enabled products take a unique approach. Some of the same clock references that are used to maintain phase-lock between on-board and off-board devices are also used to maintain a very precise master clock. In other words, all devices keep track of the current hour, minute, second, and millisecond with a precision as tight as a few nanoseconds. This time reference is often referred to as being locked to "Time of Day".

Sync Core allows Time of Day lock by any of the following methods:

PTP (IEEE-1588)
NTP
GPS

With this approach, playback times are scheduled based upon this shared master clock. This greatly reduces the impact of network latency because the time that the command arrives is irrelevant as long as it arrives long enough before the scheduled playback time to account for the consistent reaction time.

Here's how this concept affects device behavior to ensure perfect synchronization between two systems:

Scheduled Playback Time

System Architecture

Sounds great, right? But how do we actually implement this in a real application?

To answer that question with a pretty picture, here is a representation of a typical dark ride system that uses the Ride Control PLC as the PTP clock master for the entire attraction. In this example, the V16X, BinloopX, and RidePlayer would all be configured to lock directly to the PLC's master PTP clock to ensure perfect synchronization for all show systems throughout the attraction.

Notice how each device is precisely aware of the distributed clock value of 01:02:03.456.
As the controlling device in this example, the V16X will use this clock value to schedule the BinloopX and RidePlayers to play their content with extreme precision.

Sync Configuration

The SyncCore system is able to lock to any of the following from any of the following reference clocks:

PTP (IEEE-1588)
GPS
NTP
Genlock

Choosing a Sync Reference

Not all Sync Reference types are equal - some provide phase lock (to prevent drift), some provide time lock (to accurately schedule start times), and some provide both. Sync Reference choice depends on your system architecture and requirements.

PTP (IEEE-15888) - Phase Lock AND Time Lock
GPS - Phase Lock AND Time Lock
NTP - Time Lock
Genlock - Phase Lock

Because NTP only provides a Time Lock, Sync Core allows you to connect a Genlock source when in NTP mode for a combined NTP + Genlock mode. In this mode the A/V clocks are used from Genlock, and the time of day is used from NTP. When a valid Genlock source is connected while in NTP mode, the Sync Source displayed on the front panel of your device will read "NTP + Genlock".

Locking to a Sync Reference

Within your WinScript Live project, you can configure an external sync reference by accessing the Configuration-->Script menu option and browsing to the Clocks section. Here, you can choose the reference source you want this device to synchronize with and specify a master Frame Rate for the show control system.

If your application does not require the use of an external reference clock, you can leave this selection at its default value of None. In this mode, the product will generate its own clocks internally.

Distributing a Sync Reference

Not only can this product lock to an external sync reference, it is also capable of distributing sync references as well.

Genlock is always distributed automatically based upon the Frame Rate you have selected for the Master Clock. This is indicated in the Clocks section of the script configuration as well:

Keep in mind that not all frame rates are compatible with the video standards supported by the Genlock output circuit. Supported rates include 59.94, 50, 29.97, and 25 fps. If you choose any other frame rate, WinScript will indicate that the Genlock output is disabled like so:

There's also the option to distribute a clock via network using NTP or PTP. This setting is configured from the Clocks section of the script configuration screen which is accessed using the Configuration-->Script menu option.

As seen in the example above, it is possible for SyncCore-enabled devices to lock to an external reference and simultaneously distribute another type of reference. A common example of this would be configuring a V16X to lock to an external PTP Master (i.e. Ride Control PLC). This V16X may then need to synchronize precisely with RidePlayers over a wireless network which does not support PTP distribution. To overcome the limitations of the wireless network, the V16X could be configured to distribute a sync reference as an NTP Server. We would then configure the RidePlayer units to lock to the V16X via NTP.

The hybrid system architecture would look like this: