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.