Using ESP32 and Neo-7N for precise frequency measurement

[edigi]

To get 8 digits/s your gated counter needs input frequencies >= 100 MHz. Any prescaler will reduce resolution obviously.

That's what I'd like measure anyway (prescaler is just to get the signal in the range that can be directly measured).

A reciprocal counter will give you 8 digits/s @ >= 1 kHz even if you are using your GHz 1000:1 prescaler.

I'm not planning to build a generic purpose frequency meter (thus not so much interest) but let's check a bit via an example to see if I understand correctly.
So let's drive the counter with a 10MHz signal (for simplicity the round value but it could be n*8MHz if this is what GPS receiver good at).  Let be the frequency to be measured not 1KHz (which is so easy), but 1234Hz.

So during a single period of the 1234Hz signal there will be 8103.72771475.. periods of the 10 MHz signal.
Obviously the counter won't count fractions, thus sometimes it will be 8103 but probably more frequently 8104.
That corresponds to 1234.11082315...Hz and 1233.95853899... Hz
So a single measurement won't get us to the desired precision. Multiple measurements are needed. The more digits, the more (or longer) measurements.

Here it matters a lot how you do it. You can't simply rely on the ISR getting to the same point of code within the same time after the ISR triggering signal appears on the particular pin (see my previous post) and phase can shift things to wrong direction.
If you do some noise (jitter like or worse some shifting) is added to your measurement that may or may not precisely average out.
The way of exact measurement however is not told/unknown to me.

You don't have anymore total control over the HW or the SW. There are OSs on these things, libraries for SPI, for I2C for OLED/LCD for you name it with its own advantages and disadvantages.

So it's pretty much clear to me that in case of low frequency signals it's not the number of cycles but the period is measured.
But to measure the period a different setup is required, with its own issues.

Now let's get to the practical part: I don't remember the last time when I needed to measure an 1 KHz signal (or 1234Hz signal) with 8 digit precision.
Even more I don't remember the last time when I needed to measure any signal with 8 digit precision below the quite typical 10 MHz.
So I have hobby projects where I do various things in my spare time (mostly tied to RF). No deadline, no boss but still I'd not like to spend all my spare time on it, especially things that I don't see some need for.

synchronising is done by hardware. Interrupts are NO problem!
I guess you are afraid of interrupts.

I'm not afraid of interrupts (I wrote several ISRs, although last time I've not only got my hands dirty with ky-40 rotary encoder to get it 100% right but also burned them as well as I had declare an ISR scoped static variable as volatile although the ISR had IRAM_ATTR...).

If HW can do the synchronization then probably it's good (although so far no-one told the exact solution, which I'm pretty much missing) but still this is not something I'd change platform if it can't be done on what's I'm using, simply I can live without precision measurement of low frequency signals.

Have I missed something?

[tggzzz]

Things have changed a lot since then and like it or not (it's still better to prepare for it) today even micro controller like thingies are multiple core (ESP32 is in fact dual core and this is what is/will be the trend) and have become so fast that caching is unavoidable.

Not true. There are 4000MIPS embedded processors with 32 cores and zero cache and zero interrups - precisely because those prevent hard realtime operation. (And you can transparently "daisy chain" processors to get higher throughput)

So maybe it's possible to get down interrupt precision to the level of few microseconds but definitely not to nanoseconds because of multi-core and cache misses etc. and gating precision has to be interface clock precision or more that is in case of a 80 MHz interface is in the ballpark of 10 nanoseconds or less (it never hurst to have more precision and 10ns for 8 digits in 1sec measurement sounds a good target to me).

I am using a processor with a 10ns interrupt latency, and a 4ns timing resolution for input and output. The IDE specifies the exact number of clock cycles between i/o and messaging operations. Yes, you can get absolutely predictable timing.

Yes, you can use software to count each and every transition in two independent 62.5Mb/s data streams, at the same time communicating over USB to a host processor and also dealing with front panel i/o. That is suffiicient for a software only reciprocal frequency counter with two 20MHz inputs.

FFI see the XMOS xCORE processors, and buy them from Digikey.
https://www.digikey.co.uk/en/supplier-centers/x/xmos
https://www.digikey.co.uk/en/pdf/x/xmos/xcore-architecture
https://www.xmos.com/download/private/XMOS-Programming-Guide-%28documentation%29%28F%29.pdf
https://www.digikey.co.uk/en/pdf/x/xmos/xtimecomposer-tools-overview

[tggzzz]

You can't simply rely on the ISR getting to the same point of code within the same time after the ISR triggering signal appears on the particular pin (see my previous post) and phase can shift things to wrong direction.
If you do some noise (jitter like or worse some shifting) is added to your measurement that may or may not precisely average out.
The way of exact measurement however is not told/unknown to me.

You don't have anymore total control over the HW or the SW. There are OSs on these things, libraries for SPI, for I2C for OLED/LCD for you name it with its own advantages and disadvantages.

None of that is true, provided you choose your processor carefully.

Have I missed something?

Yes you have missed something: XMOS processors and their software environment.

[tggzzz]

So it's pretty much clear to me that in case of low frequency signals it's not the number of cycles but the period is measured.
But to measure the period a different setup is required, with its own issues.

Are you aware of how modern reciprocal frequency counters and statistical frequency counters work?

[iMo]

I've been using an NEO-7M and an stm32 (with some additional circuitry and an OCXO) as a DYI counter.

NEO-7M:
1. 1PPS RMS jitter value as per spec is 65ns (in reality better, but it may depend an many factors)
2. NEO-7M can provide "any" ref freq at 1PPS pin - from 0.25Hz to 12MHz (you must configure the NEO-7M)
3. some output clocks (like the 10MHz) are "broken" (see the other threads with that topic), so I was using in my early experiments 12/8MHz as the REFclock for an reciprocal counter - with such an setup you may get 8 digits

Any chance you share more info about your counter? In case your design allows 10MHz OCXO/VTCXO, it basically is (supposedly) low cost GPS-disciplined 10MHz reference clock, good enough for most hobby labs and not only. Currently 10MHz GPSDO's on eBay are going for 160..200$.

The counter is a reciprocal counter. It runs two counters in an FPGA - one which counts the "signal freq" and the second one which counts the "reference freq". The reference is 10MHz (GPSDO).
Based on a request issued off the MCU anytime (ie. a rising edge) it makes a snapshot of both counters. That is how it timestamps the signal freq counter. Based on a difference "new-old" for both counters it can calculate the frequency. That is how the "reciprocal counters" work.

The advantage of the reciprocal counters is you may implement a measurement of the "phase difference" between signal and ref clocks edges thus you may increase the resolution (the "time iterator") significantly.

Imagine you want to measure a frequency with 1milliHertz resolution.

You have got three choices, imho:

1. to use a 1GHz ref clock with a standard clock gating approach
2. to use 1000secs gate time with a standard clock gating approach
3. to use a "time iterator" - analog or digital (ie. with 10MHz ref clock you can measure the 100ns ref period with 1ns "resolution").

[ogden]

Yes you have missed something: XMOS processors and their software environment.

Nah. FPGA or ASIC is right tool (kidding) As I said - 1$ STM32 is enough for freq counter having core freq (72 MHz) granularity and no dependence on interrupt timing. Capture interrupt I mentioned before is just obvious and convenient way to avoid brute polling, interrupt timing/jitter is irrelevant. Disclaimer: I do not talk to OP here.

[tggzzz]

Yes you have missed something: XMOS processors and their software environment.

Nah. FPGA or ASIC is right tool (kidding) As I said - 1$ STM32 is enough for freq counter having core freq (72 MHz) granularity and no dependence on interrupt timing. Capture interrupt I mentioned before is just obvious and convenient way to avoid brute polling, interrupt timing/jitter is irrelevant. Disclaimer: I do not talk to OP here.

FPGA will, of course, work.

The XMOS processors are nibbling into FPGA territory. They contain 4 to 32 cores running at 100MHz.

I haven't evaluated the stm32, so can't comment on that.

[ogden]

I haven't evaluated the stm32, so can't comment on that.

If you are into timing/frequency measurement or control - you shall (evaluate). - Because only peripheral on stm32 that can be considered as good is timer. [rant on] If you are into DSP - stay away from stm32 because you can't clock it's ADC/DAC directly from crystal oscillator. [rant off]

[tggzzz]

I haven't evaluated the stm32, so can't comment on that.

If you are into timing/frequency measurement or control - you shall (evaluate). - Because only peripheral on stm32 that can be considered as good is timer. [rant on] If you are into DSP - stay away from stm32 because you can't clock it's ADC/DAC directly from crystal oscillator. [rant off]

How fast a data stream can you capture? While also doing USB connection to a host PC?
Whats the time resolution with which you can  know when inputs occurred?
Ditto specify when an output will occur?
How many of those can you do simultaneously?
How accurately can the IDE toolchain specify the minimum/maximum time a code path will take - without measuring and hoping you capture those conditions?

I very much doubt it gets anywhere vaguely close to the xCORE processors!

As as example, the xCORE tools easily predict without executing that (on a first generation XS1 device) a "float" multiply takes 1.032us max (0.408us min), and a "double" multiply takes 2.632us max (0.560 min). Don't forget that's per core, and there can be many cores executing simultaneously!

[mark03]

If you are into timing/frequency measurement or control - you shall (evaluate). - Because only peripheral on stm32 that can be considered as good is timer. [rant on] If you are into DSP - stay away from stm32 because you can't clock it's ADC/DAC directly from crystal oscillator. [rant off]

That's funny, STM32L4 is my favorite for DSP projects.  I make good use of the built-in hardware CIC filter.  I do have a few quibbles on its implementation, but I don't know of any other CM4/7 MCU with a similar peripheral.

What's the motivation for direct clocking from XO?  Is jitter that much of an issue at these sample rates?  In a precision design I'd be using an external ADC anyway.

[ogden]

What's the motivation for direct clocking from XO?

PLLs of stm32 have inherent phase noise, but ADC clock phase noise creates ADC aperture jitter.

Is jitter that much of an issue at these sample rates?

Depends on what for you is issue. 300ps jitter (PLL spec of most most stm32's) means that 11-bit ENOB is not good anymore for input signals above ~200KHz (!) frequency. Most 1MSPS applications will be fine, but even stm32f1xx interleaved mode become kinda useless, not to mention 5MSPS ADCs' of higher-end chips and their interleaved modes.

https://www.maximintegrated.com/en/design/tools/calculators/general-engineering/jitter.cfm

[ogden]

Whats the time resolution with which you can  know when inputs occurred?

High resolution timer: 217ps

As stm32 have ARM core, you can get answers to other questions yourself.

I very much doubt it gets anywhere vaguely close to the xCORE processors!

So what? It does not automagically mean that at every timing application you shall throw xCORE! 

Please don't even try to start stm32 vs xCORE flames. It is obvious that xCORE is faster At least you said so. What about availability, chip & devtools  & debug interface price, learning curve, community support?

[mark03]

Is jitter that much of an issue at these sample rates?

Depends on what for you is issue. 300ps jitter (PLL spec of most most stm32's) means that 11-bit ENOB is not good anymore for input signals above ~200KHz (!) frequency. Most 1MSPS applications will be fine, but even stm32f1xx interleaved mode become kinda useless, not to mention 5MSPS ADCs' of higher-end chips and their interleaved modes.

https://www.maximintegrated.com/en/design/tools/calculators/general-engineering/jitter.cfm

Hmmm.  STM32L4 claims one order of magnitude better than that (about 30 ps).  Maybe the older lines are worse?  In any case, I've always thought the high sample rates were primarily there so you can throw away samples in exchange for more bits.  Hence the usefulness of the built-in CIC.  I guess there are applications where you can actually process 1 MSPS data directly, but they must be rather limited?

[tggzzz]

Whats the time resolution with which you can  know when inputs occurred?

High resolution timer: 217ps

I suspect that figure conceals important practical limitations.

Can you "schedule", say, 10 different outputs to change at 217ps intervals, or "measure" that 10 different inputs changed at 217ps intervals? For obvious reasons you can't have software involved in that, it has to be done by a separate hardware in each i/o pin/port.

The xCORE devices have such hardware, so you can schedule/measure any/all i/o at 4ns intervals.

As stm32 have ARM core, you can get answers to other questions yourself.

I very much doubt it gets anywhere vaguely close to the xCORE processors!

So what? It does not automagically mean that at every timing application you shall throw xCORE! 

Please don't invent strawman arguments.

Please don't even try to start stm32 vs xCORE flames. It is obvious that xCORE is faster At least you said so. What about availability, chip & devtools  & debug interface price, learning curve, community support?

The company, XMOS, has been shipping processors for at least 10 years, and continues to gather more investment from a wide range of well-known companies. It is based on sound software concepts from the 70s (now being incorporated into languages like Rust and Go), processors/languages from the 80s, and modern semiconductor capabilities. An excellent long-term pedigree.

Buy it at DigiKey, as per previous URL.

Dev tools are free, excellent, based on eclipse, and extend eclipse's standard functionality to exploit the hardware+software ecosystem's unique advantages.

I've seen many "new revolutionary" ics/software/etc over the decades; almost all fail to live up to expectations! I first used xCORE/xC to "kick the tyres" and see if it lived up to its promises - it did far exceeded my expectations. It was extraordinarily easy to get programs that just worked as expected. In particular the peripheral i/o is remarkably simple because the hardware and software are co-designed by people With A Clue.

As for an RTOS? Who needs one - those functions are done in hardware.

As for community support. Yes it exists - but I haven't needed to use it because I didn't encounter any unexpected behaviour! And that's remarkable.

Basically, it just worked as stated on the tin.

[iMo]

fyi: STM32F334 only - "high res timers" - 217ps resolution available for all operating modes, variable duty cycle, variable frequency, transition mode,…
Those high res timers are used for fine adjustments of pwm in critical applications. It does not relate to the "precise freq measurments"..
Otherwise the PLL's of all MCUs are a crap, so I would not use them for something called "precise frequency measurement".. 

[mino-fm]

fyi: STM32F334 only - "high res timers" - 217ps resolution available for all operating modes, variable duty cycle, variable frequency, transition mode,…
Those high res timers are used for fine adjustments of pwm in critical applications. It does not relate to the "precise freq measurments"..

This is right.

Otherwise the PLL's of all MCUs are a crap, so I would not use them for something called "precise frequency measurement".. 

That is wrong.
There is no problem using an internal 100 - 200 MHz reference clock (period 5 ns) with less than 1 ns jitter to get 8 digits/s.
STM32F407, ..411, ..427, ..429 work well and reliable.

[ogden]

Please don't invent strawman arguments.

LOL.

You sound like hobbyist running all your projects including LED blinker on highest performance embedded hardware you have in your bin, most likely never had to think about BOM cost optimization. I can assure you: xCORE wins stm32 in all the categories you listed - in case you for some strange reason think that this is contest between two. Yet I do not see why frequency meter builder shall move to xCORE. IMHO it's gigantic overkill to use multicore MCU aimed at hard realtime applications for such a simple task as counting pulses using two timers. I can repeat - few timers of stm32 is enough for the task.

[edit] Yes, I missed fact that hi res timers 217ps are output only resolution.

[tggzzz]

Please don't invent strawman arguments.

LOL.

You sound like hobbyist running all your projects including LED blinker on highest performance embedded hardware you have in your bin, most likely never had to think about BOM cost optimization. I can assure you: xCORE wins stm32 in all the categories you listed - in case you for some strange reason think that this is contest between two. Yet I do not see why frequency meter builder shall move to xCORE. IMHO it's gigantic overkill to use multicore MCU aimed at hard realtime applications for such a simple task as counting pulses using two timers. I can repeat - few timers of stm32 is enough for the task.

[edit] Yes, I missed fact that hi res timers 217ps are output only resolution.

Again you try to shift the argument away from your invalid, losing position.

It would help if you comprehended what I did write and didn't write.

And, again, don't fantasise what my position on subjects actually is!

Have a look at the strapline in the blog in my .Sig, viz "doing more with less"

[ogden]

Again you try to shift the argument away from your invalid, losing position.

Please explain. Am I losing to your stronger xCORE card or what?

It would help if you comprehended what I did write and didn't write.

What I did not comprehend? Explain! - Other readers of our conversation for sure would like to know.

[tggzzz]

Again you try to shift the argument away from your invalid, losing position.

Please explain. Am I losing to your stronger xCORE card or what?

It would help if you comprehended what I did write and didn't write.

What I did not comprehend? Explain! - Other readers of our conversation for sure would like to know.

See my previous messages. Read what they contain. Do not read what they don't contain.

[ogden]

See my previous messages. Read what they contain. Do not read what they don't contain.

You informed me well. When I will need hard realtime multicore MCU - I will look into xCORE. For simple tasks depending on various requirements I will use either msp430, AVR, stm32 or Zynq.

[edit] Don't worship chips. Actually don't worship anything. Get a life.

[ogden]

How fast a data stream can you capture? While also doing USB connection to a host PC?

How many opamps and comparators xCORE MCU's have?

[edit] If you think you found "THE microcontroller" - you are mistaken.

[tggzzz]

How fast a data stream can you capture? While also doing USB connection to a host PC?

How many opamps and comparators xCORE MCU's have?

[edit] If you think you found "THE microcontroller" - you are mistaken.

Yet more strawman points. (Or perhaps you can point to where I claimed the xCORE devices are "THE microcontroller" - or anything vaguely similar)

Please stop wasting our time.

[ogden]

How fast a data stream can you capture? While also doing USB connection to a host PC?

How many opamps and comparators xCORE MCU's have?

[edit] If you think you found "THE microcontroller" - you are mistaken.

Yet more strawman points. (Or perhaps you can point to where I claimed the xCORE devices are "THE microcontroller" - or anything vaguely similar)

Please stop wasting our time.

As you are not addressing my arguments, I do not want to waste my time addressing yours. Have a good time using just your affiliate chip.

perhaps you can point to where I claimed the xCORE devices are "THE microcontroller"

When you carefully re-read your posts - you will see. In case you do not see how "fan boy" you are about xCORE, then I will have no further comments

[edigi]

After some silence I've thought that I give some update about this project.

The ESP32 is suitable to create reciprocal frequency counter with exactly the 7-8 digit precision I was looking for.
For this one has to use one of the MCPWM capture feature + PCNT as counter.

The capturing is required so that:
- Gating for the counting can be made synchronous with the signal to be measured (so that one knows the amount of integer number of input signal cycles)
- The time between integer number of input signal cycles can be measured (in 12.5ns steps as capture counter is driven by a 80 MHz signal)

As the capture unit saves the actual value of the 12.5ns stepping capture counter in HW this is the resolution that can be achieved.
Thus for 7 digit resolution around 100ms measuring time is required and for 8 digits around 1 sec.  The precision is independent of the signal to be measured that can range roughly from 1/measuring time - 35 MHz (this was a bit higher with RMT gating).

As I have not figured out how to make a one shot capture triggering (if possible at all) very tight ISR timing is required so that the value captured by the HW is not overwritten by the next edge (next HW capturing). This seems to limit the upper frequency to 35 MHz down from the slightly higher theoretical limit (I'm actually even surprised that ~28.6ns is enough for the ISR to save the captured counter...). Also higher priority interrupts may interfere with this (not an issue for my hobby project, but for serious use it may be an issue).

Due to the capture functionality, measuring several cycles of the GPS 1pps signal could not be simpler. However I've also realized that GPS receiver is disturbed by the ESP32 RF noise, so that an active antenna that can be remotely placed is required (what I've received only recently).

So in short: While ESP32 may not be the best possible platform to make a precise reciprocal frequency counter, it's entirely possible with moderate cost.

More update later on, when I've explored this a bit more (and fully integrated the 1pps output of the GPS receiver).