Electronics > Projects, Designs, and Technical Stuff
Using ESP32 and Neo-7N for precise frequency measurement
<< < (6/11) > >>
edigi:

--- Quote from: mino-fm on September 14, 2018, 10:48:22 am ---To get 8 digits/s your gated counter needs input frequencies >= 100 MHz. Any prescaler will reduce resolution obviously.

--- End quote ---

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


--- Quote from: mino-fm on September 14, 2018, 10:48:22 am ---A reciprocal counter will give you 8 digits/s @ >= 1 kHz even if you are using your GHz 1000:1 prescaler.

--- End quote ---

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.


--- Quote from: mino-fm on September 14, 2018, 10:48:22 am ---synchronising is done by hardware. Interrupts are NO problem!
I guess you are afraid of interrupts.

--- End quote ---

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:

--- Quote from: edigi on September 14, 2018, 09:11:13 am ---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.

--- End quote ---

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)


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

--- End quote ---

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:

--- Quote from: edigi on September 14, 2018, 03:06:24 pm ---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.

--- End quote ---

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


--- Quote ---Have I missed something?

--- End quote ---

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

--- Quote from: edigi on September 14, 2018, 03:06:24 pm ---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.

--- End quote ---

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

--- Quote from: ogden on September 11, 2018, 06:48:14 pm ---
--- Quote from: imo on September 11, 2018, 10:11:12 am ---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

--- End quote ---

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

--- End quote ---
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").
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod