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?


5 Answers 5


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\$ Commented Mar 18, 2020 at 8:40
  • \$\begingroup\$ You can make butter from Goat milk too. \$\endgroup\$
    – Andy aka
    Commented Mar 18, 2020 at 9:01
  • \$\begingroup\$ Wouldn't you make it from Goat milk cream? \$\endgroup\$ Commented Mar 18, 2020 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
    Commented Mar 18, 2020 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\$ Commented Mar 18, 2020 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\$ Commented Mar 18, 2020 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
    Commented Mar 18, 2020 at 8:59
  • \$\begingroup\$ see my answer. I specifically defined it there. \$\endgroup\$ Commented Mar 18, 2020 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
    Commented Mar 18, 2020 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\$ Commented Mar 18, 2020 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.


I think the key to tell the difference between synchronous and asynchronous is to understand what synchronous mean. I will try to explain it.

Being synchronous means the 2 parties has a shared timing schema. And each party does its work at a fixed action point in this timing schema.

(Actually this is not quoted from anywhere. I just use quote to make it more eye-friendly)

For example, in below graph, at the clock falling edge, sender always sends the data, and at the rising edge, the receiver always attempts to sample the data. The sender and receiver do their work only according to the clock. They don't care about each other. It is the shared timing (in this case, the common clock signal) and the fixed action point in this schema that make both parties work in harmony.

I think there are other ways to convey this shared timing info besides an explicit clock wire. So sometimes you don't see a clock wire. (If anyone has a concrete example, please feel free to edit my reply and add it. Thanks.)

(Picture from: Serial Port Complete)

sync comm

For asynchronous,

There's no such shared timing and thus nor fixed point in the timing schema.

In below graph, the sender and receiver do their work according to their internal clocks. They only follow their own cadence. So it is no surprise that if the 2 timings don't match each other and the whole thing become a mess. That's why you see wild characters in a terminal when baud rate is not configured the same on both sides.

(Picture from: Serial Port Complete)

async comm

From: here

Baud Rate Mismatch


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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