Suggestion to get maximum accuracy when reading frequency of external crystal

[VictorFS]

I'am working on a project using Teensy 4.1 where I read the frequency of a Quartz Crystal Microbalance (QCM) using the FreqCount library. My goal is to be able to detect very small changes on the QCM frequency (natural frequency around 5 MHz) caused by deposition of material (added mass) over time. These variations in frequency are in the order of units or tens of hertz.

Currently, my setup has very good stability on the frequency reading under controlled temperature. The problem is that when the Teensy heats up, the frequency reading increases, and when the Teensy cools down, the frequency reading decreases. This happens even if I keep my QCM temperature stable and with no mass deposition happening. Currently my Teensy runs inside an enclosure which is placed outside, so its subject to variations in temperature. The QCM is in a temperature controlled chamber.

I've searched the forum looking for answers and came across the threads below, but still have some questions I would appreciate the community help.

RTC Crystal not temperature compensated
Teensy 4.1 24Mhz Crystal 30 ppm
Using external OCXO with Teensy

1 - Is the change on the frequency reading probably caused the the Teensy 4.1 24 MHz crystal changing frequency due to temperature change?
2 - To solve or at least minimize this issue, could I simply replace the current Teensy crystal with other one such as this?
3 - Would you have other suggestion to tackle this issue? I am open to other approaches.

Thank you!

 

[PaulStoffregen]

1 - Is the change on the frequency reading probably caused the the Teensy 4.1 24 MHz crystal changing frequency due to temperature change?

Yeah, probably.

2 - To solve or at least minimize this issue, could I simply replace the current Teensy crystal with other one such as this?

Those look physically smaller than the 3.2 x 2.5 mm part on Teensy 4.1. But yes, if you could get one in the correct physical size, a TCXO would likely give an improvement over the ordinary crystal you have now.

3 - Would you have other suggestion to tackle this issue? I am open to other approaches.

Maybe an OCXO part would be better? Depending on the strength of its output, you might need to use a resistor divider to scale it down to a signal you can connect to 1 of the pads where you desolder the crystal.

 

[PaulStoffregen]

If you desolder the crystal and try connecting the output of an oscillator (rather than another simple crystal), this corner is the location to connect the oscillator output.

You probably should use resistors to attenuate the oscillator output waveform to about 1 volt peak.

 

[VictorFS]

That's great advice, Paul!

If a TCXO has enough temperature stability for my use case, what would be the specs I should look for when selecting the part? For example, input voltage, output signal form and voltage. Maybe if you could provide the exact part number of the current 24 MHz crystal used by Teensy I could find one with similar specs, but temperature compensated.

Also, regarding your last reply: So if I understood correctly, you are saying that I could dessolder the current crystal and apply a reference 24 MHz signal (e.g. coming from an OCXO or signal generator) directly to the pad you pointed? Leaving the other three not connected?

Thank you for you kind support as always.

 

[PaulStoffregen]

The crystal is spec is 24 MHz and 12 pF.

But you could use pretty much any 24 MHz crystal with different load capacitance spec by simply changing those 2 capacitors.

 

[mborgerson]

Rather than try to modify the T4.1 itself, you could connect a low drift temperature-compensated oscillator or RTC module to an input pin on the T4.1. You can then measure the frequency of that clock once per minute or so, and use its value to correct for the drift in the T4.1 crystal frequency. I used that technique with a DS3232 RTC some years ago to compensate for clock drift in the MPU crystal that was reading frequency from a pressure sensor. The stability was usually better than 2PPM/deg over 0 to 40C. I also used the output of a DS3232 in a software phase-locked loop to correct for the drift and inaccuracies of the RTC in a low-power logger that spent six months or more submerged in the equatorial Pacific ocean. We needed accurate time values to measure oceanic front propagation using data from multiple moorings.

Analog Devices/Maxim has lots of 3.3VC parts to choose from.

To get better long term stability than that, you may need to connect to the PPS output of a GPS chip----if your system will get good GPS lock at its location.

 

[VictorFS]

Hi mborgerson and Paul! Thanks for the insightful replies as always.

I ended up ordering two different external oscillator: Pletronics 1ppm VCTCXO and Connor Winfield 5ppb OCXO
My first attempt was to remove the standard Teensy 24 Mhz crystal and connect the output of the external Pletronics TCXO to the pad shown by Paul previously. It worked, and the frequency measurements are more accurate than before. However, I still didn't have the time to further evaluate the results or test the OCXO.

Rather than try to modify the T4.1 itself, you could connect a low drift temperature-compensated oscillator or RTC module to an input pin on the T4.1. You can then measure the frequency of that clock once per minute or so, and use its value to correct for the drift in the T4.1 crystal frequency

This is an interesting approach, as I could work with more standard frequency oscillators, such as 10 MHz. Finding those 24 MHz parts was really hard, and there aren't many available. However, I still couldn't figure out how to make this work.

See, I would have 3 different frequencies to deal with: 1 - Teensy 24MHz crystal, 2 - External frequency of interest that I need to keep monitoring every 2 seconds and 3 - The output of the external temperature-compensated oscillator or RTC. How to use all this info to be able to read frequency #2 without being affected by ambient temperature changes?

To get better long term stability than that, you may need to connect to the PPS output of a GPS chip----if your system will get good GPS lock at its location.

Unfortunately this is not possible for my application, as sometimes GPS signal is not available.

 

[mborgerson]

Without going into all the details, the algorithm is something like this:

1. Measure the frequency of the external stable oscillator with FreqMeasure on the T4.1
2. Assume that the external oscillator is spot-on. Calculate the PPM error of that value from the FreqMeasure value.
3. Apply that PPM error to the FreqMeasure value that you get when you measure the signal of interest.

The result should be the corrected value of the signal of interest. Errors should be limited to the accuracy of the external oscillator.

I've left out all the details of the sign of corrections, the calculation of ppm error, etc. etc. The correction factor is likely stable over a few seconds unless:

1. One or another of the frequency sources is perturbed by accelerations if the measurements are taken on a moving platform.
2. Temperature changes occur at rates faster than the rate at which you measure the stable oscillator to calculate the correction.

The calculation of the corrections likely involves a few floating point multiplies and divides. That might have been a time sucker on older systems without hardware floating point capability

 

[sbfreddie]

VictorFS:
I am often amused by people who see everything as a software solution. (I you only have a hammer everything is a nail) This type of solution in my option would best be to use a combination of hardware and software such as using a highly accurate oscillator attached to a clocked register with a trigger to start and stop counting in hardware. (This would be very fast and very accurate with modern circuitry) Then after the event is finished send interrupt to Teensy to read the count from the register and do with it what ever you like. This method would eliminate most all of the delays inside the Teensy that might effect the accuracy of the measurement.
Of course this describes the function of a standard Frequency Counter, of which we in the EE world have been using for a very long time. (Me personally since the 60's)

Regards,
Ed

 

[mborgerson]

VictorFS:
I am often amused by people who see everything as a software solution. (I you only have a hammer everything is a nail) This type of solution in my option would best be to use a combination of hardware and software such as using a highly accurate oscillator attached to a clocked register with a trigger to start and stop counting in hardware. (This would be very fast and very accurate with modern circuitry) Then after the event is finished send interrupt to Teensy to read the count from the register and do with it what ever you like. This method would eliminate most all of the delays inside the Teensy that might effect the accuracy of the measurement.
Of course this describes the function of a standard Frequency Counter, of which we in the EE world have been using for a very long time. (Me personally since the 60's)

Regards,
Ed

That hardware that you describe is exactly how I have been implementing frequency counters with microprocessors since the 1970's. Then as now, your precision and accuracy depend on the same factors:

1. Your precision depends on the number of bits in the counter register and the time interval over which you count the input transitions--assuming your digital inputs have clean transitions.

2. Your accuracy depends on the accuracy of the oscillator driving the counter and controlling the gating of the input signal. That's the difficult part unless you have a temperature-stable oscillator of known frequency. The 'known frequency' generally means having the oscillator calibrated against an expensive standard oscillator or a gps-disciplined oscillator.

The T4.1 hardware gives you lots of options for building a frequency counter: 16 and 32-bit counters with a plethora of gating and oscillator inputs, control registers to define how you gate the counters and select the oscillators, etc, etc.. That's how the T4.1 does things in the FreqCount and FreqMeasure libraries. The problem really comes down to the oscillators on the T41 board. The 24MHz oscillator can't match the stability of the oscillators in even low-cost hardware frequency counters--which often cost as much as a T4.1.

I didn't worry about all these issues until I was in the Navy in the early 70's and got to play around with a few million dollars worth of telemetry intercept equipment. I didn't even know what a TXCO was before that---even though I'd spent hundreds of hours twiddling the dials on some very good HF receivers.

 

[AndyA]

One further suggestion, a GPS engine with a PPS output will give you a very accurate 1Hz frequency reference (or depending on the make a configurable frequency) that you can use as a reference to calibrate the teensy clock or enable counter inputs. This does have the requirement that the receiver (or at least its antenna) has a good view of the sky so it has restrictions that other solutions avoid but if practical for your application it gives a very good accuracy/price trade off.

 

[VictorFS]

Thank you all for the replies and suggestions!

Without going into all the details, the algorithm is something like this:

Ok, now I got the general idea. I will try this out in the future depending on the outcomes of my current test setup.

This type of solution in my option would best be to use a combination of hardware and software such as using a highly accurate oscillator attached to a clocked register with a trigger to start and stop counting in hardware. (This would be very fast and very accurate with modern circuitry) Then after the event is finished send interrupt to Teensy to read the count from the register and do with it what ever you like. This method would eliminate most all of the delays inside the Teensy that might effect the accuracy of the measurement.
Of course this describes the function of a standard Frequency Counter, of which we in the EE world have been using for a very long time. (Me personally since the 60's)

So as far as I understand, in order to achieve this I would need to have an external oscillator and an external clocked register? My preference would be to keep external circuitry to a minimum. That's because my project already has a PCB with fixed position for everything. Unfortunately, I didn't account for this issue (Teensy frequency count changing due to temperature). My only option for now (before modifying the PCB project and manufacturing a new version) is to hack the PCB and / or Teensy, or use software corrections.

One further suggestion, a GPS engine with a PPS output will give you a very accurate 1Hz frequency reference (or depending on the make a configurable frequency) that you can use as a reference to calibrate the teensy clock or enable counter inputs. This does have the requirement that the receiver (or at least its antenna) has a good view of the sky so it has restrictions that other solutions avoid but if practical for your application it gives a very good accuracy/price trade off.

GPS PPS seem to be the clear way when available. Unfortunately I am not able to use it due to a number of reasons, such as lack of GPS signal in some places, like underground or inside buildings. My application needs an standalone solution.

I am still evaluating my first attempt, which was to replace the Teensy 24 MHz crystal with an external signal from a 1 ppm 24 MHz TCXO. I will come back to this thread to share my results.