Using ESP32 and Neo-7N for precise frequency measurement - Page 1
Forum section: electronics / projects

author: edigi
author_rank: Regular Contributor
timestamp: September 07, 2018, 12:36:54 pm
content: I've found some older topic where both ESP32 and Neo-7N was mentioned but scope was rather signal reference than measurement so I've decided to create this topic.After trying some cheap ready built OLED frequency meters from e-bay and from elsewhere (all were basically crap, not coming even close to a device using a half decent TCXO) I've decided to build one by myself.ESP32, which I was familiar from other projects, looked as a good candidate and also found some examples about the PCNT usage and using RMT for gating.I've had naturally some reservations about how good clock source ESP32 can have to use RMT for gating but nevertheless it was easy to check.(As prescaler currently I use Fujitsu mb506, the leftover of the OLED meter, but plan to extend the range with HMC434.)Result: ESP32 clock drifts something like 2ppm within 15 minutes from cold start in a stable temperature room.Certainly better than the OLED variant that I've bought, but still not good enough even for my hobbyist use, and although I'd like to build something cheap, I'm still willing to invest a bit more to make it better.So I've looked for a better gating source and found that Neo-7N gives out a high precision 1 sec period pulse signal by default. The pulse is 100ms and there is 900ms low value. To keep things simple I could directly use this with ESP32, use the 900ms low (negative) value as gate and process the measured counts in the remaining 100ms time.There is a big question though that I've found no answer so far and I have nothing to check this (not even the GPS module, let alone any capable measuring device). So I understand that the period of the pulse is high precision but how about the 100ms/900ms division or other words has the 90% duty cycle similar precision as the period?Has anyone experience with this or could check please?

author: edigi
author_rank: Regular Contributor
timestamp: September 10, 2018, 01:21:34 pm
content: I've tried to check an answer to my question in various threads in eevblog and what I've realized that quite many people are planning to build (or has already built) their own GPSDO (many of which is based on some Neo GPS variants).I don't know what are the precision expectations, but if one does not need very high precision that is the simplest case 0.01ppm (10 ppb) is sufficient or in a more demanding case 0.001ppm (1 ppb) a very simple setup can do it (so it makes me wonder why no-one has come up with the idea, or what are the pitfalls).So to ramp up some interest let's see the bill of materials:ESP32: ~7 USDNeo 7N: ~12 USD (you could use also the cheaper 7M)AD9834 DDS board: ~15 USD (in the more demanding case AD9910 but there is a diminishing return since AD9910 is not so cheap)So core material is in the magnitude of ~35USD in the simplest case+ probably some TFT display+rotary encoder etc. where you mileage may vary.So basically instead of building a tailored PLL with special loop filter simply measure the frequency of the output of the DDS using the GPS for gating and after some digital filtering (in simplest case some averaging of the successive frequency measurements) the ESP32 can easily adjust DDS as needed to compensate for the error of the DDS reference clock source (that can be done in case of AD9834 with 28 bits precision, for practical purposes actually one bit less/nyquist theorem).Since the ESP32 can measure up to 40MHz out of the box (there is only 15bit for counting, but on overflow an interrupt can be generated so counting can use as many bits as you wish) it's quite good match with the AD9834. Since prescalers (obviously) cannot increase the precision of the measurement, (gating) period must be extended to at least 3 sec for this use case even with AD9834 (ten times more with AD9910).This design has the advantage that you can set arbitrary frequency reference (hence the rotary encoder) as after all that's the purpose of DDS and can have e.g. both sine and square right out of the box (depending on the DDS with very little phase noise + various extras that's available in the DDS). The disadvantage that without the GPS assistance the built in XO is probably very far behind an OCXO and is even probably well behind a good TCXO (I have checked this with ADF4351 of which I have 2 different designs, even the better one is only 2ppm and the worse is something like 10ppm).However even with occasional (self) "calibration" with the GPS reference (so after all it's not necessary to connect the GPS all the time if less precision is OK, calibration offset can be saved to flash) the long term stability can be improved even probably beyond a good OCXO.So what do you think?Note: I used ADI products in my description (basically as example) as those are that I'm familiar with but this does not mean that you could not use many similar products as well (so as short disclaimer: I don't have any affiliation with ADI or any other vendor).

author: ArthurDent
author_rank: Super Contributor
timestamp: September 10, 2018, 09:56:27 pm
content: I see a lot of buzz words and part numbers being thrown around but I'm not sure I see any real application information to connect any of this stuff together to make a working system. I wish you luck.

author: hamster_nz
author_rank: Super Contributor
timestamp: September 10, 2018, 10:56:45 pm
content: I have a vaguely similar interest in making this sort of project (if only because i have most the parts lying around), and would be quite interested in playing along at home with your build.However, I wonder if people have a real use for a 10 ppb reference. I could see it being handy for checking calibration, but that is about it. Most of the world seems to be built on +/- 1% for most specs, and maybe +/-50ppm for frequency (about that of a cheap XTAL)What are you going to do for an antenna?Fun fact #1 - the clocks on-board the GPS Space Vehicles are not super-accurate in terms of absolute time keeping or frequency, but they are very predictable. Each Space Vehicle transmits the coefficients for a polynomial equation, that is used to map the on-board time to back to the GPS time standard, for the current few days.Fun fact #2 - GPS time also has been known to be break:http://insidegnss.com/news/gps-experiences-utc-timing-iif-satellite-launcher-problems/

author: DimitriP
author_rank: Super Contributor
timestamp: September 10, 2018, 11:49:04 pm
content: QuoteYou seem to describe something that resembles this:http://www.knology.net/~gmarcus/VFO/GPS_Sig_Gen_v1_1.pdf

author: iMo
author_rank: Super Contributor
timestamp: September 11, 2018, 10:11:12 am
content: 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 digitsCounter:1. I would not use 1PPS directly for "gating" the input frequency and counting the pulses (the traditional old school counter)even it is feasible with the 1sec 1PPS (mind the one-shot jitter there)2. Use an "reciprocal counter design" instead3. use the NEO for disciplining an OCXO and use the OCXO as the ref clock - the NEO's mid term stability is low (but better than a cheapo crystal), while the long term stability is high.PS: fyi - with NEO's 12MHz ref clock (at its 1PPS pin) I saw around 450ps rms jitter (with my 150ps rms resolution measurements) with an external antenna (the cheapo 28dB one) and 6-8 sats in green.

author: edigi
author_rank: Regular Contributor
timestamp: September 11, 2018, 01:35:45 pm
content: Quote from: hamster_nz on September 10, 2018, 10:56:45 pmAny RF engineer will frown on this who needs (at least occasionally calibrated) accurate reference? E.g. it's very typical to down mix. Also it's not uncommon (especially for hobbyist use) to down mix narrow band signals. From this on it's probably easy to figure. Sure for many digital stuff it does not matter.For trialing this kind of things either a good/affordable reference is required or measuring frequency with some precision. So maybe a 2ppm signal does not sound too bad. At 2.2GHz (lowest value of the VCO of the ADF4351) this is around 4 KHz. Once not so far in the past I had the idea of using the ADF4351 as signal source. There are several examples/cook books on the net about this. There are however some trade offs, as outside of the VCO range it outputs a divided down, thus square like signal. Also it cannot go below 34.375 MHz by its own.So let's mix (as with this a huge range can be covered). I've actually made this exercise. To throw in even more part numbers beyond the ADF4351 I've used a mini circuits SIM-73L+ (what I like/so great about this mixer that it can mix with such low level LO that the ADF's output can be directly used without anything like balun, amplifier etc.) + ADF4355 (apart from register structure it's very similar to ADF4351 so for trialing the same cookbook can be used).So let's down mix to e.g. 12 MHz. Oh wait, the 4 KHz drift is still there but it's not 2ppm anymore...You mean the GPS antenna I guess. Some cheapo stuff but may I could also build it from wires (basically nothing) if I'm really pushed.Quote from: ArthurDent on September 10, 2018, 09:56:27 pmConnecting the RF stuff I've used SMA male to male cables so far and for the digital part some Dupont wire. Really nothing else.True that I did not factor these in in the bill of materials as I have some of these lying around (although SMA stuff may actually be not so cheap). So connecting stuff together is mostly SW, not HW (where except for the averaging there are tons of SW examples on the net, e.g. for the ADF4351 I found at least 3, I've found DDS code as well for many DDSs), however I'd still like to avoid that due to limitation of the building components SW connecting cannot work even in theory, hence this thread.Note: I've started out this thread as precise frequency measurement but as you can see thing are interchangeable and so wondered to GPSDO now. One of them is needed but having one, the other can be created with relative ease.Quote from: DimitriP on September 10, 2018, 11:49:04 pmExactly. Apart from using the more powerful ESP32 that does not need the extra circuitry for dividing down the signal (so less components, really just wiring; and also conversion can be faster) it pretty much covers what I've tried to describe.As the AD9850 seems to have more bits so tuning can be more precise.So to me it's not obvious at first checking what does actually limit the precision only to 0.3Hz @ 10 MHz. Anyhow, it's pretty much in the expected range.So after all the idea existed quite some time already, just people are oriented towards the more specialized PLL+ special loop filter direction (that unfortunately cannot be built from off the shelf generic boards).Quote from: imo on September 11, 2018, 10:11:12 amBut it would not be one shot, several measurements averaged so jitter averaged out. Look the conversion figure and the description of the linked material.Well, it was a good discussion, thanks especially for DimitriP for the link.

author: ogden
author_rank: Super Contributor
timestamp: September 11, 2018, 06:48:14 pm
content: Quote from: imo on September 11, 2018, 10:11:12 amAny 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$.

author: mino-fm
author_rank: Regular Contributor
timestamp: September 12, 2018, 08:11:38 am
content: For precision frequency measurement you don't need a GPSDO. An 1 pps signal is sufficient for 7 – 8 digits/s.I can give you some (german) information about a counter, which has two input channels: one to measure input frequency and a second one for measurement of internal reference clock generated by crystal, TCXO or OCXO.A simple version uses ATmega162 which provides two input capture units. One channel offers 4 mHz – 50 MHz at 7 digits/s. The other one accepts 1 pps signal from a cheap GPS-module (EM-406A). Comparing (computing) the relation of input frequency and 1 pps pulse will give the true result:http://mino-elektronik.de/fmeter/fm_software.htm#bsp2Here you can find a picture (demonstration board):https://www.mikrocontroller.net/topic/241150#2467565The same GPS stabilising I use at other counters with STM32F407:http://mino-elektronik.de/FM_407/fmeter_407.htm.The last one of these counters offers up to 10 digits/s:http://mino-elektronik.de/FM_407/fmeter_407.htm#c3.Of course you can use a GPSDO but it is not mandatory.

author: ogden
author_rank: Super Contributor
timestamp: September 12, 2018, 08:35:00 am
content: Quote from: mino-fm on September 12, 2018, 08:11:38 amBesides frequency counter, there are other instruments that needs frequency reference like generators, spectrum analyzers and so on.

author: edigi
author_rank: Regular Contributor
timestamp: September 12, 2018, 01:58:25 pm
content: Quote from: mino-fm on September 12, 2018, 08:11:38 amYes, that was the idea in my first post. I have no doubt now that it can work and I can hardly wait the GPS module that I've bought to arrive.For the frequency measurement no DDS is needed but it's good to have some kind of prescaler (like MC12080 used in the linked description or the Fuji MB506 that I use) but those are so cheap (1 USD per part) that doesn't even worth mentioning.As no answer arrived at that point to my question I've started to look around and found that for what most people use the GPS module is to build a GPSDO but I started wondering why most people seem to use special PLL instead of the simpler DDS (ready made cheap boards available), since the DDS is more flexible that is if you need 10 MHz (that most measuring devices use) you can set that or if you need 25 MHz you can set that or basically any value (which can have also its own good use e.g. ADF4351 VCO can be stepped only with FREF/4096 step, however if one can change the FREF in very fine steps that limitation is also very easy to overcome...).

author: mino-fm
author_rank: Regular Contributor
timestamp: September 12, 2018, 03:24:17 pm
content: Quote from: edigi on September 12, 2018, 01:58:25 pmPlease tell us which resolution do you expect (digits/s) and about your desired input frequency range. You should use reciprocal counting in any way. Don't thing about gatetimes of 1 s or something like that.I don't know anything about ESP32 but if you are familiar with this chip, you should know more about its internal timers and capture units. This could solve your problem with little extra hardware like D-FF, inverter and GHz prescaler as desired.

author: ogden
author_rank: Super Contributor
timestamp: September 12, 2018, 07:03:24 pm
content: Quote from: edigi on September 12, 2018, 01:58:25 pmMost likely just because VCO approach of building GPSDO is more mature/popular and usually lower cost as well.QuoteDon't. Fractional-N or Integer-N synthesizer is worst thing you can use to build reference oscillator. Compare phase noise specs of ANY synthesizer to what you can get with DDS and you will see why.http://www.analog.com/en/analog-dialogue/articles/dds-vs-analog-pll.htmlBecause of the frequency division, C-DDS-based solutions have a clear advantage over analog PLL synthesizers in output phase-noise. The output phase noise of a C-DDS synthesizer is actually better than that of its reference clock source, while analog PLL-based synthesizers have the disadvantage of actually multiplying the phase noise present in their frequency reference.

author: edigi
author_rank: Regular Contributor
timestamp: September 13, 2018, 11:50:54 am
content: Quote from: mino-fm on September 12, 2018, 03:24:17 pmExpected digits are in the above mentioned 7-8 range, that translates to 10-100 million counts needed per measurement. As apart from references I'm mostly interested in the RF range so the 1s gating is more than perfect, but as all of this SW based, if my need changes I can easily adjust.ESP32 is nothing special, there are quite many different micro controllers that one can buy cheap (ATmega, STM32) but ESP32 is probably newer/more powerful and most devkits with WiFi and BT support (that I don't use in this case). It has 8 independent counting channels, that can be separately gated (from internal remote controller logic) or externally (pins as you wish, so it's just SW which is the gating and which is the counting input).There are several examples (just google github ESP32 frequency counter) but almost all, if not all are broken as the authors nicely forget about that the HW can automatically continue from upper limit after zeroing and generate an interrupt at the same time so count length as you wish, but it's easy to fix (also it can count on both edges so e.g. 25 MHz generates 50 million counts; tested with 25MHz TCXO. Note: multi channel high frequency measurement can have issues due to the massive amount of interrupts generated but I've never tried this as this is way beyond my needs).The logic interface is super fast, once I've tried it with a 100 MHz TCXO, it measured it as 20 MHz, if you're familiar with sampling you know why but my point is that it had no trouble with the 100 MHz signal...I also have a ready made 8GHz 1000:1 ratio prescaler (input side is either HMC434 or some PLL that has pins for both divider input and output; never bothered to check) but I don't particularly like these high ratio dividers as precision is lost unless one is willing to wait quite long for the measurement (so they are really good only for the high frequency side).

author: ogden
author_rank: Super Contributor
timestamp: September 13, 2018, 12:06:12 pm
content: Quote from: edigi on September 13, 2018, 11:50:54 amNot true. 32 bit counter overflows at 2^32 = 4.3billioncounts. This means that gating (timer capture) interrupts will be more frequent than timer overflow interrupts. If you are using 16 bit counter for frequency measurement application, you are simply not using right parts. Other possibility: you are building your frequency counter wrong way.

author: edigi
author_rank: Regular Contributor
timestamp: September 13, 2018, 12:34:29 pm
content: Quote from: ogden on September 13, 2018, 12:06:12 pmNope, gating is full HW without any interrupts, please try to read the specs before you make such bold statements and also there is no 32 bit counter either that you seem to miss also from my earlier post in this very topic (not to mention the spec again).

author: ogden
author_rank: Super Contributor
timestamp: September 13, 2018, 12:50:24 pm
content: Quote from: edigi on September 13, 2018, 12:34:29 pmOh myPlease try to read as well. I said "gating (timer capture) interrupts". Don't you seetimer capturementioned? For someone familiar with hardware timers it shall be obvious what actually I did mean.I meantimer capture and it's following interruptinitiated by gate timer (hardware) signal. Comprehendo?QuoteI love when people create unnecessary problems just to struggle solving them. Some form of EE masochism? Why don't you just pick MCU with 32bit timer?!

author: edigi
author_rank: Regular Contributor
timestamp: September 13, 2018, 01:25:20 pm
content: Let's cut this discussion short: I don't have any issue with the counting and it's precision (it's already 7-8 digits). The issue is that the gating signal currently from XCO does not have long term (due to e.g. aging) or even mid/short term stability (due to temperature change). Actually counting precision is so good that I can see even the sub KHz warm up drift of the signal in 2 GHz range. That is what the pps signal from GPS expected to solve as it has super long/mid term stability.

author: ogden
author_rank: Super Contributor
timestamp: September 13, 2018, 01:42:52 pm
content: Quote from: edigi on September 13, 2018, 01:25:20 pmYou have other option as well - use 8MHz (or other integer ratio to 48 MHz), reciprocally measure your reference oscillator against GPS freq. Such way you possibly can have faster lock times after power-on. While local oscillator is not locked, you can use GPS freq as reference frequency source.

author: edigi
author_rank: Regular Contributor
timestamp: September 13, 2018, 03:25:28 pm
content: Quote from: ogden on September 13, 2018, 01:42:52 pmOK, it can be done, not exactly the way as you've described (as internal XCO is not surprisingly also the measurement limit + I'd like to stick to ready made dev board, without extra discrete components, and also there is no easy access to the internal XCO signal in case of most boards as due to WiFi there is shielding) but I can measure in this way the gating precision and correct based on that, all SW again). A bit of flexibility gained probably but via some more complexity (not much by its own, but I have many other things to do as well). I'll decide when the GPS module arrives if it worth for my case the extra effort. I also would not like to loose the possibility of WiFi as it can have also its own advantages (like wireless logging, control etc).

author: ogden
author_rank: Super Contributor
timestamp: September 13, 2018, 05:06:50 pm
content: Quote from: edigi on September 13, 2018, 03:25:28 pmIndeed it can be done. At least on 1$ stm32. What I did tell you - was not questionAlso It can be done exactly the way I tell you. I am tired of challenges and don't want money of kids learning electronics, so you better just trust me.I am afraid that you do not receive what I am saying. - Most likely because englisch is not my native language.When I say "faster lock times" I actually mean "faster (DDS) frequency acquisition time to required precision". My suggestion does not require any access to XCO. Only additional circuit what's needed - signal wire that routes GPS module output clock to timer input clock pin.Disclaimer: I am stm32 guy, know nothing about esp32 timers and do not plan to learn them. Also I don't plan to analyze which of my suggestions can be implemented on esp32 or particular devboard you use. Just if it is possible with generic stm32 - I suppose it can be done and I shoot it out.

author: edigi
author_rank: Regular Contributor
timestamp: September 14, 2018, 09:11:13 am
content: Quote from: ogden on September 13, 2018, 05:06:50 pmIt seems that you're obsessed with the idea that the only good way how it can be done is how you do it (both HW and SW) where in reality many solution variants exists that are roughly similar and can produce exactly the same result.Let me reflect one thing that I did not want to reflect originally (and use it as an example). I use in my current solution zero number of timing interrupts because it's not needed, yet it can count with arbitrary precision (so precision is determined how long one is willing to wait for the counting. I'm willing to wait currently max 8 digits/magnitude of a second but if I wanted counting could be 15 digits precision also).The HW does the counting by itself including the HW gating control. If gating signal allows it starts/continues if does not allow it stops/suspends by its own. The gating signal is also HW generated. The SW determines how many interface cycles (ABP clock) the gating should be allowed and the HW plays that. Of course the gating cannot be more precise than the clock source of the controller since it's a divided down version of the controllers clock and that naturally drifts. This was the issue that I was seeking a solution not counting precision (as most people seem to believe).I'd not even trust any kind of timing interrupt precision here. Back early in my engineering carrier (decades ago) it was common practice to write codes for micro controllers in assembly (or check it in assembly) and count how many clocks cycles instructions use and if it can meet timing requirements.You had total control both the HW and the SW.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.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).It does not mean that one never needs interrupts related to gating. E.g. if the time difference between measurements is so low (sub millisecond; I'd be too lazy to do it for a generous 100ms) then one needs to assign an interrupt for the gating signals edge that ends the measurement to notify the SW to start as quickly as possible collecting the result and reset counters before the next measurement starts. Here again can be multiple good solutions how the SW part that does the real job is notified (since in ISR one cannot spend too much time).So all in all, please stop pushing your ideas. Although probably I did not get it totally (like it's visible I still don't see the need for gating timer interrupts) but I've seen enough of it that I can judge that I don't need it. Also I haven't faced any limitation that would force me to switch platform (in the middle of my hobby project for couple of bucks that I don't even need to spend since I have couple of spare controllers lying around , fracture of my budget for this hobby project). If I meet such limitation, I'll switch and I'm quite confident that as I could learn by myself ESP32, quite many various PLL/VCOs or DDS I'll be able to learn enough of any controller that I can use it for my needs.

author: ogden
author_rank: Super Contributor
timestamp: September 14, 2018, 09:41:38 am
content: Quote from: edigi on September 14, 2018, 09:11:13 amReally? Seems, your problems are far worse than you think mine are. You better stop your attitude and before you even consider to draw discussion into personal insults - read this book, from cover to cover:http://leapsecond.com/hpan/an200.pdfYou said "it can be done, not exactly the way as you've described. I corrected you "It can be done exactly the way I tell you". Please show me where I say "this is only good way how it can be done"?Indeed you can measure frequency and time many ways. And many are "good ways". Read the book and you will see.

author: ogden
author_rank: Super Contributor
timestamp: September 14, 2018, 09:58:36 am
content: Quote from: edigi on September 14, 2018, 09:11:13 amBrilliant. So you thinkyou own this threadand if my input is not important toyou- I shall stop writing here? Actually good idea. I will not waste my time for such an arrogant person. Bye. Have a nice design.

author: mino-fm
author_rank: Regular Contributor
timestamp: September 14, 2018, 10:48:22 am
content: Quote from: edigi on September 14, 2018, 09:11:13 amDon't be silly!To get 8 digits/s your gated counter needs input frequencies >= 100 MHz. Any prescaler will reduce resolution obviously.A reciprocal counter will give you 8 digits/s @ >= 1 kHz even if you are using your GHz 1000:1 prescaler. A reciprocal counter needs some SW calculation (especially 1/x) but counting and synchronising is done by hardware. Interrupts are NO problem!I guess you are afraid of interrupts.Your 15 digits precision looks very nice. Take your >= 100 Mhz signal and wait for 116 days for each result.Do what you like to do but don't be silly.

author: edigi
author_rank: Regular Contributor
timestamp: September 14, 2018, 03:06:24 pm
content: Quote from: mino-fm on September 14, 2018, 10:48:22 amThat'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 amI'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... HzSo 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 amI'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?

author: tggzzz
author_rank: Super Contributor
timestamp: September 14, 2018, 03:41:04 pm
content: Quote from: edigi on September 14, 2018, 09:11:13 amNot true. There are 4000MIPS embedded processors with 32 cores and zero cache and zero interrups - precisely because those prevent hard realtime operation. (And you cantransparently"daisy chain" processors to get higher throughput)QuoteI am using a processor with a 10ns interrupt latency, and a 4ns timing resolution for input and output. The IDE specifies theexactnumber of clock cycles between i/o and messaging operations. Yes, you can get absolutely predictable timing.Yes, you can usesoftwareto 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 asoftware onlyreciprocal 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/xmoshttps://www.digikey.co.uk/en/pdf/x/xmos/xcore-architecturehttps://www.xmos.com/download/private/XMOS-Programming-Guide-%28documentation%29%28F%29.pdfhttps://www.digikey.co.uk/en/pdf/x/xmos/xtimecomposer-tools-overview

author: tggzzz
author_rank: Super Contributor
timestamp: September 14, 2018, 03:45:41 pm
content: Quote from: edigi on September 14, 2018, 03:06:24 pmNoneof that is true, provided you choose your processor carefully.QuoteYes you have missed something: XMOS processors and their software environment.

author: tggzzz
author_rank: Super Contributor
timestamp: September 14, 2018, 03:47:58 pm
content: Quote from: edigi on September 14, 2018, 03:06:24 pmAre you aware of how modern reciprocal frequency counters and statistical frequency counters work?

author: iMo
author_rank: Super Contributor
timestamp: September 14, 2018, 05:58:32 pm
content: Quote from: ogden on September 11, 2018, 06:48:14 pmThe 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 approach2. to use 1000secs gate time with a standard clock gating approach3. to use a "time iterator" - analog or digital (ie. with 10MHz ref clock you can measure the 100ns ref period with 1ns "resolution").

author: ogden
author_rank: Super Contributor
timestamp: September 14, 2018, 06:01:17 pm
content: Quote from: tggzzz on September 14, 2018, 03:45:41 pmNah. 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.

author: tggzzz
author_rank: Super Contributor
timestamp: September 14, 2018, 07:27:20 pm
content: Quote from: ogden on September 14, 2018, 06:01:17 pmFPGA 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.

author: ogden
author_rank: Super Contributor
timestamp: September 14, 2018, 08:14:37 pm
content: Quote from: tggzzz on September 14, 2018, 07:27:20 pmIf 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]

author: tggzzz
author_rank: Super Contributor
timestamp: September 14, 2018, 09:32:51 pm
content: Quote from: ogden on September 14, 2018, 08:14:37 pmHow 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 predictwithout executingthat (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!

author: mark03
author_rank: Frequent Contributor
timestamp: September 15, 2018, 12:24:49 am
content: Quote from: ogden on September 14, 2018, 08:14:37 pmThat'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.

author: ogden
author_rank: Super Contributor
timestamp: September 15, 2018, 04:33:50 am
content: Quote from: mark03 on September 15, 2018, 12:24:49 amPLLs of stm32 have inherent phase noise, but ADC clock phase noise createsADC aperture jitter.QuoteDepends 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

author: ogden
author_rank: Super Contributor
timestamp: September 15, 2018, 04:51:55 am
content: Quote from: tggzzz on September 14, 2018, 09:32:51 pmHigh resolution timer: 217psAs stm32 have ARM core, you can get answers to other questions yourself.QuoteSo 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 fasterAt least you said so. What about availability, chip & devtools & debug interface price, learning curve, community support?

author: mark03
author_rank: Frequent Contributor
timestamp: September 15, 2018, 06:40:37 am
content: Quote from: ogden on September 15, 2018, 04:33:50 amHmmm. 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?

author: tggzzz
author_rank: Super Contributor
timestamp: September 15, 2018, 07:20:46 am
content: Quote from: ogden on September 15, 2018, 04:51:55 amI 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.QuotePlease don't invent strawman arguments.QuoteThe 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 didfarexceeded 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.

author: iMo
author_rank: Super Contributor
timestamp: September 15, 2018, 08:38:02 am
content: 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"..

author: mino-fm
author_rank: Regular Contributor
timestamp: September 15, 2018, 08:58:16 am
content: Quote from: imo on September 15, 2018, 08:38:02 amThis is right.QuoteThat 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.

author: ogden
author_rank: Super Contributor
timestamp: September 15, 2018, 04:53:20 pm
content: Quote from: tggzzz on September 15, 2018, 07:20:46 amLOL.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. Yes, I missed fact that hi res timers 217ps are output only resolution.

author: tggzzz
author_rank: Super Contributor
timestamp: September 15, 2018, 07:51:29 pm
content: Quote from: ogden on September 15, 2018, 04:53:20 pmAgain 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"

author: ogden
author_rank: Super Contributor
timestamp: September 15, 2018, 08:13:00 pm
content: Quote from: tggzzz on September 15, 2018, 07:51:29 pmPlease explain. Am I losing to your stronger xCORE card or what?QuoteWhat I did not comprehend? Explain! - Other readers of our conversation for sure would like to know.

author: tggzzz
author_rank: Super Contributor
timestamp: September 15, 2018, 08:24:32 pm
content: Quote from: ogden on September 15, 2018, 08:13:00 pmSee my previous messages. Read what they contain. Do not read what they don't contain.

author: ogden
author_rank: Super Contributor
timestamp: September 15, 2018, 08:31:18 pm
content: Quote from: tggzzz on September 15, 2018, 08:24:32 pmYou 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. Don't worship chips. Actually don't worship anything. Get a life.

author: ogden
author_rank: Super Contributor
timestamp: September 15, 2018, 08:58:08 pm
content: Quote from: tggzzz on September 14, 2018, 09:32:51 pmHow many opamps and comparators xCORE MCU's have? If you think you found "THE microcontroller" - you are mistaken.

author: tggzzz
author_rank: Super Contributor
timestamp: September 15, 2018, 09:37:31 pm
content: Quote from: ogden on September 15, 2018, 08:58:08 pmYet 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.

author: ogden
author_rank: Super Contributor
timestamp: September 15, 2018, 10:22:50 pm
content: Quote from: tggzzz on September 15, 2018, 09:37:31 pmAs 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.QuoteWhen 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

author: edigi
author_rank: Regular Contributor
timestamp: October 10, 2018, 11:06:03 am
content: 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).

author: edigi
author_rank: Regular Contributor
timestamp: November 09, 2018, 02:03:49 pm
content: Some more update with code, screenshots, bill of materials and future plans.So why Arduino and serial output for evaluation?Naturally I use OLED/TFT in my more complete setup/code but that requires the relevant library installed etc and that adds nothing just complexity for the purpose of evaluation. Arduino is really simple, it's easy to grab the serial output and I've installed it on Linux without any trouble and probably the same applies to Windows.50 GPS pulses (50s) are allowed between start/stop time stamping for reference compensation and as the counter is controlled by a 80 MHz signal thus it means 4 billion counts that just fits to 32 bits.If the clock source of ESP32 would be precise that translated exactly to 4 billion, if not then it can be used for compensation.Not directly but after filtering. A very simple filtering is used, maybe a more sophisticated FIR would be better (I don't know) but for a simple evaluation probably it should be OK.Filtered value is also saved to flash for convenience (as convergence of the compensating value is really slow) though I originally planned to omit it from the attached code as it's not strictly needed and also it's not necessarily the best example.Default measuring duration is set to 2.5 sec so it's not the limiting factor for 8 digits.So I've unpacked a brand new ESP32 eval board, connected it to the NEO-7N (on USB power using external antenna, both were good lessons but that's another story) and a Vanguard 0.1 ppm 25 MHz TCXO.Note: The frequency meter in this form requires CMOS compatible signal, so low value does not work and HIGHER VALUE THAN 3.3V ON ANY PIN WILL KILL THE ESP32 (a simple prescaler however makes it immediately usable for RF signals).I've made some screen shots about the convergence, using mainly the TCXO and also the 1pps signal that may sound odd but in reality not so.So the TCXO is around 1 Hz off (but that is still within spec) and the 1pps signal is mostly measured to be 1 Hz after the convergence but sometimes off with 1 in the least significant digit.What I did not like about the convergence that it's never completed (and mostly was far from that). I expected that there is a small variation at the end in the last digit of the 4 gig count, but it was more. Probably one factor is that the crystal driving ESP32 drifts a lot, but there can be many other factors as well like GPS sawtooth error, noise and jitter etc.So all in all a decent TCXO is needed for clock source of the ESP32 and after it's easier to figure out where else more improvement can be done.The need for improvement is pretty obvious after making counting duration longer and allowing for 9 digits.In the meantime however I've started to get interest for interpolating reciprocal counter. It's clear that I must raise the bar for the bill of materials so let's check the current state (obviously this is a hobby frequency meter so decent signal shaping in the front just like triggering is not much aimed and also it's not multi channel although platform has no limit for dual channel implementation and maybe even 4 is possible and also triggering is not so hard to add):12 USD NEO-7N6 USD ESP324 USD GPS antenna20 USD TCXO (for ESP32 not for testing; still in progress)10 USD Decent TFT (for the time being I use a smaller OLED for my more complete version)Thus altogether in the ballpark of 50 USD.New challenge for myself: doubling the budget (to the ballpark of 100 USD) for 2 more digits per sec thus in the magnitude of 10 digits/s.A quick search of how others did interpolating reciprocal counter I've found basically 2 methods:1) Charging a capacitor and making AD conversion for the fraction ("analogue interpolation"), like this:http://n1.taur.dk/permanent/frequencymeasurement.pdfI'm admittedly not keen going into analogue direction as it usually translates to more components that kills simplicity however if it can save FPGA...2) Phase shifting the signal via delay and using the phase shifted values to determine fractions like this:https://www.febo.com/pipermail/time-nuts/attachments/20071201/e7833af5/attachment.pdfor the more scientific version:http://www.wseas.us/e-library/transactions/circuits/2010/89-747.pdfAs I'm not really familiar with FPGAs (and here it's probably hard to avoid), this will require more time and more dedication from me especially that budget for FPGA part is 50 USD (I actually have a cheaper one but that may not suit for this project).Note: I don't really have a need for this precision, this is just for fun.So as usual, what do you think?A small UPDATE:I've forgot to mention that if one is willing to settle for a fixed frequency GPSDO like 10 MHz and ready to invest 20 USD more (the price of VC-TCXO + 3 resistors one is best to be a potentiometer for course adjustment) with minimal code extension for around 70 USD not only a 8 digit frequency meter is achievable but a 1 ppb (or better since measuring time can be longer here) reference as well.VC-TCXO is actually pretty obvious choice but I was too obsessed with flexibility of DDS (cheap ones won't do as their analogue comparator has way too much jitter and better ones like AD9954 with low comparator jitter are too expensive for used just purely for this...).So I've ordered some VC-TCXO for reference but as Xmas is approaching probably I won't receive it any time soon, so no quick update on this either... (I've also noticed that someone is selling cheap VC-TCXO on e-bay but with high shipping cost so only large quantities are economical so I've skipped that as I can't do much with large quantities of VC-TCXO...)