8
\$\begingroup\$

In serial communication, does the baudrate mean we have to use the exact clock speed or is it a range of speeds that we can use?

and if it's an exact value, how exact should it be ? for example, can i use 555 as the clock of a serial communication circuit ?

\$\endgroup\$
  • \$\begingroup\$ A UART usually can tolerate a deviation of about ~3%. Depends on a specific one, though. \$\endgroup\$ – Eugene Sh. Dec 19 '17 at 18:06
  • \$\begingroup\$ For USB, it'll be specified in the standard, which is free to download. \$\endgroup\$ – The Photon Dec 19 '17 at 18:11
6
\$\begingroup\$

The timings have to be accurate enough that they don't drift apart before the protocol resyncronises.


UART serial resyncronises on each byte and a byte is around 10 bits (8 bits of data plus start and stop). We assume that our UART targets the middle of each bit. If everything is is perfect and only one end is inaccurate that allows for approximately 5% difference between the two ends of the link.

However:

  1. Both ends of the link may be inaccurate relative to nominal. In the worst case one end may be under nominal while the other is over nominal.
  2. There may be systematic inaccuraries. For example most UARTS have a limited range of baud rate generator settings.
  3. Your UART is based on a master clock with a finite speed. Even if the clocking and baud rate generator are perfect this will result in it not hitting the exact middle of each bit.

The bottom line is that 1% error on your clock is almost certainly fine. 5% error is almost certainly a problem. Between those two figures it may or may not be a problem depending on the overall picture.

That is a tall order for a RC oscilator. Lets say your R has a 1% tolerance and your C has a 2% tolerance. That gives about a 3% tolerance for the RC network's time constant and that is before you think about any errors introduced by your driver chip.

So the bottom line is you should be looking at a crystal or ceramic resonator.


As for USB I don't have the experiance to analyse from first principles but https://www.silabs.com/community/interface/knowledge-base.entry.html/2004/03/15/usb_clock_tolerance-gVai says 1.5% for low speed and 0.25% for full speed.

\$\endgroup\$
  • \$\begingroup\$ If one can program baud rate in 3% or finer steps and can use a suitable "training" sequence, RC accuracy may not be an issue. If one knows that the other end will be alternating sending 0xF8 and 0xF0 repeatedly (low for four and five bit times, respectively) setting one's baud rate 33% faster should cause one to consistently receive 0xF0 (5.33 bit times) and 0x80 (6.67 bit times). Receiving other values will let one know one is faster or slower than that "33% over" speed, while receipt of repeated 0xF0 0x80 will indicate that one should reduce speed by 25% and start real communication. \$\endgroup\$ – supercat Dec 19 '17 at 20:34
8
\$\begingroup\$

The UARTs typically used in RS232-type serial systems work by sampling the data line somewhere mid bit according to a division of the predefined baud rate base frequency clock. As such, if the sent data and receiver are not on the same frequency the "sample-point" will wander closer to the edge of the bit frame on successive bits.

With a normal UART the bit length for a byte is 10 or 11 bits. 1 Start, 8 data, and 1 or 2 stop bits. Half a bit of wander on the 10th bit translates into 0.5/10 = 5% error.

However, in reality your tolerance is less than that because you also need to add in the latency of you base frequency period which will add in an offset from the leading edge of the start bit. The higher your base frequency, the less effect that has.

As for using a 555 timer for this purpose, I would not recommend it unless you plan on having a manual adjustment in the 555 circuit.

A USART on the other hand uses a more complex control method that attempts to synchronize the transmission to the received data. This can be through using a data pattern that has an embedded clock, by using a passed clock, or by some form of phase locking to the received data edges. (Though arguably the latter is really pseudo-synchronous.)

\$\endgroup\$
  • \$\begingroup\$ Since you know what you're talking about, I thought I'd mention the abbreviation "USART", which should be a part of this answer. Well, it would make the answer complete in my opinion, and after that deserve a +1 from me. \$\endgroup\$ – Harry Svensson Dec 19 '17 at 18:46
  • 1
    \$\begingroup\$ @HarrySvensson hmm.. I agree.. but trying to decide is that just makes the answer more confusing for a 555 packing OP. \$\endgroup\$ – Trevor_G Dec 19 '17 at 18:51
  • 1
    \$\begingroup\$ A USART is different in that it can be synchronous. And if it's used as a synchronous interface, then the clock is common to both ends, and then the clock speed doesn't matter. \$\endgroup\$ – gbarry Dec 19 '17 at 19:18
  • 1
    \$\begingroup\$ Oh well, it can be in the comments instead, thank you @gbarry. I don't mind. +1 to Trevor. \$\endgroup\$ – Harry Svensson Dec 19 '17 at 19:26
  • \$\begingroup\$ @HarrySvensson I did add a brief hand wavy explanation of the difference for completeness.. \$\endgroup\$ – Trevor_G Dec 19 '17 at 19:27

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.