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

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