18
\$\begingroup\$

UARTs often let you choose between 1, 1.5 and 2 stop bits. With 1 stop bit payload efficiency is 80% (8/10), with 2 stop bits that drops to 72.7% (8/11). So what's the advantage of the second stop bit?

\$\endgroup\$
26
\$\begingroup\$

Extra stop bits can be a useful way to add a little extra receive processing time, especially at high baud rates and/or using soft UART, where time is required to process the received byte.

Where speed is tight, and your UART only offers division ratios in powers of 2, adding an extra stopbit can be an option to give a less drastic reduction in speed than the next lowest baudrate.

I believe this is may one reason the DMX512 standard specifies 2 stopbits.

Another situation where they can be useful is if you have devices forwarding a data stream without any buffering or packetisation - small differences in clock rates between nodes and finite sampling granularity can cause errors to occur as data is received and retransmitted by a number of nodes in a chain, but if the data is sent with 2 stopbits and the receivers are set to one stopbit, it adds enough margin to accommodate these errors and leave at least one valid stopbit period for nodes far down the chain to receive reliably.

I have also enountered a situation where a very long cable run caused some asymmetry in the rise and fall times, resulting in inadequate stopbit length - sending 2 stopbits and having the receiver only require one fixed this.

\$\endgroup\$
6
\$\begingroup\$

In days long gone printers were (almost) all-mechanical constructs. Baudrates were somewhat standardised even then, so adding an extra stop bit would give the printer some extra time to print the character. Timing aspects were more visibly back then. For my first printer, an noisy http://en.wikipedia.org/wiki/Teletype_Model_33 , I had to insert a pause of two characters after sending a Carriage Return.

\$\endgroup\$
1
  • \$\begingroup\$ A properly adjusted Model 33 only needed one character after the Carriage Return. That's when you're supposed to send the Linefeed! I forgot that they needed 2 stop bits, but you're right and so what I said below Russel's answer applies (but those 1.5 stop bits was for Baudot hardware). Extra stop bits (of 10ms) didn't help any Carriage Return delays, though. \$\endgroup\$
    – gbarry
    Apr 10 '14 at 7:24
6
\$\begingroup\$

Two stop bits are unlikely to be much more useful than one on a system that has a significant proportion of stopped time and which is working in a low noise (low BER) environment such as internal to equipment or in a peripheral interface with a few metres of cable and/or without a modem-modem stage.

2 stop bits give you greater synchronisation time, more time to process between characters and probably, depending on hardware and algorithms, better chance of gaining or regaining synchronisation during a continuous data stream. Intercharacter time is of much less value on modern systems than when clock speeds were low and processor throughput lower.

If you have an essentially continuous data stream, then if unsynchronised, any high bit will look like a stop bit. Any high low transition will look like a byte boundary. If your receiver starts on a 10 boundary and it is not a true start boundary then this will only be discovered 50% of the time )(ie if the final "stop bit" is found to actually be a low data bit and you will also have skipped over the genuine stop/start boundary along the way. On average you have 1/4 prospect of a byte boundary being 1/0 and falsely looking like a stop/start pair. The above suggests that if you choose a false stop-start pair then there is probably about 50% chance that you will choose another one on the following attempt.

If you use 2 stop bits (11) then a valid stop start sequence is 110 which has 1/8th chance of occurring in random data traffic. The mixing of genuine stop and start bits in the unsynchronised flow changes the statistics slightly but it seems relatively unlikely that if you get a false 110 stop/start sequence on one cycle that you'll hit another one next try before stumbling over the genuine 110 sequence which next occurs.

As you note, 1 stop bit yields 8/10 = 80% max throughput and 2 stop bits yield 8/11 = 72% efficiency. The difference in throughput at the utter limit is 80%/72% =~ 11% more. This is a useful gain in extreme circumstances but not vast and if the circuit is idle more than about 10% of the time it's of minimal value. If your circuit is noisy and prone to occasional synchronisation loss then the extra stop bit may help a lot. BUT if you care that much about throughput you can often increase the baud rate (not always) or change to fully synchronous operation.

\$\endgroup\$
7
  • \$\begingroup\$ I don't know of any UARTs which can be configured to ignore any apparent start bits that aren't preceded by more than a full bit time of marking (indeed, most will accept a start bit which is preceded by half a bit time of marking, and cannot be configured to do otherwise). Such a feature could be useful, though. \$\endgroup\$
    – supercat
    Apr 15 '12 at 19:57
  • \$\begingroup\$ You've rather stumbled onto the correct answer, if we can accept that this practice goes back to the mechanical days. Back then, the receiver mechanism needed about 1 bit time to come to a stop to be ready for the next start bit. So the transmitter was constructed to have a 1.5 bit time stop bit. It had the effect you described. If sync was lost, there might be several garbage characters until you regained sync. When we got to electronic implementations, the receiver could start waiting for the next start bit immediately upon seeing the transition to the stop level--it didn't need padding \$\endgroup\$
    – gbarry
    Apr 10 '14 at 7:12
  • \$\begingroup\$ @gbarry - methinks thous't rather stumbled in your comment. \$\endgroup\$
    – Russell McMahon
    Apr 11 '14 at 5:27
  • \$\begingroup\$ Actually, I ran out of characters :) Something wrong? \$\endgroup\$
    – gbarry
    Apr 11 '14 at 7:15
  • \$\begingroup\$ @gbarry I just 'stumbled' upon this again 6+ years on. aking up, perhaps, where I left off (memory fades, so who knows with certainty what I had in mind then? :-)). I was oldish then and older now. (70 fwiw). My first printer was a Creed 7B teleprinter running 6 bit Baudot with 1.5 stop bits (memory says). My first ASYNC code was written in machine language on a NatSemi SC/MP (maybe1976?) as it had no internal UART (or any other peripherals) and while you could buy discrete UARTS they cost money and code was 'free'. So the 1 1.5 2 nuances were 'part of life' way back then. \$\endgroup\$
    – Russell McMahon
    Jan 12 '21 at 0:29
5
\$\begingroup\$

To amplify mikeselectricstuff's point about receive time with "soft UARTs", a receive application that will always know when to accept data and does so on a polling basis can often handle faster baud rates than would be practical with an interrupt-driven soft UART. Such applications, however, can only process incoming data during the time between the start of one byte's stop bit and the next byte's start bit; the time required to process each byte ends up being the limiting factor for communications speed. Processing data at 115,200-N-8-2 is not much more demanding than processing it at 57,600-N-8-1, but it's more than 80% faster.

Sometimes one can push things even further by using seemingly-less-efficient data formats. For example, one can send each byte in two pieces, one with seven bits and one with one (the MSB's of the one-bit part are all set). If one does that, even with only one stop bit, there will be eight bit times of marking between the end of one byte-pair and the start of the next, thus allowing one to push the bit rate four times as high as what one could do with only two stop bits (and eight times as high as what one could do with one). Despite having to send twice as many bytes, the four-fold increase in data rate would be a major win. In addition, although each transmitted byte pair could be used to send eight bits of data, only 130 out of 256 possible byte values would be used by the encoding, leaving 126 values available for signalling or other purposes.

\$\endgroup\$
2
  • \$\begingroup\$ You can also soft-UART high baudrates (250K and up) by generating an interrupt on the startbit edge and staying inside the interrupt code for the whole byte - an extra stopbit can be very useful here. \$\endgroup\$ Apr 16 '12 at 20:11
  • \$\begingroup\$ @mikeselectricstuff: An extra stop bit can be very useful, as can using only some of the bits in each byte (requiring that the LSB of each byte be set can be useful because one can derive timing from the rising edge of that bit, even if there might be a little slop in when the interrupt occurs). A major limitation of the bit-interrupt-triggered-on-start-bit approach, though, is that there isn't any nice way to send data while incoming data might arrive. Either the transmitted data or the received data (or both) is going to lose. \$\endgroup\$
    – supercat
    Apr 16 '12 at 21:10
2
\$\begingroup\$

Once upon a time there were electromechanical monsters called teletypes. Most ran on AC motors synchronous with the power line frequency. Thus there was always a chance that two communicating machines may not have been synchronized to the same power grid or even run on alternating current using different frequencies for that matter.

Thus, in order to allow a slower machine to catch-up and not drift out of synch, two stop bits were sent.

For other purposes such as allowing for the printing carriage to return to the beginning of a new line, a CR, LF plus two rubouts were sent (all holes on an 8 level tape).

It was customary for circuits running at speeds of 110 Baud and slower only.

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

Slowness of the receiving mechanical devices was the reason behind adding the extra stop bits, however the devices today are fast enough and work at even higher baud rates without the need of an extra stop bit

\$\endgroup\$
0
\$\begingroup\$

As you know UART is an asynchronous method of data transfer, this means that the clock of receiver and transmitter is not synchronous. So as the number of received bit increases the receiver sampling time drifts from the middle of the bit duration, So the stop bit can be set to be as wide as 2 bit duration so that we are sure that receiver can sample the stop bit correctly. As mentioned above there could be some other reasons like slowing down the transmission rate for the receiver to be able to receive correctly. But i think other yet important reason is what i mentioned.

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