0
\$\begingroup\$

I think I understand synchronised data transmission between A and B. They share a synchronised clock signal that indicates when the transmitter is sending a bit and the receiver should read the value.

What I don't understand is asynchronised data transmission. I realise that there are start and stop bits and possibly a parity bit too but how does the receiver know when to "take readings" from the signal between the start and stop bits?

\$\endgroup\$
  • \$\begingroup\$ Depends on what protocol you're talking about. One of them wireless or more like multi-master I2C? \$\endgroup\$ – Mast Feb 7 '16 at 13:10
  • \$\begingroup\$ note that the term is not asynchronised but asynchronous. \$\endgroup\$ – Wouter van Ooijen Feb 7 '16 at 13:16
7
\$\begingroup\$

For the most common asynchronous serial communications the protocol requires the transmit and receive ends to agree on the data signalling rate and the data format. Format being an agreement between ends as to number of bits to expect from start bit through stop bit. Knowing this the receiver just has to synchronize itself on the leading edge of the start pulse. The receiver will also use a sampling clock that is a multiple of the agreed upon data signalling rate such as 16 times as fast. Then the receiver can count 8 clocks from the start bit edge and arrive at the center position of the start bit. From there the samples it takes every 16 clocks will be the data bit value for the expected number of bits. If the last one is not the expected level of a stop bit the receiver then knows to post an error.

I just described the simplest version. There are other receiver algorithms that will also see when the edges of the data changes occur within the start to stop bit interval and may shift their reference center position of the bit one clock either way in an attempt to track signalling distortion to some degree. Another scheme used is to sample the data three times around the bit center position and require that all three samples be the same. If not all the same the receiver posts an error as it realizes that the data is changing during the center time of the bit which indicates an out of sync situation.

\$\endgroup\$
  • \$\begingroup\$ So silly question but why is it called async when there is clearly synchronisation going on? \$\endgroup\$ – tommyd456 Feb 7 '16 at 13:14
  • 2
    \$\begingroup\$ Asynchronous (in this case) means that the clocks at transmitter and receiver need not be synchronized. \$\endgroup\$ – Wouter van Ooijen Feb 7 '16 at 13:15
  • \$\begingroup\$ So after each byte (after the stop bit) will syncing take place again between sender and receiver? \$\endgroup\$ – tommyd456 Feb 7 '16 at 13:22
  • 1
    \$\begingroup\$ The receiver will re-adjust (i.e. sync up) using the next start bit edge. This is the reason that the stop bit and start bit are the opposite levels so as to guarantee an edge to sync from. \$\endgroup\$ – Michael Karas Feb 7 '16 at 13:25
  • \$\begingroup\$ Do you know any advantages of async over synchronous data transmission? \$\endgroup\$ – tommyd456 Feb 7 '16 at 13:43
2
\$\begingroup\$

The receiver known when to sample the signal by mutual agreemnet on the bit rate (= baudrate, in this case). The receiver starts at the leading edge of the start bit, waits 1.5 bit times, samples, waits one bit time, samples, etc.

In reality receivers often oversample: they take 3 (or even more) samples and use majority voting.

This arrangement works only when

  • sender and receiver agree a-priory on the bit rate

  • sender and receiver have reasonably accurate clocks

  • the '0-time-moment' moment is re-establised periodically

For the common asynchronous format, the '0-time-moment' is re-estabilised at every start bit, and the a rule of thumb is that the clocks must be ~ 1% accurate.

Note that with sufficiently accurate clocks on both sides a hybrid between synchronous and asynchronous communication can be used: just one wire carries the data, and the occasional 'bit slip' is accepted. Telephone exchanges used to communicate this way, with a central master clock synchronyzing the other clocks.

\$\endgroup\$
1
\$\begingroup\$

There are at least three basic forms of asynchronous transmission.

1) The UART, (Universal Asynchronous Receiver/Transmitter) where the transmit and receive clocks are asynchronous, but both ends agree (by some out-of-channel means like baud rate setting instructions) to use approximately the same frequency.

The receiver detects a start condition (RXD going low), waits half an agreed bit period, and starts acquiring data. As long as the baud rates agree to better than +/-5%, this system can operate for 10 bit periods (start, 8 bits, parity) before losing synchronisation, and it needs to re-synchronise at the start of each new symbol (character, byte).

Oversampling is a typical refinement on this scheme.

2) Self-clocked schemes, where a clock signal is buried in the data itself. One example of this is "Manchester code" where every clock edge causes a transition (change in level), every '1' data bit does, every '0' bit does not. These can even operate in the absence of a pre-agreed baud rate, provided the receiver is allowed some short time to "learn" the clock rate from the data, and there is some convention for framing (such as the missing clock edges in the AES/EBU preambles).

8B-10B codes are another family of self-clocking codes, where each byte is converted to a 10 bit value with some specific characteristics (such as, approximately equal number of 0's and 1's for minimum DC content, no runs of more than 5 9's or 1's in a row) - guaranteeing there are enough edges to infer the clock rate. IBM patented one implementation in 1984, but another was in use by 1982 for digital video transmission over fibre optic link (sketchy details on p.6 here)

3) Handshaking, which requires two signals for handshaking as well as the data signals.

Each time the transmitter sets a bit, it also changes the state of its handshake signal (often called "Req" or Request). The receiver notices this change, accepts the data bit, and replies with a state change on its "Ack" or Acknowledge signal. This gives the transmitter permission to send the next bit.

In some respects, Req is similar to a clock line : however unlike a clock, there is no defined clock frequency or signalling rate, the transmission is reliable even if the receiver is busy and ignores its inputs for a while.

\$\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.