RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
Wiki Home
View source

Personal Tools

Search the Wiki


Asynchronous vs Synchronous

The following was quoted/adapted from the 'Digital Review' column titled "Asynchronous vs Synchronous - Whats the Difference?" by Day Watson WUN0407 Aug 1998 (c) Worldwide Utility News

Basic RTTY is an asynchronous structure. It is not necessarily continuous but may operate in a start/stop mode. Each character, usually 5 bits is encapsulated by a leading START bit, and terminated by 1 or more STOP bits. The STOP period may not be whole bit elements, 1.5 stop bits being common. Timing is achieved on individual characters, the receiver seeing the Stop/start transition and, counting off clocks, strobes the subsequent data bits midpoint (assuming the transmit and receive clocks running exactly the same rate. Timing synchronisation will be repeated on the next stop/start transition irrespective of whether the data is coming down the line nose-to-tail or randomly.

Assuming we have a 7.5 bit character frame. This is 5 bits of data, and 2.5 bits total of START and STOP elements. From this we see that 33% of the transfer time is completely wasted from an information transfer point of view.

From this we move to synchronous where the data does not have start and stop bits, and we have no half/partial length elements or bit cells. All are equal. For a given baud rate we can squeeze in more characters in a given time. But what of determining where the characters start in a continuous bit stream? The characters may be ERECT or INVERTED. This is basically the same as the NORMAL/REVERSED terminology discussed last month under data passage through a communications system. Where (under CCITT);

  • The low frequency represents data bit 1, data is NORMAL or ERECT
  • The low frequency represents data bit 0, data is REVERSED or INVERTED.

In asynchronous RTTY the signal will either be Normal, or Reversed, all the time.

In synchronous systems one discusses the aggregate signal. Say the system is ARQ/E - here there is 1 character in 4 (or 1 in 8) which is "marked". This is achieved by having 3 characters (or 7) ERECT and the "marked" character INVERTED. With the majority of characters in the bit stream being ERECT then the aggregate signal is said to be ERECT.

The software handling the data reception will be able to sense the change between erect and inverted characters and use this as part of its synchronising procedures in determining the start of a character. Synchronisation is achieved by taking 7 bit blocks (assuming a 7 bit character structure) and testing with consecutive bits down the data stream as the start point proceed until a valid character (erect or inverted) is recognised. Thereafter checking that each subsequent 7 bit block is a valid character.

Note that the time to reach synchronisation depends on the baud rate in use and on the type of transmission - some with their inbuild error correcting being more complex than others and therefore take longer.

What happens if the data stops flowing because the operator stops typing? The system doesn't fall over - if no data is available from the source ie operator or files from a computer the transmitting modem stuffs a filling or packing character into the datastream in lieu. This is famous BETA character. Other than enabling a led or other display when there is a predominance of the BETA control character in the data stream the character is processed as any other character for the purposes of error correction, but not passed to line as data.

What About Other Modes?

Burst mode systems eg Sitor/A, ARQ/S, ARQ/6, ARQ/Swed etc. These operate with synchronous data. Here the timing can be taken from the leading edge of the burst. Again use is made of a padding character as a fill to maintain the data flow in the absense of traffic.

Decoders will usually pick up automatically on whether the aggregate signal is ERECT or INVERTED and start decoding.

From the 'Digital Review' column by Day Watson WUN0407 Aug 1998 (c) Worldwide Utility News

Copyright 2017 by LLC Privacy Policy  |  Terms and Conditions