I'm having a hard time understanding the exact distinction between synchronous and asynchronous serial because different sources have confusing description.

For example, some source say a separate clock wire is required in synchronous, some do not mention a separate clock but a SYN character instead. Some source say asynchronous requires start and stop bits, some say not necessarily as long as there is only a pair of wire.

So my question:

1) Is clock wire always needed in synchronous serial? If not, how do we synchronize?

2) When we say asynchronous, does it always mean we use start and stop bits? If not, how do we synchronize?


You might care for a simpler answer:

  1. Synchronous means one side sends a clock signal that both sides use to clock the bits. Most truly synchronous serial communications can run with uneven bit times (ie, you just get a data bit when the clock says, and there is no timing information at all. Also you can use "third-party clocks", if both sides have access to some shared clock.)
  2. Asynchronous means each side uses its own timers wait a period and then to clock each bit. The most common variety uses start bits to align the phase at the beginning of each transmitted word.
  3. Self-clocking means a system such as Manchester encoding, which gives a recoverable clock and data in the same wire. You can consider this to be a variety of synchronous (because one side is sending the clock), or a variety of asynchronous (because the clock recover uses the receiver's gross timer to recover the fine timer.)

I'm using "clock" in the specific sense of shift a bit into (or out of) a shift register, nothing to do with time directly. I'm using "timer" to mean a mechanism which measures an interval measured in seconds (or fractions).

So, directly:

  1. Yes, a synchronous serial system always has a shared clock
  2. Yes, an asynch serial system always uses start edge of some kind, normally made from start bits and variable-length stop periods (of a given minimum time, the number of stop bits)

Is clock wire always needed in synchronous serial? If not, how do we synchronize?

As far as I'm concerned you can send data synchronously by either using an external clock signal or modifying the data stream to contain a clock signal à la Manchester encoding or data scrambling to keep the bit changes ticking over.

When we say asynchronous, does it always mean we use start and stop bits? If not, how do we synchronize?

Asynchronous transmission always needs a start bit so that (for example) the UART receiver can have enough time to sort itself out and calculate where the middle of the data symbol is so that it can sample the data stream at the most optimum point for minimal error. Stop bit(s) are also required as are transmission breaks i.e. sending a continuous stream of asynchronous data can mean never being able to have a receiver sync up to that data. Having a transmission break that is longer than one byte means the receiver can sync up.

However, for synchronous transmissions, frame markers are usually required that are embedded into the data in order to provide a sync reference. It's not just about aligning the bits but also aligning the message.

I'm having a hard time understanding the exact distinction between synchronous and asynchronous serial

There is no exact definition. What's the exact difference between butter and margarine for instance.

  • \$\begingroup\$ Butter is cream that's been beaten for long enough to separate. Margarine is a mixture of oils with water, which have been hydrogenated. So, these are pretty well-defined, unlike what synchronous serial and asynchronous serial are ;) \$\endgroup\$ Mar 18 '20 at 8:40
  • \$\begingroup\$ You can make butter from Goat milk too. \$\endgroup\$
    – Andy aka
    Mar 18 '20 at 9:01
  • \$\begingroup\$ Wouldn't you make it from Goat milk cream? \$\endgroup\$ Mar 18 '20 at 9:06
  • \$\begingroup\$ @Andy aka "Asynchronous transmission always needs a start bit" In practice yes. But one can imagine an application which just pick the data at a random, and doesn't require precision timing or have other mean of adjusting. \$\endgroup\$
    – Fredled
    Mar 18 '20 at 9:08
  • \$\begingroup\$ @Fredled in practice, no. There's enough line receivers that just look for specific words within the data and shift stuff in bit-wise until they've found a sensible start, instead of using dedicated start symbols. I think you're thinking too much in terms of PC-style serial ports! \$\endgroup\$ Mar 18 '20 at 9:24
  1. In the most simple configuration, Yes. There must be a wire to share clock pulses between two devices. In this case the clock frequency can be anything and even irregular. In more advanced systems, there are other ways to share the clock pulse or its timing without adding a wire, explained int he other answers.

  2. No: Start and stop bits are just a convention on how to decode the incoming serial data. They separate bytes. It doesn't depend wether it's synchronous or not. You can use no start or stop bit, if you want, or you can create your own convention. This is done in software. But the one start bit, 8 bits, one stop bit, no parity bit aka 8N1 is the most commonly used. The stop bit, is in practice, a return to iddle state at the end of transmition or a bit preceding the next start bit between two bytes. Both the emitter and reciever must share and understand the same format.

  • \$\begingroup\$ 1. No; that's not the case. PCIe is a synchronous serial link, but can (doesn't have to) work without a clock line. \$\endgroup\$ Mar 18 '20 at 8:41
  • \$\begingroup\$ @Marcus Müller How do you define synchronous and asynchronous then? My definition of synchronous is when the clock pulse is shared be the two devices. \$\endgroup\$
    – Fredled
    Mar 18 '20 at 8:59
  • \$\begingroup\$ see my answer. I specifically defined it there. \$\endgroup\$ Mar 18 '20 at 9:06
  • \$\begingroup\$ @Marcus Müller According to Wikipedia, every communication is synchronous as soon as both clock run at the same rate (and clock pulse adjusted). That's indeed a valid interpretation. But then every digital communication is sychronous. Isn't it? How do you make digital transfer with different clock frequencies? \$\endgroup\$
    – Fredled
    Mar 18 '20 at 9:27
  • \$\begingroup\$ no, that's not what wikipedia says: it says that the receiver clock needs to be synchronized, which means that it should have been subject to a synchronization to the transmitter. \$\endgroup\$ Mar 18 '20 at 9:29

Is clock wire always needed in synchronous serial?

So, from wikipedia:

Synchronous communication requires that the clocks in the transmitting and receiving devices are synchronized – running at the same rate – so the receiver can sample the signal at the same time intervals used by the transmitter.

So, what you need is synchronous clocks, not necessarily a clock signal.

If not, how do we synchronize?

There's plenty of ways to keep synchronization. In fact, synchronization is among the most diverse things you'll find in digital communication schemes – so, I really can't list all the things systems do to synchronize. There's just too many different approaches, and a lot of them really only make sense in the very narrow use case of a specific system.

Instead, let's talk about a few typical, or extreme things.

For lower rate things, simply having a good common time base works – whether it's something you've got from GPS, or something you got by having been equipped with a quartz crystal and a battery.

Often, clock synchronization is done based on the signal's shape you're receiving. Remember that no real-world signal has ever infinitely steep edges, because that would require infinite bandwidth (and that would require infinite power. Also, real-world systems are practically always low-pass systems).

So, instead, if you know about that problem, you start shaping your pulses, e.g. instead of trying to send -1 V for a symbol period followed by +1 V for a symbol period, you start smoothing out with a filter. You do that in a controlled way! (You might want to google "eye diagram" to see what that looks like for high-speed serial buses.)

Now, your receiver has something to work with: whenever you have a symbol switch (and that should, in our 1 symbol = 1 bit scheme practically be as common as not switching, so pretty often), you get a nice slope between your last and your next symbol. If you average a bit, you'll see that you only get a nice maximum or minimum, i.e. zero derivative, when you look at the signal at the right point in time. If you're a bit too early (or too late), you'll notice by always being a bit on the slope instead of "top of the hill", so you can correct for that.

A system that finds the correct times to evaluate the signal from the signal itself is called timing recovery. What I described above is one of a lot of methods of dealing with that – others involve preambles, feedback, simply testing multiple delays, …

That's half of what you need to be synchronous. The other half is having the right clock frequency. Such problems are very often solved by means of removing the actual data from the transmission (in our +1V/-1V example above, simply square the voltage), and then looking for periodicities and using these, e.g. in a PLL (like your 1980's car radio proudly boasted a "PLL" label, the Phase-Locked Loop is just a way to train a local oscillator based on the average speed of the transmitter's oscillator). Other methods involve preambling with a clean tone, superimposing a tone at a frequency that you can remove with a filter so it doesn't mess with your data signal, autocorrelation methods, and many, many more.

So, as you can see, many different ways to deal with that problem, and in the world of baseband communications, you use different things (e.g. Manchester coding) than in the RF comms world (e.g. Schmidl&Cox sync for OFDM).

When we say asynchronous, does it always mean we use start and stop bits?

No. It's just a convenient way of telling your receiver that transmission starts (stops) now. Depending on the application, this might be something you want, or something you don't need.

If not, how do we synchronize?

Not at all, that's the point: your receiver just runs and doesn't get to recover the "beat" of your transmitter from a clock signal or the data signal it's getting. The assumption is that this just works, because there's enough "leeway" in the signal.

For example, if I send a bit as symbols of +1 or -1 V, with a symbol rate of 1 sym/minute, even you as human won't need access to my clock at all – you just start looking at the voltage I send. Chances that you're looking exactly at the point where I switch symbols are very low. Chances that your wristwatch is so inaccurate that you'll lose (or gain) more than a minute relative to my wristwatch within the say 16 bits I want to send are so low that you can live with that.


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.