HighDots.NET Computer Hardware Forums  

why 1,1.5 or 2 stop bts are necessary for asynchronous serail communication

Peripheral Devices Peripheral Devices Discussions (comp.periphs)


Discuss why 1,1.5 or 2 stop bts are necessary for asynchronous serail communication in the Peripheral Devices forum.



Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old   
archana
 
Posts: n/a

Default why 1,1.5 or 2 stop bts are necessary for asynchronous serail communication - 08-23-2006 , 01:28 AM






hi all,
why is that 1.5 or 2 stop bits are required for transmission when only
1 start bit is enough?and the second question is what does 1.5 bit
mean? why are these stop bits dependent upon the word length we are
gonna transmit? how is the syncronization achieved by transmitting more
number of stop bits? thank u


Reply With Quote
  #2  
Old   
glen herrmannsfeldt
 
Posts: n/a

Default Re: why 1,1.5 or 2 stop bts are necessary for asynchronous serailcommunication - 08-23-2006 , 02:39 AM






archana wrote:

Quote:
why is that 1.5 or 2 stop bits are required for transmission when only
1 start bit is enough?and the second question is what does 1.5 bit
mean? why are these stop bits dependent upon the word length we are
gonna transmit? how is the syncronization achieved by transmitting more
number of stop bits? thank u
(comp.arch removed, since it doesn't really apply)

Google or Wikipedia for ASR33.

Stop bits are needed to keep synchronized even if the clocks
are a little off, and in case the connection is made in the
middle of the character. One is enough to do that, but some
need more time to get ready for the next character.

-- glen



Reply With Quote
  #3  
Old   
Jeff Jonas
 
Posts: n/a

Default Re: why 1,1.5 or 2 stop bts are necessary for asynchronous serail communication - 08-23-2006 , 03:24 AM



Quote:
why is that 1.5 or 2 stop bits are required for transmission when only
1 start bit is enough?and the second question is what does 1.5 bit
mean? ...
Stop bits are indistinguishable from the idle-line-condition.
It's a manditory minimum time the line goes back to idle,
first of all for the receiver to assure the character was received properly
(a "framing error" results if the stop bit is not received). (*)
But it also gives the receiving device time to act on the character received,
thus the "1.5 stop bit" for mechanical printers
(which used rotary contacts and mechanical latches
for receiving the data, before semiconductor UARTS).
And even then, additional time delays were required
for long actions such as carriage return and line feed
(which still exist in the Unix/Linux "stty" command
in case of real serial links to physical terminals).

(*) that's probably how a BREAK condition is distinguished
from receiving a 0xff character:
the character is received without a framing error,
a break condition probably causes reception of 0xff WITH frame error.
--

-- mejeep deMeep ferret!


Reply With Quote
  #4  
Old   
jsavard@ecn.ab.ca
 
Posts: n/a

Default Re: why 1,1.5 or 2 stop bts are necessary for asynchronous serail communication - 08-23-2006 , 10:25 AM



archana wrote:
Quote:
why is that 1.5 or 2 stop bits are required for transmission when only
1 start bit is enough?and the second question is what does 1.5 bit
mean? why are these stop bits dependent upon the word length we are
gonna transmit? how is the syncronization achieved by transmitting more
number of stop bits?
The first terminals to use a start-stop serial bit transmission
protocol operated at low baud rates, and they were mechanical devices.

Thus, while they might have used 40ms to transmit each bit, they might
have instead used 60ms for the stop bit - one and a half times as much.

These terminals used a 5-bit code; so it is *historical*.

The mechanical terminals using an 8-bit code used a faster baud rate,
transmitting more bits in the same time, to fit in 8 bits while still
printing the same number of characters per second. So they needed two
stop bits, because while the baud rate was faster, the machinery in the
terminals moved at the same speed.

Then came along electronic terminals - and, *of course*, as your own
instincts properly told you, only one stop bit would ever be needed for
them.

John Savard



Reply With Quote
  #5  
Old   
Bob McConnell
 
Posts: n/a

Default Re: why 1,1.5 or 2 stop bts are necessary for asynchronous serail communication - 08-23-2006 , 07:40 PM



On 23 Aug 2006 08:25:03 -0700, jsavard (AT) ecn (DOT) ab.ca wrote:

Quote:
archana wrote:
why is that 1.5 or 2 stop bits are required for transmission when only
1 start bit is enough?and the second question is what does 1.5 bit
mean? why are these stop bits dependent upon the word length we are
gonna transmit? how is the syncronization achieved by transmitting more
number of stop bits?

The first terminals to use a start-stop serial bit transmission
protocol operated at low baud rates, and they were mechanical devices.

Thus, while they might have used 40ms to transmit each bit, they might
have instead used 60ms for the stop bit - one and a half times as much.

These terminals used a 5-bit code; so it is *historical*.

The mechanical terminals using an 8-bit code used a faster baud rate,
transmitting more bits in the same time, to fit in 8 bits while still
printing the same number of characters per second. So they needed two
stop bits, because while the baud rate was faster, the machinery in the
terminals moved at the same speed.

Then came along electronic terminals - and, *of course*, as your own
instincts properly told you, only one stop bit would ever be needed for
them.

John Savard
The early teleprinters had a governed motor, so the speed was not
always precise. Even a correctly adjusted governor would be a few rpm
off, and who knew whether it was fast or slow? As the motor aged, the
variation increased until it was time to adjust them again.

So the long stop bit was there to allow the slowest printers to catch
up with the faster transmitters. Later models had a synchronous motor,
which was as accurate as the line frequency it was powered from. Even
then, mobile units like ships and aircraft still varied a bit. But
they were able to cut the stop bit back to 1.5 or even 1.42 bit
lengths, which at seven bits per character (five data, start, stop)
made a significant difference even at 45.5 bps.

Bob McConnell
N2SPP
Ex-RM2: TTY Repairman - NFIT, NLM



Reply With Quote
  #6  
Old   
David Brown
 
Posts: n/a

Default Re: why 1,1.5 or 2 stop bts are necessary for asynchronous serailcommunication - 08-24-2006 , 02:05 AM



archana wrote:
Quote:
hi all,
why is that 1.5 or 2 stop bits are required for transmission when only
1 start bit is enough?and the second question is what does 1.5 bit
mean? why are these stop bits dependent upon the word length we are
gonna transmit? how is the syncronization achieved by transmitting more
number of stop bits? thank u

Others have explained the historical need for more than one stop bit for
old printers - these days, the only time stop bits other than 1 are used
are in embedded systems, when they can be useful. When receiving
characters, most uarts will accept a byte as correctly framed if it has
at least half a stop bit. But when transmitting, it can be useful with
more stop bits. One case I have used involved a system where the
receiver was powered only by a capacitor, which was recharged during
idle level from the transmitter. Using two stop bits ensured longer
charging times without complicating the transmitter or its software. In
other cases, I have used two stop bits to aid interrupt synchronisation
- in a stream of transmitted data, transmitter interrupts typically
occur at the end of the first stop bit, so with two stop bits you have a
little warning before the next character goes out.


Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.