3
\$\begingroup\$

I am new to electrical engineering. Just a question on lack of synchronization problem. Below is a picture from my textbook:

enter image description here

I am very confused, time is unique to everyone in the world, so if both sender and receiver agree that, for example, the pattern of 0.001s represents a bit, so we won't have any synchronization problem any more, isn't it?

\$\endgroup\$
  • 2
    \$\begingroup\$ Yes, you're correct. "Absolute" synchronization to a time or frequency standard, e.g. UTC or 9600 baud, doesn't really matter. As long as the sender and receiver's clock agrees, there won't be synchronization problems. But for standardization, we use standard baud rates and frequencies. for serial communication, and calibrate all devices to this standard. \$\endgroup\$ – 比尔盖子 Oct 19 '19 at 7:49
  • 1
    \$\begingroup\$ The phrase "time is unique to everyone in the world" is exactly true. But since it means the opposite of the position you are arguing, it may not capture your intent. If everyone has their own unique time, how do any two people agree on the duration of anything? \$\endgroup\$ – Eric Towers Oct 20 '19 at 22:48
19
\$\begingroup\$

if both sender and receiver agree that, for example, the pattern of 0.001s represents a bit, so we won't have any synchronization problem any more, isn't it?

This would work in theory, however it requires both sender and receiver to have infinitely accurate clocks that will not drift relative to each other.

Real world clocks always have some inaccuracy and drift. Quartz oscillators are pretty good, especially considering how cheap they are, but they are not perfect. There is no perfectly accurate clock with zero drift.

Say your sender and receiver both use 1MHz +/-50ppm clocks. In the worst case, one clock will run at 1000050 Hz and the other at 999950 Hz, so you get 100ppm drift between the two.

The only practical way to have two synchronized clocks is to actually synchronize them by slaving one clock to the other.

Also, time is not "unique to everyone in the world" as you say. For example, relativity predicts that gravity influences time, so the frequency of a clock also depends on how far it is from Earth (ie, altitude)...

If the sender and receiver are communicating via radio, and they are moving, then a doppler shift will occur and transmission delay will change. For example if a cellphone transmits at 2GHz from inside a car moving at 100km/h away from the cell base station, then the frequency the receiver gets will be doppler-shifted by about 185 Hz. Also the transmission path length will change over time, which changes propagation delay. The receiver must account for this (among lots of other factors).

Even if you had two perfect clocks, propagation delay would still have to be accounted for, say when the user replaces a 1 meter HDMI cable with a 2 meter HDMI cable. That extra meter would add about 4.3ns delay (assuming 70% speed of light in the cable) corresponding to about 15 bits (per lane) at 3.4Gbps.

That's why clock is usually transmitted with data (either using its own wires or embedded in the signal) to allow the receiver to synchronize its local clock.

\$\endgroup\$
  • 4
    \$\begingroup\$ and if a device uses an RC oscillator instead of a quartz crystal, it gets way worse \$\endgroup\$ – ilkkachu Oct 20 '19 at 8:58
  • \$\begingroup\$ The propagation delay is irrelevant for that question, since it does not have an effect on the baud rate. It would be relevant for bidirectional communication, but that was not the question. \$\endgroup\$ – 12431234123412341234123 Oct 21 '19 at 11:15
  • \$\begingroup\$ Unless the receiver is a perfect device without setup & hold times, having proper timing alignment and delay (aka clock phase, so the edges end up in the right places) is just as relevant as baud rate for proper reception. \$\endgroup\$ – peufeu Oct 21 '19 at 13:22
12
\$\begingroup\$

You've touched on the answer in your question: "if both sender and receiver agree". The problem is, how do you ensure that they both agree? There are a few methods:

  1. Use a global clock, shared between all devices. Signals are then registered at the edge(s) of this clock. The design must ensure that the signals are at settled values for a specified time either side of the clock edge (setup/hold time).
  2. Agree a standard rate with some tolerance, with no clock shared between the devices. If both the sender and receiver are at the same rate within tolerance, then data can be sent successfully. There must be a signal that data transfer is commencing, and then the receiver can then register signals at the agreed rates.
  3. Embed the clock within the signal. An example is Manchester coding, which you'll can find in IR remote controls.
\$\endgroup\$
  • \$\begingroup\$ isn't that synchronization automatically apply?as the pictures in my post, the first picture of sender shows the signal pattern vs time , the receiver will receive the exact same picture of pattern vs time.so the sender says hey bro ,the interval of 0.001s represents a bit, then the receiver just needs to interpret bit in every 0.001s \$\endgroup\$ – secondimage Oct 19 '19 at 8:49
  • 4
    \$\begingroup\$ @secondimage Yes, this is the idea. But in practice, you cannot just say, "hey, let's use x seconds for a bit" and proceed. The timing accuracy and precision of the system is limited due to various imperfections. The first limitation is the tolerance of the clock oscillator itself, 0.001s or 1 Kbps is not a problem, but what happens when you run the link at 10 Mbps, when each bit only lasts 100 nanoseconds? If the clock oscillator has 1% error, it means the frequency is off by 0.1 MHz, and the receiver will receiver 100,000 corrupted bits for every 10,000,000 bits transmitted per second. \$\endgroup\$ – 比尔盖子 Oct 19 '19 at 9:21
  • \$\begingroup\$ @secondimage Second, many systems are controlled by software, and it imposes additional limitations. For example, imagine a hypothetical 8 MHz microcontroller which has an I/O instruction that takes 3 cycles to shift a bit, 4 cycles to output a bit to its GPIO, it means the serial communication cannot work faster than 1.14 Mbps, further, the time resolution is quantified, and can only be a multiple of 0.875 microseconds. If this system wants to communicate with another system which uses 5 microseconds to represent a bit, it gonna have some troubles. \$\endgroup\$ – 比尔盖子 Oct 19 '19 at 9:29
2
\$\begingroup\$

To get a sender and receiver to agree so that the receiver can accept valid data, the receiver has to know when the received data is valid for a given bit.

That can be done by distributing the clock to the receiver (as in SPI communication). So long as the signal and clock paths are similar enough in length that the clock edge and data arrive at close to the same time this will work well.

There are also asynchronous communication schemes where the receiver effectively recreates the clock locally from the data. Provided the receiver and sender have clocks that are close to each other in frequency (in the 1% range is good), a single 8-bit byte (perhaps 11 bits with parity and start/stop bits) can be reliably transmitted. For each succeeding byte the receiving side effectively re-synchronizes with the transmitter. Otherwise there would be a limit on how many characters could be transmitted in a row before the clocks got too much of a bit time out of sync.

\$\endgroup\$
2
\$\begingroup\$

We actually do this from time to time. However, the fundamental issue with "if you see this 0.001 second sample, it means a '1'" is that finding a sample is a lot harder than already knowing where to find it. You may need to sample several times faster than the data rate in order to get a clear picture of that millisecond sample. Meanwhile, a system which has achieved synchronization doesn't need this, so it can transmit data at a much higher rate.

Nowdays, its very common for the transmitter to embed a clock signal in the data. One of the more applicable methods use to do this is "comma codes" in 10/8 encoding. 10/8 encoding is a way of encoding 8 bits of logical data in 10 bits worth of data sent on the wire. It has some really nice properties, such as having no DC bias, which makes the physical hardware easy to build.

Comma codes are symbols that only appear at the end of a code word. 10/8 encoding uses symbols with 5 1s or 0s in a row -- data never has more than 4. Thus, if the receiver ever sees a period of high or low which is too long to be 4 bits, then it knows this must have been a comma code. It can then synchronize to it, and start reading data. Of course, this signal is 5x slower than the data it is embedded in, which makes it easier to pick up without having to sample at an incredibly high rate. Once that sequence is locked in, data is transmitted at the high rate.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.