I'm using USART on board to display messages on desktop PC terminal using Realterm

I noticed that, when I change stop bit number on Realterm, it does not affect the correctness of the message, contrary to baud rate, or bit number.

why stop bit number does not affect correctness?.


2 Answers 2


The stop-bit has a logical high level, it's the last bit that gets transfered if you transmit a byte over RS232. In case that you don't do any transfers the line is idle, and this is signaled as a logical high level as well.

If you increase the number of stop-bits on the sender side of a RS232 connection the receiver side will interpret the first stop bit as a stop bit, and all following stop bits as idle time on the line.

Effectively for each additional stop-bit you just add a small delay between the bytes transfered over the link.

  • \$\begingroup\$ Note that the inverse will probably not work: when the receiver expects 2 stop bits and checks for them (AFAIK not all do, even when set to 2 stop bist), and the reveiver sends only one stop bit and a new byte immediate after the stop bit, the receiver will signal a (framing) error. \$\endgroup\$ Jun 16, 2015 at 10:30
  • 1
    \$\begingroup\$ @WoutervanOoijen Correct, it will however receive the last byte of any continuous transfer because the idle-time will again be interpreted as a stop-bit. \$\endgroup\$ Jun 16, 2015 at 10:44
  • \$\begingroup\$ correct. And when there is somehow a gap between each tranismitted byte the problem will never be noticed... \$\endgroup\$ Jun 16, 2015 at 11:21
  • \$\begingroup\$ @WoutervanOoijen Jep! Quite a lot of RS232 transmitters have small, undocumented delays between bytes. Found that out when I tried to abuse RS232 transmitters as frequency generators. \$\endgroup\$ Jun 16, 2015 at 11:36
  • \$\begingroup\$ @NilsPipenbrinck sorry im really new to uart : what does baud rate means exactly : the number of data (8 bit length in my case) per second, or number of single bits (including start, data bits, stop bit) per second ??? \$\endgroup\$
    – makouda
    Jun 16, 2015 at 12:42

A second stop bit in the transmitter makes the communication more resistant to interruptions, allowing the receiver to detect a true byte start faster than with one stop bit.

When you have a continuous stream of bytes and you turn on the receiver mid-stream, chances are that you get a byte from its middle, taking actual data as a start bit and confusing start/stop bits as part of the data. Of course this means that you'll get garbage for a while. Errors will accumulate until the receiver finally gets the real start bit for a word start and the stream stabilizes. When that happens depends on the data itself; it's more likely to happen after bytes that end in ones, like 0x01, 0x03, 0x07, 0x0f, 0x1f or such., because they have fewer zeros to be taken as start bits.

When you have two stop bits, statistically you'll get to that point faster than with one stop bit (provided that all bytes are transmitted without any pause or delay between them, which would act as effective additional stop bits). This was specially useful in old hardware like teletypes with very low baud rates and very noisy lines, especially if you don't have an underlying protocol (with checksums, retransmissions and such).

It's still a good measure to use two stop bits (in the transmitter) if you've got any of the forementioned conditions.

Of course you've asked about the receiver side. I don't think it's very useful to use two-stop bits, but it could help to detect framing errors as well depending on the implementation (whether the word is rejected or accepted when an error is found).


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.