why the sender's clock might not in the same pace with the receiver's clock

Question

I'm new to EE, sorry if my question is dumb. I was reading a text book which says:

To correctly interpret the signals received from the sender, the receiver’s bit intervals must correspond exactly to the sender’s bit intervals. If the receiver clock is faster or slower, the bit intervals are not matched and the receiver might misinterpret the signals. Below shows a situation in which the receiver has a shorter bit duration. The sender sends 10110001, while the receiver receives 110111000011.

I have two questions:

Q1. Since time is unique to anyone, how can one's clock is faster than others?

Q2. Why can't we tell each bit by the length it denote? Let's say e.g. one micrometer denotes a signal, so we can have a "ruler" to measure a complete wave length and work out every bit by the standard length?

Answer 1

The problem is not that time is the same, but how you measure time is different.

To follow along with your length analogy, suppose your ruler is slightly shorter on the receiver than it is on the sender. The length hasn't changed, however you might measure/interpret the lengths differently simply because you have a different ruler.

In electronics, often the clock is generated from vibrations of a small tuned crystal. Like everything else in this world, that crystal has manufacturing variations which will effect the frequency at which it oscillates, and consequently your measurement of time will change from one device to another.

You can reduce these variations by using a more accurate time measuring system, but this can get expensive quickly; you wouldn't want to put an atomic clock into every device just so you can essentially eliminate variations in time measurement!

The other way to solve this problem is to design your signalling protocol in such a way that it accounts for these variations. One such protocol is to simply have the sender also send you their clock signal so you can both use the same measurement system.

Answer 2

By default, no two (remote) clocks are synchronized. But they can be. Typically in a single-wire serial transmission as you have drawn here, the the falling edge denotes the beginning of the transmission. This is called a "start bit". The baud rate is generally set offline, although multi-wire protocols can infer a transmission rate. but you are talking single wire here. The first edge synchronizes a PLL (phase locked loop) which has a certain tolerance for jitter when generates the subsequent clock edges from the oscillator (oscillators are characterize error in parts per million ppm or parts per billion, which is tolerance). There can still be error, which is why single-wire asynchronous serial transmission often includes a parity bit in order to verify all 8 (or 7 or 9) bits were sent correctly, to an extent (parity can't do everything).

Does this help?

Answer 3

Since time is unique to anyone, how can one's clock is faster than others?

I'm not sure what you mean by "unique to anyone", but no two clocks match exactly, and the more you want them to match up, the more time, effort, money, and space it's going to cost -- on both ends of the link.

Why can't we tell each bit by the length it denote? Let's say e.g. one micrometer denotes a signal, so we can have a "ruler" to measure a complete wave length and work out every bit by the standard length?

You could, but that process would be noisy, because you'd only be "remembering" the time for one bit interval. There would also be difficulties in correctly interpreting long strings of ones or zeros. Clock synchronization schemes work on the idea that while the receiver clock may not match the transmitter clock, once synchronization is achieved that synchronization will hold over many bits. So with proper clock recovery (in other words -- bit clock synchronization) you can dramatically reduce the noise associated with the clock mismatch over just measuring individual bit times.

Answer 4

Two systems running on independent timebases cannot be guaranteed to be synchronized to each other. In broad terms then, some method of recovering the sender's clock timing needs to be devised to properly decode the data at the receiver.

There’s several approaches to the problem of not-synchronized senders and receivers.

One approach is to reconstruct a clock from information embedded in the data. That is, use a data coding scheme that has some kind of a recognizable pattern that a receiver can lock on to with its tuneable locally-synthesized clock. The receiver then periodically rechecks its alignment against this pattern and makes an adjustment to correct for any drift. Most high-speed serial links (like SATA, PCI Express, USB3) adopt this approach.

Another way is to send a separate timing reference - a source-generated clock that is synchronized to the data. That’s the approach used by HDMI and MIPI. It’s somewhat simpler to implement than the self-clocking methods used by SATA and PCIE, but it requires more wires and introduces skew issues.

Finally, there’s a brute-force variant of the first approach, which is to use markers between framing boundaries. UARTs use this method: the sender includes ‘start’ and ‘stop’ bits between bytes, which help the receiver re-align its bit timing state. The receiver sees the start bit, samples it with a 16x clock, then uses that edge to fix the sample point for the rest of the bits in a byte.

Manchester coding used in Ethernet works similarly, but at a bit-by-bit level. The sent data is XOR’d with the clock, guaranteeing a transition on every bit cell from which a receive clock can be recovered. While this scheme isn't very efficient bandwidth-wise, it is simple to decode using gates and delay lines.

Answer 5

It seems that the question is about UART communications, so the book is not completely right on this. The receiver and transmitter bit rates need not to be identical, they only need to match within certain tolerance in order for the receiver to be able to catch the transmitter data without error. For UART communications with certain nominal baud rate, if one device transmits with 1% too fast baud rate, and another device receives with 1% too slow baud rate, the transmission can still work.

A1 ) Devices, including clocks, have manufacturing tolerances. Many devices run on crystals which are commonly more accurate than 0.01%, some devices run on cheaper ceramic resonators which are typically only 0.5% accurate. Some devices run with their internal clocks, that may be only 2% accurate. So you really don't have same clocks for all devices, so they don't have the same sense of time.

A2 ) With some protocols that have some sort of line coding like Manchester, they can lock on to each transition. But UART communications has no such coding, UART devices have to be set to use the same baud rate, within the tolerance, and the receiver uses only the falling edge of the start bit as a signal when to start sampling the 8 data bits at their assumed midpoints.