Hello,
I am wondering if someone could clear this doubt for me, in case of UART, the clock speed is 1.8432 MHZ, however it is able to transmit maximum of 115,200 bps, however even if we are able to transmit at 1 bit per cycle we should be able to transmit at 1,843,200 bps. What is the rationale for making something go slowly, when it can go much faster.
PS, I really could not find any suitable group for this question, follow-ups to a more suitable group are welcome.
TIA
-- Imanpreet Singh Arora
The traditional implementation uses a 16x clock on the receiver.
It looks for the transition on the leading edge of the start bit, then starts counting. After 1.5 baud times, it samples the first bit in the byte. That's the middle of the bit cell.
16*115200 is 1843200You can use slower clocks, say 8x, but they you will (sometimes) be farther from the center of the bit cell and errors will be more likely.
-- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
The oversampling not only makes it possible to determine the position of the start bit, but also it combats the noise and errors. The 16 consecutive sampled values (each being 0 or 1) are used to decide on the actual bit value. If most of these 16 samples are 1, it's 1. Otherwise, it's 0. A better (in terms of error immunity) UART is one that works with a current loop instead of the regular that works with voltage.
The start bits help to resynchronize. If the data flow isn't continuous but often have all ones, the receiver and xmitter clocks may not match each other well, provided all bits in a byte are decoded correctly. Good hardware implementations may adjust themselves to the clock offset.
Alex
Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the pauses between bytes can be of arbitrary time. Only the timings between bits in a byte are established.
Serial line has no notion of the "packet".
-- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.com
but
bits in
Packetization is an artificial thing. Normally, the physical data channels are continuous and bear no idea of any data packetization. Packets are just a way to transfer data in portions, which is most useful in the channels, where the data can be lost or corrupted. Chunks of data are numbered and redundancy is appended to make sure anything lost or corrupted can be requested for retransmission. Another way to combat data corruption is to add the redundancy into the data itself, by some forward error correction (FEC) mechanism. The receiving party can recover some errorneus bits in the data from the data with added redundancy. Although FECs can help a lot, they're not always practical because they require bigger bandwith and of course not every error can be corrected with them (the Hamming distance of the FEC determines the correcting performance).
Alex
Actually with 10mb/s Ethernet and USB (all speeds) there is no carrier on the wire when actual data is not begin transmitted. Clock recovery starts at an arbitraty point with every packet.
Oh no.
The Ethernet packet cannot have pauses between bytes, it is transmitted as the single entity time-wise. Same are USB packets, though they are smaller.
Serial UART has no notion of such mode at all. This is why it is called "async" in Cisco IOS.
There are also some serial attachment cables which have the notion of the packet (transmitted as single entity time-wise, I also expect this interface to have packet headers). They were used in X.25 equipment, and are incompatible with UART cabling. Cisco IOS called this interface "serial".
The PPP protocol requires the packet-based underlying physical media. So, to run PPP over the UART line (which means - usual modem) - escape bytes are used to denote the packet boundaries. It is described in the PPP RFC as appendix. In Windows, this logic is in AsyncMac.sys which "packetizes" the serial UART line.
Another very, very major purpose of packetization is time-sharing the single physical media line for several traffic flows.
Most network media do not use ECC, they use the stupid checksums. The recovery is done via retransmission. ECC is used in storage, not networking.
-- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.com
Same as with serial UART.
USB packets have a preamble to synchronize the PLLs. IIRC Ethernet too.
-- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.com
You are correct, that it is technically possible to SEND at 1.842MHz, and some modern UARTS have this option ( see Oxford semi ). The problems are on RECEIVE, where historically a 16x sample rate was chosen for the RX Clock. The 16x is not mandatory, but a trade off between speed and clock drift/edge jitter tolerance. Some devices have variable sample rates : /8 is often seen, and even /5, and some uarts can output/input a clock, but by that stage they have morphed away from the ASYNC approach. Because the issue is one of phase of sample, not frequency per-se, with devices like FPGAs that have Digital Delay lines, you could design a UART with a RX clock == BAUD rate, and choose the delay line tap, on each start bit.
-jg
to
correction
recovery
If the retransmissions are very costly (e.g. half-duplex physical channels) but the BER (Bit Error Rate) is good enough, error correction is quite efficient.
Alex
of
transmit
1is
bit
of the
consecutive
bit
Acurrent
Pardon me for being a novice. But, are you saying that in actual 16 samples will be transmitted of a single bit. And that the reason, we have the maximum transmission rate is because 16 copies of a bit will be transmitted.
-- Imanpreet Singh Arora
No. The 16 samples-per-bit is done on the receiving side. The receiver's sample clock is not locked to the transmitter's. So, because of this, it needs to sample many parts of what it thinks may be one bit. To determine if that bit was truly a one or a zero, many samples are taken. If, for example,
10 of the 16 samples were the same polarity, then it's safe-to-assume that the bit was that particular polarity.If the transmitter sent a clock along with the data, then the receiver could use that clock to sample the data only once (the same as just latching the data with its clock).
If the transmitter didn't send a clock, but rather sent all data bits in a very periodic manner, then the receiver could use the data edges to infer (recover) where the center of each bit is. This method requires a fairly constant flow of data edges. Because of this, the data is usually scrambled to insure that this edge density requirement is met.
These two methods of data transmission are referred to as "synchronous" transmission.
On the other hand, a UART (what you're talking about) is used to send and receive data "asynchronously". Therefore the receiver doesn't really know where each data bit is supposed to be (in time). So, sampling and (some sort of) majority decision making is required. Hence, the lower data rate.
Bob
Thanks everyone.
-- Imanpreet Singh Arora
No, I dont think most UARTs work in this way. The reason for oversampling is to have a good determination of the sample point.
The UART first tries to determine the middle of the start bit oversampling by 16, then it only samples once per bit.
If you are sampling at the BAUD rate, then the error in the sample poin can be almost half a bit in both directions.
If you are sampling at BAUD*16, then the error is 1/16 or 6,25%.
On top of that error you have a deviation between the senders or receivers frequency vs the nominal BAUD rate. They can deviate in differing directions.
After receiving 10 bits, your max deviation should be less than half a bit time.
So the equation is 0,0625 + (10 x 2 x err) is less or equal to 0,5 solving the equation gives err
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Yes, that's why it uses start and stop bits.
-- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.com
Alexei A. Frounze wrote about UARTs:
I've never seen a UART that behaves that way. Such a UART would be very unreliable, because if the sender was slightly slow or fast relative to the receiver, the 1 bits would get smeared into adjacent bits.
Normal UARTs find the leading edge of the start bit, then wait 8 clocks and sample again to make sure the start bit is valid. After that, they take a single sample every 16 clocks.
Some of the fancier UARTs (e.g., some Motorola/Freescale microcontrollers) take samples at 7, 8, and 9 clocks into the bit cell, and will report noise if they are not all equal.
Eric
Another example : The 80C51 UART sampled 3 times, in mid-bit, and does a majority vote. It does not flag any errors on this.
Some UARTs start looking for a START egde, at the END of the Stop bit. As an excercise, consider if this is a good idea, and if not, what would be better ?
jg
Wehn I have done UARTs, I put the filter before the start bit detector so if there is is a glitch in the beginning of the start bit, then this is filtered away, Come to think ábout it, this might be a bad idea if there is a positive spike after the start bit is detected, DO we know for sure that it is only the middle of the startbit that is filtered or is the start bit edge filtered as well. Some UART detect 8 valid samples low and some only sample half a bit time after the first low is detected.
Any comments on what is good and what is bad?
Aint a good idea if the sending UART is faster than the receiving UART. Then you will sample at your perceived end of stop bit and the sender has at that time already started sending the next startbit Eventually you will lose one character. Have to start searching for the startbit after 3/4 or shorter depending on error.
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
the
I don't see where it's unreliable. The majority tells the final value. Your "slightly", which is about 1/16th of the bit duration isn't going to make it unreliable so badly.
noise
That's fine.
Alex
On a slightly different note, does anyone know why most serial protocols use simple voltage levels to denote a logic 0 or 1? I admit I'm no expert but I recall from my A-level electronics an edge-triggered system where a '0' would be (say) low-followed-by-high whereas a '1' would be high-followed-by-low. Yes, this means _at_least_ twice as many voltage transitions per bit but I would have thought that given its greater resilience mismatched clocks or any stray capacitance it would be worth the trade off.
Just curious...
-- Andrew Smallshaw andrews@sdf.lonestar.org
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.