8 – 11 digits reciprocal frequency counter 0.1 Hz – 150 MHz

[Kleinstein]

The linear regression gets the same resuslt as using a weighted average over slopes from the 1st and last, 2nd and 2nd last, 3rd and .... (at least if the points are nominally equally spaced).
It is diffenrent from using only short measurements one after the other - this may end up the same as just looking at the 1.st and last point.

Calculating the linear regression looks complicated, but for the line there is a closed formula. So it can be relatively easy - still take some care with numerics if more than 8 digits are wanted. It may need more than 32 bit math.

[erikka]

When looking at the code I initially missed the summing of the delta counts, now its clear, thanks

[erikka]

And its working!
The graph is measuring the drift of two xtal oscillators versus each other
Vertical axis is relative deviation from average over total period, horizontal axis is measurement (one second gate time)
The blue line is purely based on counting (resolution just below 10e-8), red(ish) line is using a 40000 sub measurement regression and has resolution that seems to be 10e-9 or better.

Would adding an analog phase measurement (like in the HP application note on measuring time and frequency, possibly 100ps resolution) provide additional benefit or is the regression already expected to be that good?

[iMo]

..Would adding an analog phase measurement (like in the HP application note on measuring time and frequency, possibly 100ps resolution) provide additional benefit or is the regression already expected to be that good?

I did with analog, but switched to tdc chip. You will get additional 2-3 digits..

PS: with your max phase diff of 10ns, and for example THS788 (13ps res) you get 770 phase "steps" you have to incorporate into your calculation..

[erikka]

After implementing the analog phase detector the difference between the input to the regression without and with phase detector is obvious
Input to the counter is 10.002MHz, reference is 10MHz. The resolution of the phase detector is set to 1/100
The first graph is without phase detector. Y-axis is delta with input  frequency. X-axis the sub measurements within the 1 second gate time.
Second graph is with phase detector.
The spikes are probably caused by the phase detector not being perfectly aligned with the counter, e.g. it wraps when the counter does not yet see the +/- count.
Without the spikes the convergence with phase detector is indeed 100 times faster
Anyone know how to do this alignment? Or how to mathematically eliminate the misalignment?
The measured frequency by the regression with phase detector active is just a bit too high, as expected from the graph

[Kleinstein]

For "alignment" of the phase detector it shoud be about getting the right count of the timer, to the phase measurement. It depends on the details of the phase measurement how one could implement a way to get the correct count. This may be something like a 2nd slightly delay reading or modified way how the phase measurment is made.

Edit: if it is just about getting the scale factor right, no the counting, that one could use a test frequency in a known no so simple ratio to the reference and than use that to adjust the scale to get the best fit. Test test frequency may be generated by a PLL, with a slightly odd ratio like 15/16.

[erikka]

 The phase can be regarded as the fraction of the count. The broblem is the roll over of the fraction ( from 0.99 to 0.00 ) is not aligned with the increment of the count. This is due to different delays of the up edge to the counter versus the up edge to start the phase detector. Given the above measurement it should be possible to automatically detect and tune the misalignment in a calibration step. Or is there a better way?

Edit: it is clear how to adjust the phase measurement once the the required phase shift to align with the counter is known.
In above measurement it seems to be possible to detect the spikes and calculate the phase shift that removes them. Correct?

[Kleinstein]

An alignment is not so easy, even with an accurate measured alignment, there is still some possible drift and at least a small range if a possibly large error. Just from alignment it may not be possible to decide if the is before or after the counting part. So at best one would get some undefined zone and points that fall in this range would have to be ignored or used with only the count.

[erikka]

Excellent suggesting. Ignore measurements with phase close to phase wrap in the regression or ignore phase if not enough measurements are away from phase wrap. Will implement and test tomorrow and see the the combination of regression and phase detection gives the expected accuracy

[erikka]

It works!
The phase is rotated with a fixed factor calculated from a dump of the 5000 measurements done in one second of a 10.0002MHz signal versus a 10MHz reference
In the graph you see the rotated phase (0-99) in red and the error of the calculated frequency since start of measurement in blue. The vertical axis is frequency error times 100 so the maxima of the graph are +/- 1Hz error
There are still errors when the phase wraps but the systematic error for certain frequencies in the linear regression is gone. Even without the linear regression you get with a breadboard implementation of the counter using a 10MHz reference, without multiplying to 100MHz or higher, accuracy in the order of 10e-9  (measure 1MHz with error of +/- 0.001Hz with 1 second gate time) except when the phase wraps at the start/end of the gate time. The accuracy is as expected with 10MHz reference, one second gate time and phase resolution in 100 steps.
Next step is quadratic compensation for non-linearity in the phase detector and a dead-bug style prototype to see if the phase detection can be done in 1000 steps with less noise. I'm not sure the regression will still add value as its purpose was mainly to average over the total gate time to avoid unlucky phase errors at the end of the gate time.
It will be difficult to run the analog phase detector much faster then 10MHz, having 1000 steps already gives 100ps resolution.

[Kleinstein]

If the linear regression still helps depends on the type of noise that is present. If the noise is a frequency modulation, but no noise in the trigger / phase detection the linear regression does not help. If the noise is more like noise in the trigger  (e.g. a sine signal with white noise) the regression helps quite a bit, but higher resolution in the timing does not, as the signal / trigger limites the phase noise.

[erikka]

Indeed
An advantage of the phase detection seems to be in low frequencies as there are insufficient edges to generate data for the regression. With 1kHz you still get all 9 digits with the phase detector.  Not sure why you would need 9 digits with 1kHz though

[Kleinstein]

For my phd work I did 8 digit frequency measurements in the 100 Hz-10 kHz range. This was with the aditional complication that the signal was a sine and limites "gate - time". I actually did not need the frequency to that resolution but it did work quite well.
The phase detection / time interpolation helps if the trigger is really good,  e.g. with a clean square wave. It helps nothing of the trigger is not accurate, e.g when trying to measure the mains frequency.  Measuring the mains frequency with high resolution is actually not as easy as it sounds at first.

[Dbldutch]

Hi,

After building a bare minimum Raspberry Pico version, that is described in another forum post, I now started to build this version.
The Pico version was intended as a proof of concept for me and it passed with flying colors, so I have high hopes this one will give me some more resolution.

I have found a few things while using the BOM that Michael posted when I was ordering parts.
The BOM is about two years old, and as you know, things change...

First of all the 74AUP1G parts are hard to get and not in stock everywhere. I had several 74LVC04, -14 and -74 parts that I used instead.
UPDATE: A 74LVC04 for U5, the oscillator buffer, does not work. It has to be a 74AUP1GU04 version to lift the 0.8Vpp oscillator output to a 3V3 level for the STM.

This project will be the first time that I'm using the STM32G431, and I stumbled on ordering the right version.
I had no idea that there are so many. In any case, the proper one for this board and application is the STM32G431KBT6.
The partnumber for the MAX202 is no longer correct, I ordered the version listed on the BOM and got the wide package.
What you need is the MAX202EESE+ version.
UPDATE:
If you don't use a true RS232 to USB convertor, but a TTL to USB convertor, you should not install this chip at all.
The MAX232 does a level shift of the signals which precludes you from using the TTL to USB convertors.
You can bridge the Tx and Rx connections of the chip through a small (100R) resistor to add some protection to the STM ports.

The 3V3 regulator on the BOM is the TS9011, but is very hard to get, so I used an XC6206 that I already had in stock instead.

UPDATE: After replacing U5 I have a working system.

I'll add more info when I make more progress.

Enjoy!

Update:
I started a post on my own Blog with more information.
It can be found here : https://www.paulvdiyblogs.net/2023/01/a-high-resolution-reciprocal-counter
Comments are better handled here.

[David Hess]

The phase detection / time interpolation helps if the trigger is really good,  e.g. with a clean square wave. It helps nothing of the trigger is not accurate, e.g when trying to measure the mains frequency.  Measuring the mains frequency with high resolution is actually not as easy as it sounds at first.

The usual recommendation that I see is to phase lock a clean source to the dirty 60 Hz line, and then measure that.  Of course now a sampling converter could be used and the whole measurement could be done through digital processing.

[erikka]

Just for fun a post on a different project, ignore if not relevant.
Today I completed finally the full prototype integration of a long running project.
Its a 2 input 0.1 Hz to 6GHz counter/timer, including analog front-end for edge detection direction and trigger level setting up to 100MHz, one channel with up to 6 GHz pre-scaler, Integrated GPSDO and 10 MHz reference input/output.
The counter is a reciprocal counter running its duration counters at 200MHz, augmented with two 25ps resolution time to digital converters  to increase the counter  accuracy to below 1e-10, this without using the built-in  linear regression,
The resolution of pictured setup is less due to the terrible ground structure.
Still a lot of work needed before this is a nice usable counter/timer.

[Dbldutch]

Nice project erikka,
Will you post the development by itself?
If so where?

Paul

[erikka]

The ambition is to bring this as a next product so the design will not be open.

[mino-fm]

The ambition is to bring this as a next product so the design will not be open.

That's fine. So let us share pictures.
I'm using two TDCs too and only adding the right prescaler results are shown up to 999 GHz.

[erikka]

I'm using two TDCs too and only adding the right prescaler results are shown up to 999 GHz.

Just some questions out of curiosity
Do you have this running? great project!!!
Where you able to measure the pulling between the two inputs? In a first version of my HW (without the TDC's) the pulling was very visible.
Interesting to hear if the TDC's do deliver the promised resolution.
I see you have two stages in the SET-CAP1 and CAP1 generation. Why was this needed? I don't understand how you can measure a single start/stop event with this.
I see you use two TDC's for CAP1 to STOP using different calibration clock's (90 degrees' shifted I assume). Can you give some insight in why this is needed?
Do you still need a fast time counter (measuring the CAP moments) or where you able to relax this due to the TDC's
As the STOP of the TDC's is not coming from the retimed latching of the time counters but from the 10MHz, how do you know in which tick of the fast counter you are?

I decided to put all logic inside a CPLD. The schematic is basically the inputs into the CPLD and the CPLD connects with many pins to the MCU and TDC's and the MCU uses SPI to control everything, just like you did.
I'm using only one TDC per channel and a single D flipflop for the CAP generation. But as I've not done a PCB layout yet I do not know if the TDC's will deliver the required performance.
By shifting the input versus the ref clock  in steps of 1 ns it was possible to confirm the functionality of the TDC's

[erikka]

I think I understand how you eliminate the resampling uncertainty. The two 10MHz clocks work like the I/Q clocks in a complex downmix and having the output of both TDC's allows to eliminate the wrapping uncertainty. Nice trick!

[erikka]

Here is the block diagram. TDC B is not yet integrated in the prototype HW.

[tverbeure]

This thread was useful for me to better understand how linear regression can help increase precision in frequency counters. I ran a couple of simulations to verify some of the finer points and wrote things down in this blog post: https://tomverbeure.github.io/2023/06/16/Frequency-Counting-with-Linear-Regression.html

[tggzzz]

This thread was useful for me to better understand how linear regression can help increase precision in frequency counters. I ran a couple of simulations to verify some of the finer points and wrote things down in this blog post: https://tomverbeure.github.io/2023/06/16/Frequency-Counting-with-Linear-Regression.html

That's a well-written and useful blog, with decent references. I wish all were like that!

I will read it in detail when I get the time.

Thanks

[Georgy.Moshkin]

This thread was useful for me to better understand how linear regression can help increase precision in frequency counters. I ran a couple of simulations to verify some of the finer points and wrote things down in this blog post: https://tomverbeure.github.io/2023/06/16/Frequency-Counting-with-Linear-Regression.html

good information. I used histogram method and now wondering what is better. When gaussian-like peak is added to high resolution 1d histogram array for each measurement, a final peak formed over the time. Linear regression seems a better option but only if measurements do not contain noises. What I tried to achieve is to not only count the pulses, but also detect noise or signal interruptions, while still providing correct measurement. Many frequency counters show wrong results if signal is too weak, I experienced it many times when used HMC363 prescaler with weak input signal.