I learned from research that crystals (HC49/U style casing) experience drift which causes timing to be inaccurate in the long haul.

My project is a laser tag system in which one microcontroller (AT89C4051) in the target continuously searches for specific laser patterns from a gun which also uses the same microcontroller. Both use the exact same crystal (22.1184 Mhz) from the exact same manufacturer and the circuit board traces on both boards from microcontroller to crystal leads are the same. The capacitors between the crystal leads and ground are all 33 pF NPO (5%) from the same manufacturer.

Now if I write the software perfectly, start everything at the same time and run everything for about a minute or so, everything will fall in sync. I'm also running another unit that would cause everything to try to be in sync periodically (by the master sending sync bytes).

But what about drift?

Let's say I power each unit with a fully charged 6800 mAh battery for 10 hours. (Ok, I understand a real laser tag game would not last 10 hours, but I'm going for worst cases here). Then one battery decides to die 1 hour later and I replace it.

Since the crystal is almost 24 Mhz, the microprocessor would execute instructions about one every 540 nS. So if I had the micro running for say 10 hours, would instructions still run at 540 nS at that point? or would the time alter on every minute due to drift?

Like, for minute one, would each instruction take 540 nS to execute then minute two 538 nS then minute three 541 nS?

I'm just trying to understand the best crystal parameters regarding drift to choose for my application so the data doesn't get out of sync (just because of possible drift resulting from continuous operation).

I mean I seen specs like frequency stability and tolerance measured in ppm when I looked at crystals on Digikey, but what are the best numbers to aim for and how do I convert those numbers to the amount of time I can have guaranteed instruction stability before major drift affects the operation of the synchronization?

  • 3
    \$\begingroup\$ Reasonable schemes simply do not require maintaining synchronization for hours without updates. Your application does not sound like one which should require persistent synchronization at all - but those that do, work by adjusting the synchronization on each interaction. \$\endgroup\$ – Chris Stratton Nov 15 '19 at 6:29
  • 6
    \$\begingroup\$ It's really unclear why you think you need synchronization for this at all. If you are trying to recognize sender codes, look at how remote controls work: first the IR receiver itself demodulates the fast pulses, then software finds the pattern by which they appear and disappear. This needs only short term relative timing, and with well thought out detection algorithms will likely work with RC clock oscillators off by several percent. \$\endgroup\$ – Chris Stratton Nov 15 '19 at 6:30
  • \$\begingroup\$ Yes, if you think about UART, the first edge synchronizes the data transmission. The sender and the receiver only have to stay in sync for the next few bytes of data. \$\endgroup\$ – G. B. Nov 15 '19 at 6:37
  • 3
    \$\begingroup\$ Is there a question buried in there? If you need laser tag devices being in perfect sync for hours then it seems you are really doing something fundamentally wrong. Same like buying two identical clocks and expect both of them to tick equal amount of seconds in a year. They will drift, most quartz crystal watches can keep time within +/- 15 seconds per month which is about 12ppm. Your design has most likely 50ppm crystal and seemingly randomly selected 33pF load caps so it may not be so accurate. \$\endgroup\$ – Justme Nov 15 '19 at 6:53
  • 1
    \$\begingroup\$ LASER (Light Amplification by Stimilulated Emission of Radiation), not LAZER. \$\endgroup\$ – Transistor Nov 15 '19 at 11:29

Garden-variety crystals only have an initial accuracy on the order of 100 ppm, before you even start to consider thermal and voltage effects. You can spend more money and push things down to on the order of 10 ppm, or you can spend a LOT more money for temperature compensated or even ovenized crystals to do even better than that.

Two 22.1184 MHz crystals whose frequencies differ by exactly 100 ppm will have a phase difference of 2211.84 whole cycles after just one second. Crystals 1 ppm apart will have drifted by 22.1184 cycles in that period.

So no, you can't rely on "blind" synchronization for any meaningful length of time. You need to design your system so that the subsystems remain in sync despite the inaccuracies of their individual clocks. Basically, they need to communicate with each other in some way on a continual basis.

Of course, it isn't at all clear why a laser tag system would require that kind of global synchronization in the first place. Sounds like some sort of X-Y problem. What problem does that sort of approach solve for you?


Any system that relies on instruction to instruction synchronization of two units is doomed to fail. It is not needed, and nobody ever does it.

Using the same nominal frequency crystal will get you within +/- 100ppm as built, which is completely adequate to get bit rates correct, so they can talk to each other. +/- 10ppm can be got with extra work and cost, but there is really little point for the system you want to run.

Once communicating, they should sync their activity to the exchange of messages.


A reasonably good crystal might have a spec of 10ppm +/-15ppm/C.

In this example we are ignoring the temperature effects on the load capacitors and driving circuit that pull the crystal's frequency, and aging effects where it's frequency changes over it's lifespan.

You want to use 22.1184MHz, so 1ppm is ~22Hz, 10ppm is ~220Hz. We can assume your crystals are not at exactly the same temperature, perhaps <2C between them. So that's another 30ppm or 660Hz, ~880Hz total.

So, worst case, in one second, one crystal may have drifted from the other by about 800 ticks. That is 800 / 22118400 or about 3ms. After a day that would be 22 seconds.

Even the best commercialy available crystals that employ temperature compensation and sit in little ovens only manage in the order of ~0.01ppm and they are expensive.

The conclusion is that you can't rely on a crystal to keep good time autonimously.

Any scheme where you have more than one timing reference and the timing relationship matters you need a syncronisation mechanism. That could be some sort of locking mechanism (e.g. a PLL and VCXO). Or external time reference like GPS.

Ok, so how to fix it in your case? You have to ask yourself why do you think you need a precise shared time reference?


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.