# How does UART know the difference between data bits and start/stop bits? [duplicate]

I understand that it is common for a UART scheme to use 8N1, meaning 1 start bit, 8 data bits, and 1 stop bit. Something like this:

0xxxxxxxx1

Where 0 is the start bit, the x's are the data, and 1 is the stop bit. In the case of multiple frames being sent back to back continuously, you'd have something like this:

0xxxxxxxx10xxxxxxxx10xxxxxxxx1

My question is: how can the receiver tell the difference between the start/stop bits and data bits? To illustrate this point, suppose that the data byte 0xAA is over and over. This would look like:

01010101010101010101010101010101010101010101010101

I made the start/stop bits bold for emphasis, but it seems to me there really is no way to distinguish these from the data bits.

Sure, if the receiver has had a solid error-free connection to the transmitter since eternity past, then I can see how this wouldn't be a problem. Or if the bytes are not sent back to back then it wouldn't be a problem. But I've worked with 8N1 circuits that were continuously transmitting bytes one after another, and I could disconnect/reconnect the wires mid-transmission and the receiver would always jump right back into receiving correctly. How is this possible?

• It can't and in a continuous stream like that you will have a problem. Either a delay between bytes or some other method of 'framing' the bytes is necessary. – brhans Aug 8 '16 at 19:46
• it is very easy for the uart to sync up wrong and stay wrong for a while, there are patterns you can send continuously that if it locks up wrong it will stay wrong. Ideally the data is changing and occasionally there are idle periods, in a situation like that the uart will eventually work through the framing errors of locking on data instead of sync, and then eventually slide into the right pattern. It is a far from perfect protocol, but works well enough. There are many others that are not as error prone. – old_timer Aug 9 '16 at 1:52
• It works as you'd expect - and as the general summary of most answers suggests. Assume no parity checking, 1 start , 1 top, 8 bit data. RX idle and ready to receive, line = high = idle. | The RX will start on the 1st 0.| 1.5 bit times after the 1/0 change it will sample the 1st bit and will do this 8 times. | It will then sample the hopefully-stop bit 1 bit time later. -> NOW if the stop bit = 1 = valid it will wait for the next 1/0 transition (properly >= 1 bit time after the start of the valid stop bit AND if the data so received is rubbish it does not know. It looks as real as .... – Russell McMahon Aug 19 '16 at 6:30
• ... genuine data. So it will repeat the above. | But/and if the stop bit is invalid (low) it will KNOW it is out of sync and discard the be and look for a valid start bit. decisions can be made about WHEN a valid start bit may occur. | On the next apparent-start bit it repeats as above. If the result is a string o data with 10 sequences spaced 10 bits apart (as in your diagram) above then it IS in sync and the data IS valied- as fara as can be told. it MAY be rubbish but it is rubbish resembling real data. ... – Russell McMahon Aug 19 '16 at 6:37
• | Every time the out of sync system sees a low (= invalid) stop but it slips one or more bits along the strong and IF the data is in fact valid and error free it will sooner or later lock on unless there are patterns in the data that match the 10xxxxxxxx sync condition. | Simple high level gaps between characters will greatly help drive systems back into sync. All high for 9? character times will guarantee sync in a fault free system. – Russell McMahon Aug 19 '16 at 6:38

This sounds like a question coming from someone trying to emulate a UART receiver in software or an FPGA. For RS-232, they use the term mark and space. But these usually correspond, once digitized, into a '1' and '0', respectively.

UART receiver often divides up each bit time (must be known, a priori) into at least 4, but often 16 or more, sub-periods. It starts out (upon power up/reset) in a state where expecting the serial receiver line in a mark state. If the line is NOT in a mark at that moment, then it knows that it is in the middle of a transmission frame and must wait until it can synchronize. If the line is in a mark state, then it may or may not be in the middle of something and will have to wait and see. This is a problem with RS-232, if just plugging into another device while serial communications are happening or if part of a tap to monitor the asynch serial communications between two other players and have just been reset. To be absolutely sure, when coming out of reset anyway, the UART would need to observe at least N bit times (where N is the number of bits per word, and often 7 or 8, and assuming no parity option here) worth of mark followed by one bit time of space to re-synchronize up (or else N+1 bit times of space.) Many don't carry that much state around, so they can synchronize up incorrectly, if started in the middle of a stream. You will often get framing errors and occasional data bytes, until it happens to accidentally re-synchronize up correctly again. That's often been an acceptable price, too. Normally, cables are connected and devices are power up in a particular order of operation so that there's rarely any issues.

Once synchronized, though, the UART knows what to expect. It always starts with the receiver line going from a mark to a space, the needed start bit that goes for a full bit time, followed by data bits and then followed by at least one bit time worth of mark (or longer) as the stop bit. If it stays synchronized, then it will see that pattern repeated over and over again.

Part of the reason for dicing up the bit times, to something like 4X or 16X, is that the clocks used by the transmitter and the receiver aren't necessarily perfectly accurate and they are otherwise simply asynchronous to each other. So part of the synchronization that goes on in the receiver is in lining up its diced up periods to the transmitter's timing. The finer-grained that is done, the better aligned the receiver can become.

It is detecting the start bit. That's exactly the purpose of it. The idle line will look like this:

...1111111111111111111111111111111...


Once the receiver is seeing 0 after a long time of ones (or after a stop bit, as we will see shortly), it knows the transmission is started and starting to count bits. It knows that 8 bits (or as defined by configuration) after the start bit are data. The ninth one is the stop bit and should be 1. If it is not - framing error occurs and resynchronization is required.

After stop bit is received, it is starting to wait for the start bit again. And so on.

Theoretically there can be a problem in synchronization if the line looks like:

..1010101010101010101....


or similar, so in this case the receiver won't see where to start, but in this case it won't really matter, as the start position won't make any difference. But in order to avoid such a problems some protocols define 1.5 (one and half) bit length for the stop bit to make it unique. Or, in practice there are always some time delays between two packets of data, so the line is idle for long enough to allow the receiver to synchronize.

• "but in this case it won't really matter, as the start position won't make any difference" — it will make a difference once the line stops the series of AAs and starts to transmit different data. Then the receiver may not only get framing errors, but also garbage data. – Ruslan Sep 3 '19 at 14:59

UART needs silence at the beginning to catch first start bit. Then it just counts according to predefined number of bits, reaches stop bit- and waits for start bit again. If UART starts receiving in the middle of a long message- easily it may get just junk.

It can tell the difference because it knows where they ought to be in the bitstream (because you told it).

Just remember that any symbol is meaningless until there is an agreed upon meaning.

If idle pre-exists , no errors occur , no problem, but any error such as buffer overrun requires some method of hand-shaking, after which idle state occurs and it should sync again from the 1st start bit.

Handshaking is necessary to communicate detection of buffer full, over run, parity error or stop bit error.

Odd Parity is useful here to detect a data error and or a framing error to resume correct start bit sync and error free communication.