I've made multiple microcontroller circuits in the past, but now when I look at everything, drift has become a problem. I know this when I try to connect two micros together serially via wireless modules. I also know drift is an issue because communication is only perfect when the programs in both microcontrollers run at the correct time.

So now what I am trying to come up with is a way to adjust time on one board so that it can synchronize with any board of my choice.

Based on this circuit, what I'd like to happen is for the 8051 microcontroller to load a value into P1 to define the drift offset, then set that value by bringing P3.5 low. This will then give a resistance value which is fed into the 555 timer to alter its timing (hopefully) which in turn alters the timing of the microcontroller itself.

The problem with this setup is that when I use the serial port, I need to run at a rate in which standard baud rates above 19K can be used. In my previous designs, I used a 22.1184Mhz crystal with 33pF 5% NPO capacitors but that didn't help with timing for syncing multiple boards. I don't think the 555 has the ability to be stable at a frequency higher than about 2Mhz.

Is there an alternate circuit I can use besides this that achieves the functionality I'm looking for but also allows the microcontroller to be driven at 22.1184Mhz speed?


  • 1
    \$\begingroup\$ Frequency drift is a well-known problem with RC based 555 timer. The usual solution to improve drift is to use a quartz crystal based oscillator, where drift is typically on the order of 100ppm or better. Is there some reason why you're using a 555 instead of a crystal oscillator, given your requirement for frequency stability? Can you give more detail on the 22.1184MHz crystal based solution you tried, since that should have worked better? \$\endgroup\$ – MarkU Sep 22 '19 at 23:06
  • 8
    \$\begingroup\$ This must be an XY problem. What are you doing that drift is an issue? How is drift an issue? What is losing synchronization? \$\endgroup\$ – TimWescott Sep 22 '19 at 23:15
  • 1
    \$\begingroup\$ If you are using UART-based serial communications, the receive UART will be triggered by each Start bit, and should remain sufficiently in sync to receive a character correctly, if you are using crystals of the same frequency on both microcontrollers. \$\endgroup\$ – Peter Bennett Sep 22 '19 at 23:17
  • 2
    \$\begingroup\$ Trying to maintain two microcontrollers in lockstep wirelessly by constantly tuning an oscillator has got to be harder than refactoring the software to account for drift. What are you attempting, wireless data acquisition involving multiple micros with accurate timestamps? \$\endgroup\$ – jms Sep 23 '19 at 0:19
  • 1
    \$\begingroup\$ Your question absolutely must include the details of this "radio link". Your issue sounds a lot like you are simply trying to send data faster than it can support - things like cheap regenerative radios are actually sampled (albeit erratically) by the quenching and so will introduce jitter. You probably need to either use a much slower baud rate, or use a better radio, consider modern digital packet radios... \$\endgroup\$ – Chris Stratton Sep 24 '19 at 4:16

You need to describe your actual problem - not just summarise it.

eg I am using UARTs at 9600 baud.
My clock source is RC/Xtal/ceramic resonator ...
At xxx MHz ... . ...

For asynchronous communications(UARTS / RS232) you need usefully better than 1/2 a bit difference in time across a data word.
So say using N81 = 1 start + 8 data + 1 stop = 11 bits
so 1/2 a bit error is 1/22 or about 4% or better difference in frequencies. A cheap crystal should be able to achieve this with both arms tied behind its back.
Unless there is an exceptionally good reason not to use a cheap crystal it's the easiest solution.


The UART baud is 38400bps,
Clock is XTAL with 2 33pF 5% capacitors tied from ground to each leg on a PCB and
The crystal speed is 22.1184Mhz.
The communication is half-duplex due to the limitations of radio module.

38400 baud with N81 needs double the absolute frequency accuracy of what I listed overall and the same time accuracy.
ie with an N81 async signal 1/2 bit is 0.5 bits / (1 start + 8 data + 1 stop)
= .5/10 = 1/20 ((I said 1/22 before)
= +/- 5% overall between ends
or +/-2.5% at each end.

Look at your crystal specs - if they allow << 2.5% drift for all reasons (time,. temperature, ...) then the problem is not frequency stability.
2.5% = +/- 25,000 parts per million
= far far worse than any sensible crystal specs.

The error is more likely to lie in RF link errors.
This can be checked by examining results with known suitably stable and accurate TX & RX clock sources across the same link. Try lower and lower still data rates to see what happens.

Random noise will tend to kill bits semi-randomly.
Clocks off frequency will 1st cause parity errors when they shouldn't and then affect the bit sent last, then next to last etc. (This is because an off frequency clock will cause off centre sampling which gets worse and worse as the bits are sent until the last or later ones fall off the edge of the correct bit.

A cheating way of addressing just marginal clock speed failures is to shorten the start bit time at the TX end if the TX clock is slower than RX clock and lengthen the TX clock length if the TX clock is too fast relatively. This is "desparate stuff", may even work, and should not be needed.

Link noise is a more likely error cause.

  • \$\begingroup\$ Ok for details that you're looking for, the UART baud is 38400bps, clock is XTAL with 2 33pF 5% capacitors tied from ground to each leg on a PCB and the crystal speed is 22.1184Mhz. The communication is half-duplex due to the limitations of radio module. \$\endgroup\$ – Mike -- No longer here Sep 23 '19 at 0:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.