Patent Description:
For example, in managing time at increasingly smaller scales, problems associated with clock drift take on more complexity in distributed computing in which several computers need to realize the same global time to function properly. Further, clock synchronization is important for accurate reproduction of streaming media, particularly when using multiple input and output devices.

In a system with a central controlling server, the server may dictate the system time in a hub-and-spoke arrangement. Cristian's algorithm and the Berkeley algorithm may be used to resolve clock drift and achieve clock synchronization in this environment. In a distributed system, clock synchronization is more complex as a singular controlling global time is not easily known.

The most used clock synchronization technique used over the Internet is the Network Time Protocol (NTP), which is a layered client-server architecture based on user datagram protocol (UDP) message passing and round-trip time (RTT) measurement thereof. NTP can reduce synchronization offsets to times in the order of a few milliseconds over the public Internet, and to sub-millisecond levels over local area networks. Simple Network Time Protocol (SNTP) and Precision Time Protocol (PTP) are master/slave synchronization protocols used over local area networks and similarly based around RTT measurement of UDP messages or other data packets between the master and the slave devices.

<CIT> describes methods and apparatus for implementing time synchronization across exascale fabrics which may provide useful background to the present disclosure. <CIT> and <CIT> also describe time synchronization networks and methods which may provide useful background to the present disclosure.

Implementations described and claimed herein provide a clock synchronization network comprising a master device and a slave device. The master device includes master timing circuitry to generate a master timing reference and a data output to transmit the master timing reference on a dedicated data channel. The slave device includes a data input to receive the master timing reference on the dedicated data channel and slave timing circuitry to synchronize a slave timing reference to the master timing reference using a constant delay over the dedicated data channel. The slave timing circuitry configured to synchronize the slave timing reference to the master timing reference using a snapshot of the master timing reference transmitted over the dedicated data channel and a fixed known delay for a data packet containing the snapshot to be transmitted between the master device and the slave device.

Implementations described and claimed herein further provide a method for synchronizing a slave device to a master device comprising: generating a master timing reference using master timing circuitry, transmitting the master timing reference from the master device outbound over a dedicated data channel, receiving the master timing reference with a constant delay from the master device to the slave device over the dedicated data channel, and synchronizing a slave timing reference of the slave device to the master timing reference using the constant delay over the dedicated data channel. Said synchronizing comprises using a snapshot of the master timing reference transmitted over the dedicated data channel and a fixed known delay for a data packet containing the snapshot to be transmitted between the master device and the slave device.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Descriptions.

In a wireless network, managing clock drift becomes even more challenging due to the possibility of collision of synchronization packets on the wireless medium and the higher drift rate of clocks on low-cost wireless devices. The Reference Broadcast Time Synchronization (RBS) algorithm, in which an initiating device broadcasts a reference message to urge receiving devices to adjust their clocks, is used in wireless networks and sensor networks. However, the individual clock adjustments as still based around an RTT measurement of the reference message between the initiating and the receiving devices.

It is difficult for prior art clock synchronization techniques based around the RTT measurement to achieve extremely high precision (e.g., within one time tick (resolution of the clock source), which could be +/- <NUM> microsecond in an implementation that utilizes a <NUM> clock source) due to variance of RTT over time, particularly over the Internet or using shared device hardware and/or software.

With increasing expectations of clock synchronization accuracy, as well as widespread use of wireless data networks, the presently disclosed technology provides a dedicated clock synchronization network that yields a fixed delay between hops and within associated devices of a dedicated clock synchronization network. By accounting for the known delays between hops and within associated devices of the dedicated clock synchronization network, better clock synchronization accuracy can be achieved than prior art techniques that estimate latency based on an RTT measurement. Further, synchronization may be achieved in wireless ad hoc networks through sending synchronization messages in a multi-hop manner with each subsequent node progressively synchronizing with the node that is the immediate sender of a synchronization message using an additive delay based on the total number of hops between nodes.

Master/slave is a model of asymmetric communication or control where one device (master device) controls one or more other devices (slave devices) and serves as their communication hub. A master device as described herein provide a master timing to slave devices. Slave devices as described herein receive the master timing reference and adjust their corresponding slave timing references to match.

A variety of computing devices (e.g., laptop computers, personal computers, gaming devices, smart phones, smart TVs, wireless speakers, projectors, and microphones, and other devices that carry out one or more specific sets of arithmetic and/or logical operations) may utilize the clock synchronization networks and signals disclosed in detail herein.

<FIG> illustrates an example dedicated wireless clock synchronization network <NUM> to synchronize a slave device <NUM> to a master timing reference <NUM> broadcast from a master device <NUM>. The master device <NUM> includes a master timing element (e.g., a crystal oscillator <NUM> or electronic oscillators such as microcontrollers and phase-locked loop (PLL) circuits), which generates an electrical signal Xm with a precise known frequency. Xm is input into a master control unit <NUM> (MCU, also referred to herein as master timing circuitry) that includes a software-configurable timer or a phase-locked loop, for example, to generate the master timing reference <NUM>. The master timing reference <NUM> is output to various components or peripherals of the master device <NUM> for coordinated operation of the master device <NUM>.

The slave device <NUM> (and other slave devices connected to the network <NUM>) includes a slave crystal oscillator <NUM>, which generates an electrical signal Xs, also with a precise known frequency. The electrical signal Xs is similar to the electrical signal Xm but generated independently from the master crystal oscillator <NUM> by the slave crystal oscillator <NUM>. Xs is input into a slave control unit <NUM> (SCU, also referred to herein as slave timing circuitry) that also includes a software-configurable timer or a phase-locked loop, for example, to generate a slave timing reference <NUM>. The slave timing reference <NUM> is output to various components or peripherals of the slave device <NUM> for coordinated operation of the slave device <NUM>.

Due to the effects of clock drift, the master timing reference <NUM> and the slave timing reference <NUM> may diverge from one another over time. In implementations that require coordinated operation of the master device <NUM> and the slave device <NUM>, an increasingly unsynchronized timing between the devices <NUM>, <NUM> is problematic.

The master timing reference <NUM> may be periodically broadcast via a wireless radio transmitter (or transceiver) and associated antennae <NUM> into the wireless clock synchronization network <NUM>, via data output <NUM>. In various implementations, the master timing reference <NUM> may be a timestamp or the slave control unit <NUM> may recover the master timing reference <NUM> from an incoming packet rate. Further, the wireless clock synchronization network <NUM> utilizes a dedicated data channel <NUM> for the master timing reference <NUM> (e.g., a specified frequency band within an existing device-to-device network, or an entirely separate network. Still further, the wireless clock synchronization network <NUM> may include other components such as access points, proxies, gateways and so on so long as overall latency over the wireless clock synchronization network <NUM> is constant.

In some implementations, the wireless clock synchronization network <NUM> may be within a frequency band shared with other device functionality within an existing device-to-device network so long as a guaranteed bandwidth is available within the wireless clock synchronization network <NUM> when the master timing reference <NUM> is to be sent out. For example, burst transmissions (e.g., via a time-division multiple access (TDMA) approach) having other functionality within a wireless network may be sent out between periodic transmissions of the master timing reference <NUM>. Further, additional data could be combined with the periodic transmissions of the master timing reference <NUM> to serve additional functionality. As a result, the wireless clock synchronization network <NUM> may co-exist on a wireless network used for other purposes.

One or more slave devices (e.g., the slave device <NUM>) are also connected to the wireless clock synchronization network <NUM> via wireless radio receivers (or transceivers) and associated antennae (e.g., receiver and antennae <NUM>). The wireless clock synchronization network <NUM> may operate on the dedicated data channel <NUM> exclusively for clock synchronization or share an existing wireless network with guaranteed bandwidth for the master timing reference <NUM>, as discussed above. In various implementations, the master timing reference <NUM> may be referenced to an outgoing packet timestamp from the master device <NUM> (see e.g., <FIG>), an incoming packet rate to the slave device <NUM> (see e.g., <FIG>), or other timing and/or delay reference point. While depicted in <FIG> and described as a wireless local area network, in other implementations the clock synchronization network <NUM> may be a wired local area network. In various implementations, the slave device <NUM> and the master device <NUM> are directly connected to the wireless clock synchronization network <NUM>, as shown (also referred to as a direct wireless connection, or a wireless connection).

When the master timing reference <NUM> is received by the slave device <NUM> at data input <NUM>, the slave timing reference <NUM> is adjusted by the slave control unit <NUM> to match that of the master timing reference <NUM>, including incorporating a predetermined correction factor based on at least the fixed known delay over the dedicated channel operating on the wireless clock synchronization network <NUM> between the devices <NUM>, <NUM> and without an RTT measurement specific to the devices <NUM>, <NUM>. This yields the timer/PLL of each of the devices <NUM>, <NUM> in sync with an extremely high timing synchronization accuracy.

In an example implementation, the crystal oscillators <NUM>, <NUM> generate electrical signals Xm, Xs at <NUM> megahertz and the associated timing circuitry <NUM>, <NUM> counts time ticks output from the crystal oscillators <NUM>, <NUM>, which occur every microsecond for a <NUM> megahertz oscillator. As a result, the dedicated wireless clock synchronization network <NUM> can achieve extremely high timing synchronization accuracy, which may be within +/- <NUM> microsecond in the context described herein.

<FIG> illustrates an example synchronization timeline <NUM> for synchronizing a slave device <NUM> to a timing reference broadcast from a master device <NUM> using a timestamp. The master device <NUM> includes a master crystal oscillator, which generates an electrical signal Xm with a precise known frequency. Xm is input into a master control unit to generate a master timing reference <NUM>. The master timing reference <NUM> is output to various components or peripherals of the master device <NUM> for coordinated operation of the master device <NUM>.

Similarly, the slave device <NUM> includes a slave crystal oscillator, which generates an electrical signal Xs with a precise known frequency. Electrical signal Xs is similar to electrical signal Xm but generated independently from the master crystal oscillator by the slave crystal oscillator. Xs is input into a slave control unit to generate a slave timing reference <NUM>. The slave timing reference <NUM> is output to various components or peripherals of the slave device <NUM> for coordinated operation of the slave device <NUM>.

For purposes of illustration, the master and slave crystal oscillators are running at <NUM>. <NUM> timer outputs based on the master and slave crystal oscillators are treated as the master timing reference <NUM> and the slave timing reference <NUM>, respectively. Each of the <NUM> timers of the timing references <NUM>, <NUM> register a state change every <NUM> crystal ticks. The master and slave timing references <NUM>, <NUM> are synchronized when their respective timers are reset to <NUM>, but due to manufacturing and environmental variances, the master and slave timing references <NUM>, <NUM> may diverge over time (e.g., though designed to operate at <NUM>, the slave crystal oscillator may actually operate at <NUM>).

In this example, the master control unit includes a timing snapshot capture function (and associated module) that captures a timing snapshot <NUM> of the master timing reference <NUM> at a predetermined value (here, <NUM> crystal ticks). The timing snapshot <NUM> includes at least a crystal tick value but may also include additional information relevant to the master device <NUM> and/or the slave device <NUM>. While the timing snapshot <NUM> occurs at <NUM> crystal ticks, in other implementations, the timing snapshot <NUM> may occur at any number of crystal ticks and at any predetermined frequency (e.g., every <NUM> crystal ticks or every <NUM> crystal ticks), which is application-dependent (e.g., what level of precision is desired and at what rate to the master and slave timing references <NUM>, <NUM> diverge).

The captured timing snapshot <NUM> at <NUM> crystal ticks is transmitted to the slave device <NUM> over a dedicated clock synchronization channel for use in adjusting the slave timing reference <NUM> to match the master timing reference <NUM>. This includes incorporating a predetermined correction factor or constant delay <NUM> (here, <NUM> crystal ticks) based on at least a fixed known delay of the dedicated channel operating on the clock synchronization network between the devices <NUM>, <NUM>, but without an RTT measurement specific to the devices <NUM>, <NUM>. In various implementations, the constant delay <NUM> may be set at the factory and saved to the slave device <NUM> or pre-set in the field at the slave device <NUM> for the specific pairing of the master device <NUM> and the slave device <NUM>.

In this example, the constant delay <NUM> is calculated as a combination of an internal processing delay <NUM> at the master device <NUM> (e.g., a time required to process the timing snapshot <NUM> and send it outbound to the dedicated clock synchronization channel as outgoing packet <NUM>) equal to <NUM> crystal ticks. Further, an additional <NUM> crystal ticks are added to compensate for the transit time between the master device <NUM> and the slave device <NUM> over the dedicated clock synchronization channel and time required for the slave device <NUM> to receive and timestamp the incoming captured timing snapshot <NUM>. The constant delay <NUM> is predetermined and pre-tested to remain constant for the time required for a captured timing snapshot <NUM> to be received by the slave device <NUM> and is known by the slave device <NUM> to perform a timing adjustment. In some implementations, the constant delay <NUM> is known only to the master device <NUM> and is transmitted as part of the captured timing snapshot <NUM>. In other implementations, the constant delay <NUM> is also known by the slave device <NUM> and is not necessarily transmitted with the captured timing snapshot <NUM>.

In this example, the slave device <NUM> receives the captured timing snapshot <NUM> known to be captured at <NUM> crystal ticks at the master device <NUM>. The slave device <NUM> also knows that its timestamp on receipt of the captured timing snapshot should equal <NUM> crystal ticks (capture timer value: <NUM> + constant delay: <NUM>). The slave device <NUM> compares the expected timestamp on receipt of the captured timing snapshot (<NUM> crystal ticks) with the actual timestamp <NUM> of receipt of the captured timing snapshot (here, <NUM> crystal ticks), resulting in a clock drift error of <NUM> crystal ticks. The slave control unit within the slave device <NUM> then directs the slave timing reference <NUM> to toggle its next state change <NUM> crystal ticks earlier than it would otherwise (e.g., at adjusted state change <NUM>, which is <NUM> crystal ticks = <NUM>-(<NUM>+<NUM>-<NUM>)), which yields an adjusted slave timing reference <NUM> that is synchronized to the captured timing snapshot of the master device <NUM>. In the illustrated case of a <NUM> slave timing reference <NUM>, the adjusted slave timing reference <NUM> is reset to <NUM> crystal ticks at <NUM> rather than <NUM> crystal ticks.

Following the reset of the slave timing reference <NUM> to adjusted slave timing reference <NUM>, the adjusted slave timing reference <NUM> will start to drift again yielding a time disparity that is resolved by periodic subsequent captured timing snapshots at a sufficiently high packet rate. In other implementations, the subsequent captured timing snapshots are not periodic. For example, the subsequent captured timing snapshots could be pseudorandom or defined by available bandwidth on the master device <NUM> and/or the clock synchronization network. The timing of subsequent captured timing snapshots may also be based on a detected error rate, an application state on the master device <NUM>, or other considerations. These are repeatedly used to adjust the slave timing reference to maintain synchronization with the master device <NUM> (e.g., to prevent the time disparity from exceeding a tolerance specific to the application). In some implementations, the tolerance is used to determine a captured timing snapshot rate.

In various implementations, the features of <FIG> offer specific technical performance benefits to the disclosed timing synchronization systems and methods. Specifically, the timing snapshot <NUM> permits a periodic reset of the slave timing reference <NUM> to the adjusted slave timing reference <NUM>, and at a regular or irregular rate that maintains synchronization with the master device <NUM> within a tolerance specific to the application. The predetermined correction factor (also referred to herein as constant delay <NUM>) is predetermined and pre-tested to remain constant for the time required for a captured timing snapshot <NUM> to be received by the slave device <NUM> and is known by the slave device <NUM> to perform a timing adjustment. The predetermined correction factor is used in place of an RTT measurement, which has various disadvantages as discussed above. The predetermined correction factor includes a constant delay based on at least a fixed known delay of the dedicated channel operating on the clock synchronization network between the devices <NUM>, <NUM>, including but not limited to processing within the devices <NUM>, <NUM> and a delay over the clock synchronization channel, but without an RTT measurement specific to the devices <NUM>, <NUM>.

<FIG> illustrates another example synchronization timeline <NUM> for synchronizing a slave device <NUM> to a timing reference <NUM> (in the form of outgoing timing packets <NUM>) periodically broadcast from a master device <NUM> at a predetermined packet rate. The master device <NUM> includes a master crystal oscillator, which generates an electrical signal Xm with a precise known frequency. Xm is input into a master control unit to generate the master timing reference <NUM>. The master timing reference <NUM> is output to various components or peripherals of the master device <NUM> for coordinated operation of the master device <NUM>.

The master control unit includes an outgoing packet transmission feature that sends the outgoing timing packets <NUM> over a dedicated clock synchronization channel for use in adjusting the slave timing reference <NUM> to match the master timing reference <NUM>. The outgoing timing packets <NUM> are sent at a known (to at least the slave device <NUM>) packet rate (here, every <NUM> crystal ticks), however, the packet rate can be at any predetermined frequency (e.g., every <NUM> crystal ticks or every <NUM> crystal ticks, for example), which is application-dependent (e.g., depending upon what level of precision is desired and at what rate the master and slave timing references diverge). In various implementations, some of the outgoing timing packets <NUM> are lost during transmission. Some packet losses can be tolerated by not applying a correction when a packet gets lost.

The slave control unit within the slave device <NUM> includes a timing feedback control module (e.g., a proportional-integral-derivative (PID) controller) that compares measured crystal ticks between received timing packets <NUM> to the known packet rate of the timing reference <NUM>. The slave control unit then adjusts the slave timing reference <NUM> to match that of the outgoing timing packets <NUM> over time. For example, as shown in <FIG>, the outgoing timing reference <NUM> packet rate is set at <NUM> crystal ticks. However, the first outgoing timing packet <NUM> is received at <NUM> crystal ticks at the slave device <NUM>. If <NUM> of <NUM> crystal ticks is outside an acceptable synchronization tolerance between the devices <NUM>, <NUM>, this triggers the slave control unit to run a synchronization algorithm to adjust the slave timing reference <NUM> over time.

Specifically, the timing feedback control module adjusts its next <NUM> crystal ticks to restart at <NUM> rather than <NUM> to compensate for the accumulated clock drift and expected future clock drift. Subsequent timing packets <NUM> direct the timing feedback control module to adjust its next three <NUM> crystal tick periods to restart at <NUM>, <NUM>, and <NUM>, sequentially to iteratively synchronize the slave timing reference <NUM> to the master timing reference <NUM>. At synchronization point <NUM>, the slave timing reference <NUM> is synchronized to the master timing reference <NUM> and subsequent crystal tick periods to restart at <NUM> until synchronization between the devices <NUM>, <NUM> again falls outside an acceptable synchronization tolerance. This again triggers the slave control unit to run the synchronization algorithm to again adjust the slave timing reference <NUM> over time.

To the extent that the slave timing reference <NUM> remains synchronized to the master timing reference <NUM>, following <NUM> crystal tick periods restart at <NUM> for the slave timing reference <NUM> to adjust for expected future clock drift only. The timing packets <NUM> are repeatedly used to adjust the slave timing reference <NUM> to maintain synchronization with the master timing reference <NUM> to prevent the time disparity from exceeding the tolerance specific to the application. This tolerance is predetermined to yield the captured timing snapshot rate.

While synchronized in frequency, the master timing reference <NUM> and the slave timing reference <NUM> may not be edge aligned, which indicates that they are out of phase following the aforementioned packet rate adjustment at the slave device <NUM>. To achieve approximate edge alignment, the slave device <NUM> may utilize the moment of packet reception to edge-align with the master timing reference <NUM>, optionally accounting for a known fixed transmission delay.

<FIG> and <FIG> are not drawn to scale. Clock drift may be exaggerated from that which would likely occur in practice to illustrate the technical solution. In various implementations, the outgoing packet <NUM> of <FIG>, and subsequent output packets, as well as the timing packets <NUM> of <FIG> are sent out via a dedicated data channel. The dedicated data channel permits latency of receipt of the packets to be relatively constant, which allows the present application to perform timing adjustments without an RTT measurement.

<FIG> illustrates a dedicated wireless clock synchronization network <NUM> of slave speakers <NUM> synchronized to a master speaker <NUM>. In an example implementation, the speakers <NUM>, <NUM> form a fully synchronized multi-channel surround wireless speaker system. The master speaker <NUM> generates a master timing reference and the slave speakers <NUM> similarly generate slave timing references. Due to the effects of clock drift, the master timing reference and the slave timing references will diverge from one another over time. In implementations that require coordinated operation of the master speaker <NUM> and the slave speakers <NUM>, such as synchronized audio output, an increasingly unsynchronized timing between the speakers <NUM>, <NUM> is problematic.

The master timing reference is periodically broadcast via a wireless radio transmitter and associated antennae into the wireless clock synchronization network <NUM>. The slave speakers <NUM> are also connected to the wireless clock synchronization network <NUM> via wireless radio receivers and associated antennae (or transceivers). The wireless clock synchronization network <NUM> may operate on a dedicated channel exclusively for clock synchronization. In other implementations, the wireless clock synchronization network <NUM> may share an existing wireless network with guaranteed bandwidth for the master timing reference. In various implementations, the master timing reference may be referenced to an outgoing packet timestamp from the master speaker <NUM> (see e.g., <FIG>), an incoming packet rate to the slave speakers <NUM> (see e.g., <FIG>) or other timing reference point. While depicted in <FIG> and described as a wireless local area network, in other implementations the clock synchronization network <NUM> may be a wired local area network.

When the master timing reference is received by the slave speakers <NUM>, the slave timing references are adjusted to match that of the master timing reference, including incorporating a predetermined correction factor based on at least the fixed known delay of the dedicated channel operating on the wireless clock synchronization network <NUM> between the speakers <NUM>, <NUM> and without an RTT measurement specific to the speakers <NUM>, <NUM>.

<FIG> illustrates a dedicated wireless clock synchronization network <NUM> of slave microphones <NUM> synchronized to a master microphone <NUM>. In an example implementation, the microphones <NUM>, <NUM> form a fully synchronized array of microphones to capture audio from a user <NUM>. In some implementations, the microphones <NUM>, <NUM> utilize sound source localization (SSL) to estimate the location of the user <NUM> using relative time delay of sound arriving at each of the microphones <NUM>, <NUM>. The more accurate clock synchronization of the microphones <NUM>, <NUM>, the more accurate the SSL can be.

The master microphone <NUM> generates a master timing reference and the slave microphones <NUM> similarly generate slave timing references. Due to the effects of clock drift, the master timing reference and the slave timing references will diverge from one another over time. In implementations that require coordinated operation of the master microphone <NUM> and the slave microphones <NUM>, such as synchronized audio input, an increasingly unsynchronized timing between the microphones <NUM>, <NUM> is problematic.

The master timing reference is periodically broadcast via a wireless radio transmitter and associated antennae into the wireless clock synchronization network <NUM>. The slave microphones <NUM> are also connected to the wireless clock synchronization network <NUM> via wireless radio receivers and associated antennae (or transceivers). The wireless clock synchronization network <NUM> may operate on a dedicated channel exclusively for clock synchronization. In other implementations, the wireless clock synchronization network <NUM> may share an existing wireless network with guaranteed bandwidth for the master timing reference. In various implementations, the master timing reference may be referenced to an outgoing packet timestamp from the master microphone <NUM> (see e.g., <FIG>), an incoming packet rate to the slave microphones <NUM> (see e.g., <FIG>) or other timing reference point. While depicted in <FIG> and described as a wireless local area network, in other implementations the clock synchronization network <NUM> may be a wired local area network.

When the master timing reference is received by the slave microphones <NUM>, the slave timing references are adjusted to match that of the master timing reference, including incorporating a predetermined correction factor based on at least the fixed known delay of the dedicated channel operating on the wireless clock synchronization network <NUM> between the microphones <NUM>, <NUM> and without an RTT measurement specific to the microphones <NUM>, <NUM>.

<FIG> illustrates a dedicated wireless clock synchronization network <NUM> of slave cameras <NUM> synchronized to a master camera <NUM>. In an example implementation, the cameras <NUM>, <NUM> form fully synchronized streams from the independently recording cameras <NUM>, <NUM>. In some implementations, the cameras <NUM>, <NUM> are used to output seamless camera feed transitions, seamless image stitching, and/or depth sensing, each of which operates more seamlessly with a more accurate clock synchronization of the cameras <NUM>, <NUM>.

The master camera <NUM> generates a master timing reference and the slave cameras <NUM> similarly generate slave timing references. Due to the effects of clock drift, the master timing reference and the slave timing references will diverge from one another over time. In implementations that require coordinated operation of the master camera <NUM> and the slave cameras <NUM>, such as synchronized video output, an increasingly unsynchronized timing between the cameras <NUM>, <NUM> is problematic.

The master timing reference is periodically broadcast via a wireless radio transmitter and associated antennae into the wireless clock synchronization network <NUM>. The slave cameras <NUM> are also connected to the wireless clock synchronization network <NUM> via wireless radio receivers and associated antennae (or transceivers). The wireless clock synchronization network <NUM> may operate on a dedicated channel exclusively for clock synchronization. In other implementations, the wireless clock synchronization network <NUM> may share an existing wireless network with guaranteed bandwidth for the master timing reference. In various implementations, the master timing reference may be referenced to an outgoing packet timestamp from the master camera <NUM> (see e.g., <FIG>), an incoming packet rate to the slave cameras <NUM> (see e.g., <FIG>) or other timing reference point. While depicted in <FIG> and described as a wireless local area network, in other implementations the clock synchronization network <NUM> may be a wired local area network.

When the master timing reference is received by the slave cameras <NUM>, the slave timing references are adjusted to match that of the master timing reference, including incorporating a predetermined correction factor based on at least the fixed known delay of the dedicated channel operating on the wireless clock synchronization network <NUM> between the cameras <NUM>, <NUM> and without an RTT measurement specific to the cameras <NUM>, <NUM>.

The presently disclosed technology is applicable to a variety of audio and/or video input and/or output devices, as provided in <FIG> and detailed descriptions thereof. The presently disclosed technology may further be applicable to a variety of devices outside of the audio and/or video context. For example, distributed computing applications often require a high level of synchronization between computing devices. Further, in testing or manufacturing environments with multiple sensors and complex feedback control mechanisms, a high sampling rate and synchronization within the time space may be required to coordinate sensor results within a rapidly changing system (e.g., in autonomous cars, industrial automation and control systems, aviation systems, smart homes, surveillance systems, and so on). More generally, any application that requires a particularly high sampling rate and/or synchronization within the time space may benefit from the presently disclosed technology.

The presently disclosed technology may utilize a dedicated communication channel, along with dedicated processing power to achieve a substantially fixed latency without an RTT measurement. In various implementations, the dedicated communication channel and dedicated processing power are implemented in exclusively hardware and/or firmware. Further, software may be used to reserve processing power and/or bandwidth within shared hardware resources to achieve a similarly substantially fixed latency without dedicated separate hardware resources and without the RTT measurement.

The presently disclosed technology may use a programmable logic block that interconnects independent peripherals with a fixed latency. Example representative programmable logic devices are field programmable gate arrays (FPGAs) and complex programmable logic devices (CPLDs). Synthesis of the hardware logic block may mandate prescribed timing behavior, which ensures the fixed latency by design. Further, some microcontroller architectures support autonomous peripheral operation that mimic the operation of FPGAs and CPLDs, which could be used to implement the presently disclosed technology. Hardwiring the events and tasks of independent internal peripherals can achieve minimized latency. Once configured at bootup, an event generated by a peripheral can autonomously trigger another peripheral with a fixed latency without the intervention of any processing elements.

In various implementations, the dedicated wireless side channel described herein may be implemented using already-present radios in master and slave devices so long as the radios support a constant-time implementation and have the capability of sharing existing radio resources for the clock synchronization. For example, Wi-Fi chipsets and communication stacks may support ad hoc network construction, and Bluetooth chipsets and communication stacks may render full control over the radios and other restricted peripherals to a user.

The dedicated wireless side channel described herein may be extended to multi-hop dedicated networks at the expense of accumulating error per each hop (e.g., a <NUM>-hop network may have an approximately five time tick precision). Multi-hop networks may employ a broadcast-based managed flooding technique, wherein each retransmission subtracts a constant retransmission processing delay from the timestamp before relaying. For example, an indicator may be embedded within the master timing reference to indicate the number of hops taken, and perhaps a maximum number of hops (e.g., via a countdown from the maximum).

<FIG> illustrates example operations <NUM> for synchronizing a slave device to a master device. A generating operation <NUM> generates a master timing reference using master timing circuitry. A transmitting operation <NUM> transmits the master timing reference from the master device to a dedicated data channel. In some implementations, the dedicated data channel is a wireless data channel and transmitted using a wireless radio transmitter.

A receiving operation <NUM> receives the master timing reference over the dedicated data channel from the master device. In some implementations, the dedicated data channel is a wireless data channel and received using a wireless radio receiver. The received master timing reference has a fixed known delay which is caused by delays within one or more of the master device, the dedicated data channel, and the slave device.

A synchronizing operation <NUM> synchronizes a slave timing reference to the master timing reference using a correction factor based on the fixed known delay. In some implementations, the synchronizing operation <NUM> uses a snapshot of the master timing reference and a predetermined delay for a data packet containing the timing snapshot to be transmitted between the master device and the slave device. In other implementations, the synchronizing operation <NUM> uses a known packet rate of a series of incoming packets from the master device containing the master timing reference. The operations <NUM> may iteratively and automatically repeat to continuously synchronize the slave device to the master device.

<FIG> illustrates example hardware and software that can be useful in implementing the described technology. The master and/or slave devices disclosed herein may be remote control devices and/or physically controlled devices and are networkconnected and/or network-capable devices and may be client devices, such as laptops, mobile devices, desktops, tablets, server/cloud devices an internet-of-things devices; electronic accessories, or other electronic devices, for example.

The master and/or slave devices disclosed herein may each include a system board <NUM>, upon which a variety of microelectronic components for the device are attached and interconnected. For example, the system board <NUM> may include one or more processors <NUM> (e.g., discrete or integrated microelectronic chips and/or separate but integrated processor cores, including but not limited to central processing units (CPUs) and graphic processing units (GPUs)) and at least one memory device <NUM>, which may be integrated into systems or chips of the device. The master and/or slave devices may also include storage media <NUM> (e.g., a flash or hard disk drive), one or more display(s) <NUM>, and other input/output (I/O) devices <NUM>. The input/output (I/O) devices <NUM> may permit a user to may enter commands and information (e.g., via a keyboard or mouse). These and other input devices may be coupled to the server by one or more I/O interfaces <NUM>, such as a serial port interface, parallel port, and/or universal serial bus (USB).

The memory device(s) <NUM> and/or the storage media <NUM> may include one or both of volatile memory (e.g., random-access memory (RAM)) and non-volatile memory (e.g., flash memory or magnetic storage). An operating system <NUM>, such as one of the varieties of the Microsoft Windows® operating system, resides in the memory device(s) <NUM> and/or the storage media <NUM> and is executed by at least one of the processor(s) <NUM>, although other operating systems may be employed. One or more additional applications <NUM> are loaded in the memory device(s) <NUM> and/or the storage media <NUM> and executed within the operating system <NUM> by at least one of the processor(s) <NUM>.

The system board <NUM> may further include a (or be connected to an external) power supply <NUM>, which is powered by one or more batteries or other power sources and provides power to the system board <NUM> and an associated master and/or slave device. The power supply <NUM> may also be connected to an external power source that overrides or recharges the batteries.

The system board <NUM> may further include one or more communication transceivers <NUM>, which may be connected to one or more antenna(s) <NUM> to provide network connectivity (e.g., mobile phone network, Wi-Fi®, Bluetooth®) to one or more other servers and/or client devices (e.g., mobile devices, desktop computers, or laptop computers). The system board <NUM> may further include a network adapter <NUM>, which is a type of communication interface. The system board <NUM> may use the network adapter <NUM> and any other types of communication devices for establishing connections over a widearea network (WAN) or local-area network (LAN). The master and/or slave devices described herein may each include a communication transceiver <NUM> connected to an antenna <NUM> to send and/or receive a master timing signal over a dedicated wireless side channel. The network connections shown are exemplary and that other communication devices and means for establishing a communications links between master and/or slave devices may be used.

The master and/or slave devices may include a variety of tangible computer-readable storage media (e.g., the memory device(s) and the storage media device(s)) and intangible computer-readable communication signals. Tangible computer-readable storage can be embodied by any available media that can be accessed by the master and/or slave devices and includes both volatile and non-volatile storage media, as well as removable and non-removable storage media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Tangible computer-readable storage media includes, but is not limited to, RAM, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium which can be used to store the desired information and which can be accessed by the master and/or slave devices. Tangible computer-readable storage media excludes intangible communications signals.

Intangible computer-readable communication signals may embody computer readable instructions, data structures, program modules or other data resident in a modulated data signal, such as a carrier wave or other signal transport mechanism. By way of example, and not limitation, intangible communication signals include signals traveling through wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio-frequency (RF), infrared (IR), and other wireless media.

Some embodiments may comprise an article of manufacture. An article of manufacture may comprise a tangible storage medium to store logic. Examples of a storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or rewriteable memory, and so forth. Examples of the logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one embodiment, for example, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and/or operations in accordance with the described embodiments. The executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented according to a predefined computer language, manner or syntax, for instructing a computer to perform a certain operation segment. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

Some embodiments of the invention described herein are implemented as logical steps in one or more computer systems. The logical operations are implemented (<NUM>) as a sequence of processor-implemented steps executing in one or more computer systems and (<NUM>) as interconnected machine or circuit modules within one or more computer systems. The implementation is a matter of choice, dependent on the performance requirements of the computer system implementing the invention. Accordingly, the logical operations described herein are referred to variously as operations, steps, objects, or modules. Furthermore, the logical operations may be performed in any order, adding or omitting operations as desired, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.

An example clock synchronization network according to the presently disclosed technology comprises a master device and a slave device. The master device includes master timing circuitry to generate a master timing reference and a data output to transmit the master timing reference on a dedicated data channel. The slave device includes a data input to receive the master timing reference on the dedicated data channel and slave timing circuitry to synchronize a slave timing reference to the master timing reference using a predetermined delay over the dedicated data channel.

In another example clock synchronization network according to the presently disclosed technology, the slave timing circuitry synchronizes the slave timing reference to the master timing reference using a snapshot of the master timing reference and a predetermined delay for a data packet containing the snapshot to be transmitted between the master device and the slave device.

In another example clock synchronization network according to the presently disclosed technology, the slave timing circuitry synchronizes the slave timing reference to the master timing reference using a known packet rate of a series of incoming packets from the master device containing the master timing reference.

In another example clock synchronization network according to the presently disclosed technology, the master timing circuitry includes an oscillator that serves as a reference for a timer that generates the master timing reference.

In another example clock synchronization network according to the presently disclosed technology, the slave timing circuitry includes an oscillator that serves as a reference for a timer that generates the slave timing reference, and wherein the slave timing circuitry is to synchronize the slave timing reference by adjusting an oscillator count for toggling the slave timing reference.

In another example clock synchronization network according to the presently disclosed technology, the predetermined delay includes delays at one or more of: the master device, the slave device, and the dedicated data channel.

In another example clock synchronization network according to the presently disclosed technology, the slave timing reference is synchronized to the master timing reference without a round-trip time (RTT) measurement.

In another example clock synchronization network according to the presently disclosed technology, the dedicated data channel is a direct wireless connection between the master device and the slave device.

In another example clock synchronization network according to the presently disclosed technology, the dedicated data channel is a wired connection between the master device and the slave device.

Another example clock synchronization network according to the presently disclosed technology further comprises a second slave device. The second slave device includes a data input to receive the master timing reference on the dedicated data channel from the slave device and slave timing circuitry to synchronize a second slave timing reference to the master timing reference with a correction factor based on the predetermined delay over the dedicated data channel and a number of hops from the master device to the second slave device.

In another example clock synchronization network according to the presently disclosed technology, the master device is a component of an autonomous car and the slave device is a sensor on the autonomous car.

In another example clock synchronization network according to the presently disclosed technology, the master device and the slave device are each one or both of audio and video devices.

In another example clock synchronization network according to the presently disclosed technology, precision of synchronization of the slave timing reference to the master timing reference is within one time tick.

In another example clock synchronization network according to the presently disclosed technology, the master timing reference is generated by an application executing on the master device.

In another example clock synchronization network according to the presently disclosed technology, the master timing reference is generated at a rate that is based on a desired precision of an application executing on the slave device.

An example method for synchronizing a slave device to a master device according to the presently disclosed technology comprises generating a master timing reference using master timing circuitry, transmitting the master timing reference from the master device outbound over a dedicated data channel, receiving the master timing reference with a predetermined delay from the master device to the slave device over the dedicated data channel, and synchronizing a slave timing reference of the slave device to the master timing reference using the predetermined delay over the dedicated data channel.

In another example method for synchronizing a slave device to a master device according to the presently disclosed technology, the synchronizing operation uses a snapshot of the master timing reference and a predetermined delay for a data packet containing the snapshot to be transmitted between the master device and the slave device.

In another example method for synchronizing a slave device to a master device according to the presently disclosed technology, the synchronizing operation uses a known packet rate of a series of incoming packets from the master device containing the master timing reference.

In another example method for synchronizing a slave device to a master device according to the presently disclosed technology, the dedicated data channel is a wireless connection between the master device and the slave device.

Another example clock synchronization network according to the presently disclosed technology comprises a master device and a slave device. The master device includes master timing circuitry to generate a master timing reference and a wireless radio transmitter to transmit the master timing reference with a fixed known delay on a dedicated wireless data channel. The slave device includes a wireless radio receiver to receive the master timing reference on the dedicated wireless data channel and slave timing circuitry to synchronize a slave timing reference to the master timing reference with a correction factor based on the fixed known delay.

Claim 1:
A clock synchronization network (<NUM>) comprising:
a master device (<NUM>; <NUM>; <NUM>) including:
master timing circuitry (<NUM>) configured to generate a master timing reference (<NUM>); and
a data output (<NUM>) configured to transmit the master timing reference (<NUM>; <NUM>; <NUM>) on a dedicated data channel (<NUM>); and
a slave device (<NUM>; <NUM>; <NUM>) including:
a data input (<NUM>) configured to receive the master timing reference (<NUM>; <NUM>) on the dedicated data channel (<NUM>); and
slave timing circuitry (<NUM>) configured to synchronize a slave timing reference (<NUM>; <NUM>; <NUM>) to the master timing reference (<NUM>; <NUM>; <NUM>) using a constant delay (<NUM>) over the dedicated data channel (<NUM>), wherein the slave timing circuitry (<NUM>) is configured to synchronize the slave timing reference (<NUM>; <NUM>; <NUM>) to the master timing reference (<NUM>; <NUM>; <NUM>) using a snapshot (<NUM>) of the master timing reference (<NUM>; <NUM>; <NUM>) transmitted over the dedicated data channel (<NUM>) and a fixed known delay for a data packet containing the snapshot (<NUM>) to be transmitted between the master device (<NUM>; <NUM>; <NUM>) and the slave device (<NUM>; <NUM>; <NUM>).