SparkFun Forums

[robin_hodgson]

Just for fun, I wrote a program that uses any cheap GPS with a PPS output as the timing source for the Apollo3's build-in XTAL calibration mechanism. It works great! It means that you don't have to go buy a frequency counter to calibrate your boards to within the 1 PPM promised by the calibration mechanism.

Here is the output from a sample test run:

Code: Select all

The XTAL frequency is measured at 32768.829 Hz
Frequency error is -25.31 PPM
Frequency adjustment value is -26.54 steps
Closest integer step count is -27 steps

The first pic shows that the frequency counter agrees with the GPS about the length of a second to 0.1PPM. The second pic shows the calibrated 16384 Hz clock output from a test Redboard after the calibration completes. The uncalibrated error was 25.31 PPM, and after calibration, it is off by -0.67 PPM. That's as good as the Apollo3 calibration mechanism can do!

I'll figure out how to post the code at some point.

[robin_hodgson]

Here is another run. I added a test at the end to measure the resulting frequency of the calibrated 16384 Hz signal.

Code: Select all

The XTAL frequency is measured at 32768.832 Hz
Frequency error is -25.39 PPM
Frequency adjustment value is -26.63 steps
Closest integer step count is -27 steps
...
16384.008

You can see that the uncalibrated 32KHz clock is 0.832 Hz too fast, and you can see that the calibrated 16384 Hz clock is 100 times better at only .008 Hz fast. One thing to be aware of is that the silicon calibration adjustment mechanism is performed occurs over a 64 second rolling window. In any sub-portion of that 64 second window, the clock might be a bit slow or a bit fast, but over each 64 second window, the average clock speed will be calibrated as desired. This means that an RTC clocked from a calibrated clock source might have a tiny bit of jitter due to the calibration mechanism, but for almost all RTC purposes, it can be ignored.

[PaulZC]

Nice work Robin - thanks for sharing!

u-blox GNSS modules like the ZED-F9P can capture rising and falling edge events with nanosecond resolution on their INT pin. The timing data is available in the TIM TM2 message.

They can only capture the timing data for one event in each "navigation" period (usually 1Hz, but you can push it to 25Hz). But they can count the total number of rising edges at faster rates. I haven't tested how fast they can count, but 32kHz shouldn't be a problem.

If you have time, please take a look at these examples in the shiny new version 2.0 of the GNSS library. You might find them useful.

https://github.com/sparkfun/SparkFun_u- ... IM_TM2.ino

https://github.com/sparkfun/SparkFun_u- ... IM_TM2.ino

Best wishes,
Paul

[robin_hodgson]

Sorry for the late reply, but the Great Pacific NW Windstorm of 2021 took out my power and internet for 3 days.

I was not aware of that capability on the ZED-F9P. That is slick! The only downside is the $220 pricetag. You can get a used HP5316B frequency counter for about half that (which I highly recommend), although the more modern ZED-F9P could probably be made even more capable than the HP frequency counter with a bit of software. I guess one advantage of the HP frequency counter is that it can measure analog signals, or signals at all kinds of voltage levels. I suspect that the ZED-F9P can only handle digital inputs.

The super-simplistic PPS mechanism will work with any $6 GPS module that brings PPS out to a connector. You can even use a GPS module that doesn't bring PPS out by soldering a wire to its PPS LED, which I have done before in a case of sheer desperation.