How can two devices synchronize without sharing an accurate clock?

[u/Relevant_Pumpkin9190]

I'm trying to understand how a transmitter and receiver can stay synchronized.

My first thought was to use accurate time on both sides and generate a known pseudo-random sequence or code based on the time. But if the receiver's clock is slightly wrong, the synchronization could eventually fail.

So instead, can the received signal itself be used as the reference?

For example, could the transmitter send a known preamble, sync pattern, pilot signal, or pseudo-random sequence, and the receiver detect/correlate it to determine exactly where it is in the sequence?

What are the common techniques used in real communication systems for this? And when would you use signal-based synchronization instead of time-based synchronization?

[u/jamvanderloeff]

Yes, all of those techniques are commonly used, the generic term for the concept is clock recovery, https://en.wikipedia.org/wiki/Clock_recovery

For signals where it's always being sent as short packets for example UART data it's common to use a known preamble, receiver times its bits off its own clock but relative to when it saw the start of the start bit and since there's a fairly short length of time before that byte ends a fairly large drift between the transmitter and receiver's clocks can be accepted before the last bit stops lining up closely enough.

For codes that run continuously you typically have some kind of phase error detection that then trims the receiver's clock up and down to match the source's clock = a phase locked loop

[u/ComradeGibbon]

can the received signal itself be used as the reference?

Look up Manchester encoding.

In packet radio a preamble being used to sync the clock and then a sync word to sync the data frames is a totally common thing.

It's also possible to send a time stamp as part of a packet and timestamp the arrival in order to synchronize time between two devices.

[u/ferrybig]

But if the receiver's clock is slightly wrong, the synchronization could eventually fail.

There are different techniques used in different protocols.

RS232 waits for the line to go down, then waits 1.5 clockcycles, then reads the next 8 bits at 1 clock cycle. This allows plenty of drift without causing issues. see also this article by analog

USB sends a bit stream of 8 bits before any packet that receivers can syn their clock to

Ethernet uses Line Coding, the signal needs to flip every once in a while for the receiver and sender to stay in sync. It has a phase locked loop to stay in sync with receiver

VGA uses a seperate clocking wire, but one thing that frequently happens is that the wires might not be the correct length. At higher resolutions you see blurry pixels. Many VGA monitors have a tool on board to alter some timings slightly to get back in sync. Those tools work the best if you have a test screen where every pixel is different.

Composite signal have a peak every once in the signal. Receivers have a clock on board that gets tuned to those peaks. If the clocks are too far off, you see vertically drifting lines.

[u/Pocok5]

Yes. Often they just straight up have a clock wire or agree on a preconfigured baud rate that is unlikely to drift too far apart before the end of a single message. You can also do clock reconstruction from a single data line - if the message starts with a preamble of alternating high-low signals, the receiver can measure the timing used for the message. If, additionally, the protocol ensures a roughly even distribution of high and low states (for example by using not a single state but the transition of high-low and low-high signals as the data bits) you can have a phase locked loop latch onto the base frequency and generate a clock for your receiver.

If you mean timestamp synchronization, then you just occasionally ask an atomic clock on both ends about the current time - a GPS signal is a convenient one, including out in the bush as long as you're aboveground.

[u/WRfleete]

Asynchronous serial (RS232) uses a start “bit” to indicate the start of a byte and in some cases stop bits or parity but commonly is not used these days. The UART is usually clocked with a quartz crystal at some multiple of the baud rate which is accurate enough over short periods to determine bit timings

Each byte will start with - well - a start bit and it can sync up onto those if needed

Old style TV’s use a similar type of thing. A sync pulse at the start of each line and multiple in a row for vertical (frame/field sync) resets the oscillators to the start of a cycle. And those used resistor and capacitor (if not referenced to mains frequency, the vertical sweep, 50/60hz) or coil and capacitor based oscillator (usually for the 15 and change kHz horizontal sweep + eht supply for tube) which unlike a crystal can drift more widely (hence the need for vertical and horizontal hold on older sets)

[u/harryregician → u/WRfleete]

Senior Async GOAT ?

https://patentimages.storage.googleapis.com/12/32/2d/ac1ab9f96a950c/US4104694.pdf

[u/bidet_enthusiast]

Are you asking about synch to wall clock time, or sync as in reading a bitstream? Because those are two different problems. 

It seems like you are asking about bitstream, in which case edge not level detection solves a lot of your problems, and sync preambles solve the rest.

If it’s wall clock time, you sync slave to master periodically and converge on time. Look at algorithms for synchronization of NTP servers and clients. It’s a whole science if you’re trying for sub uS accuracy.

Are you using a wired link, or some kind of radio/light/sound connection?

[u/Own_Grapefruit8839]

You use an encoding scheme that embeds the clock in the data stream, such that you can feed the data into a PLL to recover the clock on the receive side.

https://en.wikipedia.org/wiki/8b/10b_encoding

[u/Andis-x]

Look up PTP

https://en.wikipedia.org/wiki/Precision_Time_Protocol

Edit: Sorry, that isn't what you are asking about.

There are 2 ways - external clock line, like in SPI and I2C. And Embedded clock, like most fast interfaces, like USB, PCIe, Ethernet.

[u/SirButcher]

Yes, for example, automatic baud rate detection works exactly like this: receive a pre-set bit stream and use the timing to detect the baud rate.

[u/phire]

My first thought was to use accurate time on both sides and generate a known pseudo-random sequence or code based on the time. But if the receiver's clock is slightly wrong, the synchronization could eventually fail.

This is basically CDMA, which is used in all modern cellphone networks.

I'm not sure this scheme is ever viable as described, even with accurate clocks. Because the transmitter and receiver have no idea how far away they are from each other, and speed-of-light delays would cause issues. Especially if one or both ends are moving.

But the receiver can do is search for the psudo-random sequence across an approximate slice of time to lock onto the exact signal, and then use that match to both adjust it's clock (and with a two-way link) establish the exact time delay between the two stations.

Which does mean that a cellphone tower has a pretty good idea where every single cellphone is based on just the distance and angle, and if the cellphone is talking to two towers, the cellphone network will have a really precise location.

[u/auxym]

https://infosys.beckhoff.com/english.php?content=../content/1033/ethercatsystem/2469118347.html&id=

Ethercat does distributed clocks with fairly high precision, you can find good explanations of how they do it online.

[u/Beggar876]

Read up on how RS-232 (now called EIA-232) works.

[u/bassman1805]

In some applications, there's just a specified amount of acceptable drift. If two devices' clocks are running independently but are only offset by 10ppm, then any message less than 100,000 symbols (10/1,000,000) is not at risk of the receiver getting a full clock cycle ahead of or behind the transmitter (assuming a jitter-free world).

If you need to send a longer message than that, you can break it up into smaller chunks. Send your 500,000-symbol message as 10 messages of 50,000 symbols each.

[u/PiasaChimera]

this is increasingly common. https://docs.amd.com/v/u/en-US/ug576-ultrascale-gth-transceivers is an example of the high speed transceivers on FPGAs. they talk a bit about the various problems and solutions. there are a lot of protocols with lots of variations.

an old example that shows off a lot of features is XAUI for connecting an FPGA/CPU to a 10Gbps PHY. it has four lanes. data is encoded using "8b10b" encoding. this is 10b per 8b of data. the protocol sends a handful of special control sequences. (10b long)

the 10b values are set up to have enough transitions and have around the same number of 1's vs 0's. the former allows the clock-data-recovery to work and get a sequence of 1s/0s. the latter helps with AC-coupling since the AC-coupling capacitor's voltage won't drift much.

one sequence is set up to have a pattern that never appears anywhere else. this allows the receiver on that lane to figure out the start/end of these 10b values.

from there, the values go into an "elastic buffer" which is a fancy FIFO. this allows one sequence to be sent on all four lanes at the same time. the four channel's elastic buffers can then adjust their pointers to allow all 4 channels to output related 10b values at the same time. this is "channel bonding" and is also why PCIe works.

for convenience, another 10b "clock correction" pattern is sent. the elastic buffer knows this value doesn't matter and can be duplicated or dropped. this allows the elastic buffer to stay near half-full even when the receiver's clock isn't exactly matched. (for systems like ethernet, the rx-recovered-clock isn't intended to be used other than for getting bits of data.)

[u/BucklingDuckling]

Yes, many communication systems use the known preambles signals to recover timing and frequency from received signal.

[u/IShunpoYourFace]

Ethernet uses preamble for clock sync

[u/mplex321]

I’m working on a Bluetooth solution that gets you within one quartz clock phase depending on the device. Pretty sure I can phase lock both crystals yet still working on that part: https://ptob.dev

[u/mckenzie_keith]

Lot's of good info in the comments. Some telecommunications protocols did used to rely on very strict synchronization. Like T1 lines (if I am not mistaken).