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

[mino-fm]

To do high resolution reciprocal frequency counting you need a fast reference clock and high speed counters. Fast computation could help you to get more digits of resolution. To avoid special parts like PLDs or TDCs modern ARM-controllers will give good performance at low price.
Searching for a newer low pin count controller, I’ve found the STM32G431 in LQFP32. It has the same package as ATmega328AU (Arduino) and therefore it is easy to handle. Adding some gates and D-FFs are sufficient to get a versatile counter.

Please look at the user manual if this counter could accomplish your demands: http://www.mino-elektronik.de/download/Fmeter-G431-GB.pdf  If not, feel free to add your own functions/commands.
At this time only a german version of source code is available, but if wanted, I could translate the desciption and comments step by step in the future: http://www.mino-elektronik.de/progs/Fmeter_G431/Fmeter_G431_V1.zip

I like to use these tiny 74AUP1G.. devices. But other parts like 74LVX.. or 74VHC.. should be working as well.

For the first sight, I’ll add schematics and a piture of demo-board.

[fourfathom]

With your input protection diode champing to +3.3V, you should have some additional protection on the +3.3V rail.  Otherwise a strong input signal can force +3.3V to a much higher voltage (via rectification) and damage your 3.3V components.

[dmendesf]

Very nice project, well done. Have you looked at the stm32g474 with the high resolution timer? Probably has more pins/is more expensive but could get more resolution at higher frequencies. Not a critique, just a meaningful discussion about part selection for the task at hand.

[coromonadalix]

nice project

For the tcxo adjustment, i've seen this on other project
https://gerrysweeney.com/racal-dana-199x-diy-high-stability-diy-timebase-hack-for-under-25/

relying only on trimpots will add ppm errors ??

[tggzzz]

That article refers to the need for a  “temperature stable variable voltage". That's only part of the story: it is also necessary to have an appropriately low drift over time. Some voltage references are better than others in that respect.

[Kleinstein]

Very nice project, well done. Have you looked at the stm32g474 with the high resolution timer? Probably has more pins/is more expensive but could get more resolution at higher frequencies. Not a critique, just a meaningful discussion about part selection for the task at hand.

AFAIK the HRTM high resolution timers only give additional resolution as a timer for PWM output, but not for input capture.

The next step up on the hardware side is to have some semi analog time to analog part and send that to the ADC. This can than give sub ns resolution for a single capture event. It may need an more adjustable input divider.

I have not looked at the source code. The software side can get mode resolution from looking at more than just the start and end of the interval. Those super high res counters use this.  It depends on the signal source if looking at more slopes also helps with noise. Using at least a few slopes can often help, especially with a rather simplistic input stage.

[bson]

With your input protection diode champing to +3.3V, you should have some additional protection on the +3.3V rail.  Otherwise a strong input signal can force +3.3V to a much higher voltage (via rectification) and damage your 3.3V components.

I'd shunt it to ground instead, with a suitable TVS diode.  Put a resistor on the input of IC8A so if it goes up high the IC8A input will be current limited until the clamp kicks in.  Otherwise the IC8A input will shunt it onto rail.  This would help with ESD as well.

A schematic note: personally, I like to label µC pins as the function they're actually used for, in addition to the GPIO function.  IMO this greatly helps convey theory of operation and system design.  For example, the 1 PPS CAPT2 signal goes to PA15.  What is that used as, a timer capture?  Interrupt?  Timer reset?  Input or output - that's obvious in this schematic, but not always so.  It never hurts to document the seemingly obvious!  In addition, I set the direction and other properties of the pin correctly according to the function it's used for.  (Even though coming out of POR it might default to something else briefly - which needs to be considered if it might have any impact.)  Just my $.02.

[HB9EVI]

thanks for sharing...
I already built a reciprocal counter according to your codes on a STM32F429, but I'm very tempted to build (another) one on the lower profile STM32G431.
certainly I'd use again a TFT display instead of the 16x2 LCD

[David Hess]

To do high resolution reciprocal frequency counting you need a fast reference clock and high speed counters.

No, a fast clock and high speed counter is not enough.

Common designs which work the way you describe phase lock a 100 MHz clock to a 10 MHz reference, (1) which yields a 10 nanosecond clock and 8 digits per second.  Higher resolution counters use interpolation (TDC) of one form or another which considerably relaxes the requirements for the high speed clock and counter to yield 9 digits or more per second.

A heroic design using a 1 GHz clock and ECL counters would be fascinating, but by itself still only yields 9 digits per second.  In the past ECL was required to even count with a 100 MHz clock.

(1) Phase locking the clock to the reference is actually preferable because modulating the clock with random noise prevents error from synchronization between the clock and input signal.  This is a common feature in high performance counters.

[mino-fm]

For clarification let me add some more information: http://www.mino-elektronik.de/download/FMeter-G431-GB-tech.pdf

This G431-counter is the little sister of 'strong' brothers based on STM32F407 ..F730 .. H750 using TDC + LCD and TDC + 4.3" TFT too, giving up to 12 digits/s.
My intention was not to show the 'best' counter but the 'finest' one. Another sister is coming soon ;-)

[bson]

The most important spec in a counter isn't the # of digits, but the jitter noise floor in a suitable unit, like ps.  This includes not only the TDC precision and accuracy, but also system aspects like reference stability.  If you're going to use a counter for bench measurements you really need to know the jitter spec.

[mino-fm]

A 16 MHz XO is used to give Fin and ext. Fref to see how stable measurements are (resolution). Measurement interval is 1 s.
12 digits are shown. Decide yourself.
There is no doubt, for highest accuracy you need stable sources for Fin and Fref.
But internal VCTCXO could be sufficient for 6-7 digits @ 1000 meas./s.
 

[up8051]

Would you share the PCB design?

[mino-fm]

Elecrow or JLCPCB and others are able to use this file directly: http://www.mino-elektronik.de/progs/Fmeter_G431/mino-counter.zip

[magic]

What's this mathematical method you use to extract more resolution than by naive reciprocal counting?

I'm not familiar with the MCU you use and your software, but I see that you route the input frequency and signals derived from it to multiple pins of the MCU, sometimes even the same signal to multiple pins. If your peripherals run synchronously to the MCU core and sample those signals, I hope you are aware that the same edge of the input clock may occasionally be seen by different inputs in different core clock cycles, possibly leading to intermittent errors.

[mino-fm]

As described above it's "linear regression" and it's independent of MCU.

Typical reciprocal counters are counting the number of events and synchronously the exact time (n x 1/Fref) to calculate the result. Time measurement has a +/- 1 error, so the resolution is given by +/- 1 x 1/Fref. Here Fref is 170 MHz (1.7E8) and timing error for 1s measurement time is therefore +/- 6E-9. That is sufficient for 8 digits/s.
FMeter-G431 works this way for low frequencies near 1 Hz.

At higher frequencies (let's say 1 MHz) this counter is able to do up to 200000 measurements/s. A simple way would be calculating the mean value of these samples and getting the same result as before. But these samples offer more information because each of these 200000 intervals can have small phase differences. @ 1 MHz a sample allmost will show 5 events, but this can vary between 4 - 6. Due to these events time is various too.
Linear regression can handle these variations to evaluate the optimal line across all samples. The improvement of n samples is square root of n. At given 200000 samples improvement is a factor of arround 450.

As shown before we had a resolution of 6E-9 with one sample/s. To show our improvement we must devide 6E-9 by 450 and get 1.3E-11. This means resolution of 10 digits/s are reliable - theoretically.
For each sample MCU has to calculate: 4 x uint64_t additions, 2 x double (64 bit) multiplication and 2 x double (64 bit) additions. You can see that these calculations take a little while and will produce a small offset error due to rounding temporary results. (This is why the mean value of curve shown above will not be exactly 16 MHz!)

Resolution != accuracy!
But for high accuracy the resolution of measurement has to be the same or even higher.

Resolution of FMeter-G431 at slow measurements is one point. The other point is high speed measurement with reduced resolution. For automatic tests up to 1000 meas./s can be done. You can calibrate an 32768 Hz signal to < 0.1 ppm in arround 10 ms. This all is done by a cheap but "speedy" MCU.

[Kleinstein]

A way to get more resolution than a simple reciprocal counter is to look at more than the first and last time stamp. The time stamp values in the middle can give extra resolution, at least most of the time. Depending on the noise sources the best method to look at the time stamps varies:
with domonant frequency noise (e.g. a not so good oscillator with slowly modulated frequency, but no extra effor from the input trigger) the best is to look at only the 1st and last time stamp, so the classical reciprocal counter. Including a few more points from the start and stop can still improve the quantization noise.

The other extreme is good oscillators, but added noise later on as white phase noise (e.g. a small signal and noise from the trigger part). Here the best (lowest noise) case is a linear interpolation for the times of the time stamping. This effectively gives a linear weight function for the time stamps: 100% for the start and stop and 50% for the time stamps at some 25 and 75 % of the time. As a by-product one can get a crude estimate of the phase noise - useful with not so stable signals. Because of the different weights the gain is a littel less than square root N , but it stil scales this way. AFAIR it is something like sqrt(N/3).

The usual case will be something in between. Something like using the first few (like 10%) time stamps at the start and end could be a reasonable compormise to suppress at least the rrors from the trigger circuit.

Otherwise the way for more frequency resolution is getting better time resolution, e.g. with an interpolator.
For very low frequencies (e.g. like 50Hz) sine signal  the best method may be a least square fit for the whole curve. This kind of improved on the trigger and can better deal with noise.

[FransW]

Quote: Resolution != accuracy!
Maybe superfluous, however:

Accuracy vs Resolution   
What`s the difference between accuracy, repeatability and resolution.q.
 
Three terms that are well used in the feedback industry are `accuracy`, `repeatability` and `resolution`. These words are sometimes used
interchangeably. This causes confusion when choosing an encoder or discussing encoder specifications with another person. A clear definition and illustration of each term may help to clear up this confusion.

Accuracy - designates how close a measured value is to the true quantity of what is being measured. Without comparison to a standard, accuracy cannot be determined. The accuracy of products is always stated in comparison to a formal, agreed upon standard in the industry.

Repeatability - describes how well a system or device can reproduce an outcome in unchanged conditions. In some applications, repeatability is more important than accuracy. If the system is repeatable, an error can be mapped and compensated for. Resolution - is the smallest increment the system can display or measure. A system can have a high resolution with poor repeatability and accuracy.

Resolution is a primary concern in applications regarding speed control or surface finish. Think of a clock. If the clock is mechanically sound, it should be very repeatable. Each movement of the second hand should happen at a constant interval. The clock can be used to reliably time events, from start to finish, but it may display the incorrect time. Until the time on the clock is compared to some established measurement of time, there is no way to tell how accurate the clock is. Once compared to a known standard, the accuracy of the clock can be determined. The resolution of the clock can be determined by the number of ticks in a minute or the amount of increments shown on the face. If the clock has no second hand, the highest resolution you can achieve is to half minutes. If the clock only had an hour hand, you would only be able to determine the closest half hour. Most people would prefer to use an accurate and repeatable clock, with a decent resolution. The importance of these three factors is wholly dependent on the application.

[magic]

At higher frequencies (let's say 1 MHz) this counter is able to do up to 200000 measurements/s. A simple way would be calculating the mean value of these samples and getting the same result as before. But these samples offer more information because each of these 200000 intervals can have small phase differences. @ 1 MHz a sample allmost will show 5 events, but this can vary between 4 - 6. Due to these events time is various too.
Linear regression can handle these variations to evaluate the optimal line across all samples. The improvement of n samples is square root of n. At given 200000 samples improvement is a factor of arround 450.

So I gather you take a series of (timestamp, aggregate count) pairs and calculate the best linear fit to those points to find the slope? Okay, that sounds sensible.

The other, hardware specific problem is completely unrelated to interpolation. The question is: can you guarantee that the last edge that you have captured has been counted by the counter? Can you guarantee that no later edge has been counted? Can you guarantee both, even if the counter and the input capture observe the same edge in two consecutive MCU clock cycles?

There is one very obvious algorithm which is wrong: at the end of measurement, use some magic wand to atomically snapshot the counter in the same cycle when the input capture triggers. With this method, if things go wrong, you could literally end up counting 3Hz as 2Hz. Intermittently.

I can think of two "easy" solutions: synchronize the input clock to the core clock as the very first step, or completely stop all counters on a falling edge of the input clock and restart the process for the next submeasurement after all data have been read out of the counters. And I'm not entirely sure of the latter, I came up with it just now.

Or a harder way: capture a series of snapshots of relevant counter registers and either reject the measurement if it isn't perfect or try to untangle what has happened to save the measurement.

So I wonder how you solve that?

[Kleinstein]

The counter for the capture events uses the same internal input path. So it counts how often the input capture is executed, with possibly a pre-scaler before if they come in too fast.  So there is no real problem in getting the number of periods wrong by 1. There is enough buffering so that it is very unlikely (very unstable frequency, like short bursts) to miss a capture event. AFAIK the STM32 even have hardware to detect capture overrun. 
I would expect the µC to be able to handle some 5 million capture events per second.
If the frequency is higher one needs to use a per-scaler to reduce  the rate of capture events. This does not add much error, if at all. AFAIK the STM32 already has pre-scalers internally so that the external one is only for really high frequencies.

Things get more complicated if an external time interpolation is used. However this would usually be combined with synchronization to the counter clock.

[magic]

The counter for the capture events uses the same internal input path. So it counts how often the input capture is executed, with possibly a pre-scaler before if they come in too fast.

That's OK if the STM can do it. I just noticed that there are separate signals called "count" and "capt" going to different pins and I wasn't sure how it works. I have seen similar projects on old AVRs where this issue didn't appear to be addressed (counting on ICP events is not possible).

[Kleinstein]

The input part with the flip-flops looks indeed a little odd. I had not looked at that part very much.
There is not the expected switchable pre-scaler (e.g. :1 or :16). The usual internal prescaler for input capture is :8 max. More may be done with DMA transfer and ignoring some data, but this can get messy. With the external :2 it may just work to handle capture event coming in at close to 10 MHz, but this could be quite speed critical.
The plan seems to really use separate count and gate for capture and this may indeed go wrong.


I have done a counter version with an AVR - there was not need for HW counting on capture. Counting the capture event was done in software - that maximum rate it could handle the data was relatively slow anyway. So it has a relatively large external pre-scaler, so that the frequency going to the µC is not too high.

So I did not look to much at the circuit and assumed the simple solution of 1 signal without prescaler and one with going to 2 capture inputs. Depending in the signal the µC decides which input to look at.

[magic]

I actually have a certain idea how to do it on AVR without big hassle. I think it should work.

Pre-sync the input waveform to AVR's clock with 74HC74 or similar and feed it to T0 and ICP1.
Set counter0 to count the input clock.
Set counter1 to capture the input clock.
Periodically wake up and read x=TCNT1L, y=TCNT0, z=ICR1L in this order using LDS (2 cycles each).
Account for high bytes, overflows etc.
If z>x+2, increment y by one.
Unless nothing has changed since the last time, our new output pair is (z,y)

On 1-series it seems the event system would permit elimination of the external synchronizer.

[mino-fm]

After receiving new PCBs I assembled a new board. I don't know why, but it works. I assembled another board using STM32H730. Max. input frequency is > 250 MHz and 1 MSPS are done. I don't know why, but it works too.
I'm a lucky guy!

For people who like their vintage AVRs: use it and be happy. For people who like their 5-digit $ 4,99 counter with 20 GHz prescaler: use it and be happy.

[up8051]

I like the project very much  and I have plan to build one.
Can you additionally share BOM in particular the type of VCTCXO, it would be easier to order parts.

[mino-fm]

Please notice, to reduce diversity I've changed some parts: http://www.mino-elektronik.de/progs/Fmeter_G431/BOM%20mino-counterG431.pdf
For latest information please take a look at original (german) site: http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp_G431

[magic]

For people who like their vintage AVRs: use it and be happy.

Haha, I'm testing my least squares regression on AVR right now
The output doesn't seem quite right yet but I will get there
9 digits of resolution for 8 bits of CPU, ARM can't compete
If I get it to work

[Kleinstein]

When doing linear regression is absolute makes sense to have a slightly more powerful µC than the AVR. With the AVR the speed the regression can be calculated in real time is limited, probably to something like 100000 time stamps per second. Using more time stamps especially helps against jitter and this especially makes sense if the time resolution is already good to start with.

I have an AVR solution looking at mode points, though not with linear regression, but averaging over some at the start and some at the end, as this is faster to calculate.

The linear regression is suited for the case of phase noise, like from the trigger circuit or a low signal level. An example would be measuring the mains frequency: A slightly odd challenge for a time nut, but still a challenge. The linear regression type can help here too, though not for 8 or 9 digits, but is can make the difference from 5 to 6 digits.

[magic]

Under favorable conditions, the most immediate problem is "quantization noise" due to limited reference frequency. My current code takes ~1s measurements with ~69kHz oversampling* and the output is short-term stable to 8 digits when counting a second MCU crystal oscillator. I can actually see them drift against each other. Without oversampling, it would take several seconds to get the same resolution. OP reported similar gains.

I don't know if least squares fit is the optimal solution to that, by the way, but it helps.

*and this will need to be reduced a bit if it is to count correctly below 1MHz, fail

[Kleinstein]

The least square fit is the optimal solution for white phase noise. If the noise is more like frequency noise, it gives too much weight to the points in the center and the extreme case of no added phase noise (including quantization) the simple case of using only the first and last point is best  (maximum likelihood estimator and thus an asymptotically best estimator).
Usually the "quantization noise" looks like phase noise and the trigger circuit also gives some phase noise. So the linear fit to the phase is often a good solution.

[mino-fm]

My current code takes ~1s measurements with ~69kHz oversampling* and the output is short-term stable to 8 digits when counting a second MCU crystal oscillator.

8 digits are nice!
Let me show you a diagram with around 8 digits: Fin = 16 MHz (XO) @ 100 measurements/s, recording time 2 minutes.
Please show me your diagram under the same conditions.

[magic]

No 16MHz because that's my reference clock and it's just an MCU breakout board without prescaler, but I can do 6MHz for you.

I would say it's consistent with theoretical predictions regarding relative performance; 10x difference in reference clock and similar sampling rate gives 30x advantage at short intervals. (I managed to fix the bugs without slowing it below ~66kHz).

Neither version appears to reach the theoretical minimum of Fref/sqrt(nsamples) of peak-peak noise

It should be possible to push that ARM further with some software love, considering the faster clock and wider datapath. My code spends literally half of the time doing loads and stores to SRAM and more than half of the reminder doing multi-word arithmetic, that would mostly go away on a 32 bitter.

edit
Y axis is ratio of deviation from the first measurement: xn/x1-1 was the exact formula.

[Kleinstein]

The data points in the center get a reduced weight ( this is natural to the linear interpolation formular) and the gain in resolution is thus less that the square root of the number of samples. There is an additional essentially constant factor to give less advanatage with more points.

The ARM has a 2 fold advantage:
1) possibly faster timer clock (like 100 MHz - though this may need extra care with the sync).
2) higher computational speed and thus more time stamps to work with, if the signal allows.

[magic]

Meh, I posted nonsense yesterday and nobody is calling me out.

My calculation of 30x theoretical improvement assumed that 10x higher clock means 10x more oversampling, but that's not the case. I should be almost exactly one digit behind you in resolution and quantization noise, regardless of SPS.

So dunno where the remaining 3x come from, maybe even legitimate jitter of my crystals
The truth is, I don't have enough of a lab to really verify performance of this device.

[Kleinstein]

The faster µC alao allwos faster oversampling: it may not be exactly 10 times, but close. This of cause only applies for high enough frequencies - it won't help with 50 Hz.

[magic]

OP says his sampling rate is only 50% higher than mine. In 10ms the difference is 1000 vs 661 - hardly a big deal. The extra noise has to come from somewhere else.

[mino-fm]

Y axis is ratio of deviation from the first measurement: xn/x1-1 was the exact formula.

I played with other versions of reciprocal counters and I'll try to show comparable diagrams to your's shown above, which I repeat first (magic-count120.png). G431-rel%-comp.png uses the same scaling. I reduced recording time to 10 s.

After that let me show diagrams with higher resolution scaling (HR) and other MPUs and circuits: G431 (same as before), STM32H730 (1 MSPS) and STM32F407+TDC7200 (about 50 kSPS).

I think everyone will understand why I called counters using AVRs 'vintage' ;-)

[Kleinstein]

I still have a slight problem in understanding the sync circuit part. I think with an external asynchrous signal (which is the normal case),  I still see a chance to get at least an occasional glitch if the sync does not work correct.

The comparison is a littel unfair - using the meters own clock excludes errors from clock jitter. In addition it excludes possible glitches from sync errors - even a noramlly working version can have rare glitches when hitting a metastable state.

I still agree that the higher clock in the ARM can be an advantage. The other advanatge is the inlcuded prescaler for the capture mode - however I am not sure this is suffient without an external prescaler.

[magic]

If these are measurements of a frequency derived from the reference clock then it's apples to oranges. With some luck (alignment of gating intervals with input cycles) I can produce a flat line under such conditions, otherwise it's periodic oscillation on some far away digits.

My crystals suck donkey balls. Attached below, 5000 samples at ~1.4SPS and cherry-picked best 500 samples from 3500~4000. And this was taken with a blanket wrapped around the two boards, you wouldn't want to see it before I have no way of knowing how much of the remaining crap is measurement noise and how much is the crystals. Your own theory predicts I should be one digit behind the G431, on the basis of 10x slower clock.

It is my understanding that metastability "should" not be much of an issue because IC designers strive to push its risk into "absurdly unlikely" territory. How much unlikely is a proprietary secret, I guess That being said, repeating the risky condition a few million times per second perhaps increases the risk.

By the way, I also haven't implemented any protection against ICP1 and T0 reacting to the same event in different clock I think it can be done in software on MCUs with 1 cycle access to Counter1 registers, but I tested on ATmega32U4 which lacks this ability and I haven't built an external sychronizer for it either.

[mino-fm]

The comparison is a littel unfair - using the meters own clock excludes errors from clock jitter. In addition it excludes possible glitches from sync errors - even a noramlly working version can have rare glitches when hitting a metastable state.

It seems to me that nobody reads what I have written. MPU-clock is 10 MHz VXTCXO and input frequency is 16 MHz from XO (20 years old in DIL14 package). G431 does 200 kSPS, continuously, without any gap ...
If I would use only MPU clock, you would see a straight line of 10.0000000000 MHz.

Your own theory predicts I should be one digit behind the G431, on the basis of 10x slower clock.

Where? You spoke about: "9 digits of resolution for 8 bits of CPU, ARM can't compete"

[mino-fm]

At last, I would like to show low-frequency performance of this counter. After power-on a 1-pps signal (EM-406A) is logged.
1. picture shows warm-up of local VCTCXO and 1-pps jitter. Because of gapless measurement no pulse is missing. Dimension is 's' (1/f) so jitter can be estimated directly. Here it is around 60 ns.
2. picture shows the zoomed range from 3800 - 4200. Logged data are shown in 'G431-1pps.txt'.

[mino-fm]

A colleague did serveral ADEV-tests and sent me some diagrams. First shows dependencies for 1 s intervals.
Resolution will fit < 1E-10.
The second one shows a test with 0.1 s interval which resolution ist better then 1E-9. @ 10 s interval result is < 1E-12.
For comparison purposes an extra test of FA2 is inserted.

[mino-fm]

Based on G431 design, there is a new circuit using fast STM32H730 and TDC AS6501. Two input channels give up to 12 digits/s.

[Georgy.Moshkin]

mino-fm, I am trying to understand input stage. Assume input signal contains weak high frequency noise with superimposed with low frequency waveform. Low frequency waveform will be filtered out by capacitors C17,C18. Signal amplified with IC8A (74AUP1GU04), and then weak high frequency noise will be filtered by hysteresis of IC9A (74AUP1G14). What is the purpose of R18 = 1 MOhm?


Here is interesting paper related to frequency measurement: "Extending the Frequency Measurement of a Single Sinusoid Above the Nyquist Limit Based on Zero Crossings Method"
I think this is a viable approach, especially when combined with STM's upgraded HRTIM peripheral.

[mino-fm]

I think, you meant R26. It is necessary for IC8 to work as linear amplifier (gain about 30). Output of IC8 is biased at +3.3/2 V. That's a good value for max. sensitivity of IC9.

[tomeo.gonzales]

Can you make the firmware, Gerber files and BOM available for  the circuit based on STM32H730 and TDC AS6501?
Thank you

[erikka]

mino-fm, I'm trying to understand the linear regression part and I must be missing something as its not clear how this increases the accuracy.
Suppose without linear regression the reference is perfect accuracy at 100MHz, gate time is 1 second, input frequency is 100MHz. So 8 digits resolution.
Now 100 sub measurements are introduced and the results are input to the linear regression. This increase resolution with sqrt(100) equals 10 so one digit increase, but at the same time the resolution per measurement decreases with a 2 digits so in total you lose 1 digit. There must be an error in this line of reasoning, please help me to understand.

[Kleinstein]

One can see the linear regression as averaging over mutiple measurements, using more than just the first (start) and last(stop) slope.
A 2nd pair of points are the 1st and 2nd last slope to get a 2nd  reading from separate trigger events, but with a slightly shorter time frame.
So the advantag is not a full factor of square root N, but less (e.g. like sqrt(N / 5) if N > 6 or so, I don't remeber the exact theretical factor for pure trigger noise).
The linear regression helps with some noise (e.g. noise in the start / strop trigger), but not with others (frequency noise of the reference). So the actual gain via averaging depends on the signal. Depending on the signal, there may be a better way (e.g. more weight to the point at the ends) than the simple linear regression. There are cases where the regression does not help and even adds noise, and there are cases where the regression really helps. So Ideally one has the option to choose.

[magic]

Eh, maybe we should start with fundamentals

The theory of linear regression is that we consider a number of sub-measurements of the form (elapsed time, input clocks so far). If plotted, these would look like a sort of staircase pattern. Then, using basically black magic, we find a straight line which is closest to all the points of the staircase. The equivalent of using only one measurement would be drawing a straight line from the first to the last point. These lines may not be the same and their slope (frequency) may not be the same.

The theory is that the black magic line may in many cases be more accurate. It is not limited by the resolution with which we can measure the exact time between the first and the last input clock.

This is not the same as simply taking 100 partial measurements, calculating frequency from each of them and then averaging the results.

[iMo]

Some years back I built myself a reciprocal counter based on Bluepill (stm32f103), tdc7200 and a small fpga (ice40lp384).
The MCU asked the fpga via a CAPTURE rising edge to timestamp the Ref_10MHz and Signal.
There were 2 counters in the fpga - for Ref and for Sig.
The counters (both 32bit counters) were running freely.
Thus each MCU "request" generated two 32bit values. You can make many requests per second of course, as the capture takes a couple of Ref clocks.
I read out the two registers into the MCU.
Also during the capture the phase difference between the Ref and Sig rising edges was measured by the TDC7200 (55ps res with 30ps rms).
That gave me another 10-11bits.
The MCU then calculated the Sig frequency out of OLD and NEW capture data diff.
You can make any statistics with the data, of course, as the interval between OLD and NEW capture could be arbitrary long (as the both Ref and Sig counters are running freely) so you are not in hurry .
I build it on a solder-less breadboard as an experiment, the jitter of my measurements was rather high, about 200ps rms (it requires a different type of construction of course).

[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.

[Kleinstein]

The Linear regression type is good for phase noise - for white phase noise it should be the statistical best solution. However it is not that good for a more frequency type noise.

One gets phase noise from things like the quatization (limited clock frequency) and the trigger noise with a more rounded noisy signal.
One gets a more frequency type noise with many not so stable oscillators. In this case one still needs to define what frequency is considered the true value.

Ideally the linear regression can also give the residuals and thus a crude estimate for the phase noise. This can work at least for the cases with a not so good signal. With a stable signal it may just be the intrinsic quatization part. So the resolution for the phase noise may not be meaningful for a good signal. It still helps to know when the signal is not stable.

[tverbeure]

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.

I hadn’t heard about the histogram method. Does it work the same, by taking multiple samples within the same gate time, with an ever increasing number of reference clock cycles?

[Georgy.Moshkin]

not some special method, just taking each measurement and adding it to 1d array.  E.g. 3 element kernel array {1,2,1}. First measurement gave 33, second measurement 34. Array elements from 32 to 35 become {1,3,3,1}. Third time measured 34 again. Array elements from 32 to 35 {1,4,5,2}. Fourth time measured 38. Array elements from 32 to 39 {1,4,5,2,0,1,2,1} and so on. Then finding peak, in the above array peak is at element  34 (hist[34]=5) and it is not affected by noisy "38" value, even if it was "138". Sorry for such explanation.
My next attempt was to use sliding window of measurements. Oldest measurement substracted from histogram, newest was added. This required more memory, but provided more responsive readings. Actually, significantly less advanced what you guys doing here.
Next idea was to use larger histogram, and then use gaussian blur on this 1d line of pixels (to make non-zero derivatives for peak finding algorithm). During these experiments I thought on other problem and had an idea than input data for Kalman filter type models should be always filtered by using histograms. And one important advantage of histograms is absence of computations, only addition of kernel array to histogram array around certain element in a loop.

[tverbeure]

Ok, that makes sense. When the incoming signal or the reference clock isn't fully stable, it will return the most likely value. But it will never increase the precision.

[Georgy.Moshkin]

Ok, that makes sense. When the incoming signal or the reference clock isn't fully stable, it will return the most likely value. But it will never increase the precision.

Well noted! And it does not help with resolution as well. During the experiments, I found it very interesting that many image processing algorithms can be applied to the spectrum (as line of pixels) and spectrogram (as a 2d image). E.g., curve tracing with subpixel curve extraction (parabola interpolation) easily runs in Realtime on STM32F446 mcu written in plain C (each 1024 points with sampling frequency around 40kHz / or each 25ms)

I am very interested in this precision improvement topic but do not feel experienced enough. I hope more experienced people may comment on below hypothesis. A little off topic background information first: when I researched the topic of object movement prediction, majority of sources used Kalman filter approach. What always bugged me is this "optimal" word added everywhere. It was obvious to me, that it is far from optimal if there is a significant noise in measurements. Especially if noisy values were biased and added up in some weak ghost-type measurement. For frequency counters, "ghost" measurement can emerge from power source noises if poorly designed or there is some hardware malfunction.

And now the hypothesis itself.
As in Kalman filtering, even based on very well-made model formula, linear regression (using least squares), uses formulas where information about (x,y) coordinates is lost during computations. It is lost in the sense that you can't re-build original noisy data by using result of linear regression. I think that this may indicate that input data is not used in an optimal way. So maybe input data needs to be pre-processed to achieve best results, e.g. by building 2d histograms before running linear regression. First step: 2d histogram is built. Can we rebuild input data? Yes, each point on 2d histogram tells us how many times (x,y) value occurred in input data. To me this means, that information on datapoint positions was used wisely, and we can move forward (we extracted some data, which is not used optimally during raw least squares method). Only relative time of point occurrence is lost. Second step: linear regression on resulting data. I think it is obvious that we can make many synthetic examples with artificial noise worsen linear regression and Kalman filter results by a measurable amount. At the same time, result of linear regression on pre-processed data in many cases may remain unchanged. In my above example, fourth measurement represents 25% of input data, a huge amount. Notice how easily it was filtered out, and not computationally intensive (may require a lot of RAM though). To sum up, my hypothesis is that there can be simple pre-processing step, which generally improves precision of least squares regression. If it is a foolish idea, I would be happy to hear why.

[Kleinstein]

The optimal in methods for calculating values from a set of measurements usually means a method with the lowest sensitivity to noise. This comes from the statistics as the mathematical field dealing with such problems. Which method is optimal of cause depends on the type of noise or in the mathematical sense the statistical model. For the simple case of white (uncorrelated) phase noise the method with the linear regression is optimal in this sense and gives the lowest possible noise. This kind of carries over from the linear regrssion as the best method to calculate a slope.
By definition noise is unbiased and good calculation methods should not produce a bias when noise is added.

However when the type of noise changes (e.g. FM noise) than this can also change which method is best. In case of pure FM noise the mathematical best method is the simple reciprocal counter, looking only at the first and last time stamp.

A nice part in statistics is that one can often reduce the data quite a bit before doing the final math. So not having a way to calculate back the original data is no a bad thing. The point is to keep the important information and drop the irrelevant parts / noise. With a well defined statistical model this is often possible. For many problems this is the first step: find the relevant part (sufficient statistics) that has all the relevant information (within the model). The method to than calculate the result only has to look at these reduced data. In stimple cases the reduction can go that far that it is easy to than guess a good method (e.g. with the pure FM noise the only remaining data are the first and last point and the simple reciprocal counter thus the only sensible and thus best estimator).

A point that the math is not really solving is deciding which is  the right model or assumption for the noise. There are still methods to test if an assumed model is reasonable. So ideally one would also look at the noise and from these data decide if the noise is more white PM noise or contains more FM noise. One could see this as a more complex statistical model that allows for different noise parts. With such more complex models the mathematics is than often no longer able to find optimal solutions.