1
\$\begingroup\$

I have some microcontrollers with TCXO's where I wish to measure their frequency stability using Allan variance (from say 1ms to 10s). However, my measurement equipment is limited. I have access to a 10 Mhz Rb source, a nice oscilloscope (sadly without support for external reference), and a 53220A Keysight frequency counter. I would think that the frequency counter would be the ideal to measure Allan variance, unfortunately, my model has significant gate "dead" time which appears to pollute my measurements.

Any ideas about how to go about performing these measurements would be greatly appreciated.

\$\endgroup\$
4
  • \$\begingroup\$ The problem here is that you don't have a precise time reference. You may buy a cheap GPS-assisted frequency counter like: lloydm.net/Demos/GPS_freq_counter.html \$\endgroup\$ – Enrico Migliore Apr 12 at 8:25
  • \$\begingroup\$ @EnricoMigliore I do have the option to sync my 10 Mhz Rb source to a GPS receiver. I can then use that as the counter reference. However, that doesn't fix the counter's dead time \$\endgroup\$ – user3120921 Apr 12 at 8:31
  • \$\begingroup\$ Buy a cheap refurbished frequency counter, one made in the '90s. \$\endgroup\$ – Enrico Migliore Apr 12 at 8:45
  • 1
    \$\begingroup\$ The TAPR TICC is made for exactly this situation and is excellent value. \$\endgroup\$ – pericynthion Apr 12 at 21:52
2
\$\begingroup\$

Microcontrollers can measure their own frequency stability, if provided with a stable external clock.

Divide the Rb 10 MHz standard down to a rate you're happy to get samples at. For your 1 ms - 10 s request, say 1 kHz, to create a slow, accurate clock.
(One solution: the PD4 from leapsecond.com. Code is on the website).
You may also be able to use an on-board externally clocked counter to achieve a 10 MHz / 256 interrupt rate.

Feed it to an interrupt pin of the uC under test.

Write a short program using a free running timer to print the elapsed time at each rising edge of the slow clock. Zero dead time. Occasional counter wraps but you can manage those in post-processing.

Record the serial output on a PC.
Clean up and plot phase, frequency error, and finally process for Adev, using stable32 (free), timelab (free) or one of the python libraries.

Watch out for garbage in garbage out - if your uC is detecting ghost pulses because it's on a breadboard, or your PC is dropping data, it won't be obviously visible on the Adev, it'll just be wrong. So you need to methodically clean up the data first, inspect for missing and spurious points, for phase jumps, for frequency sanity, and then process deeper.

\$\endgroup\$
3
  • \$\begingroup\$ That sounds like a really nice solution. I think I will try that out. Thanks! You mention that processing for Adev is a non-trivial task. Could you possibly elaborate on the potential pitfalls? \$\endgroup\$ – user3120921 Apr 12 at 10:19
  • \$\begingroup\$ I'm not an expert. It looks simple in theory, and there are good programs (stable32, timelab) and python libraries that do it for you. I think the biggest problem is that you work on imperfect data, that has a big unexpected step in it. It won't be apparent from the Adev curve that you put garbage in. So you need to methodically clean up the data first, inspect for missing points, for phase jumps, for frequency sanity, and then process deeper. Read the time nuts list archives for more unsorted but super-valuable advice. \$\endgroup\$ – tomnexus Apr 12 at 20:15
  • \$\begingroup\$ Thanks, I will keep all this in mind. \$\endgroup\$ – user3120921 Apr 13 at 8:07

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.