#968

[@rfdave3980]

I remember punching in Hex code on a Intel 8085 and a Motorola 6800 micros class back in college. The good old days. Had so much fun in college.

[@SpinStar1956]

To avoid chaos, place the frequency counter code in an interrupt-handler, running say once per-second, or whatever responsiveness you want. That way, the frequency-counter's instruction stream will run as one (non-interruptible) block of code, to say, loading a set of memory locations with the result. This way, there will be no timing skew in the count. Some people argue that they UI should be put in the interrupt-routine but this 'will' give errors. Then when ever you want to update the display, just disable interrupts (to prevent a new sample) then retrieve the registers that were preloaded in the background, re-enable interrupts back again, and then do whatever display-math. 73...

[@jainmanish123]

It’s really nice to see the progress and the additional projects from the IC com receiver. I am learning something new from each video. As we are now trying to share ideas on the frequency counting, thought of sharing my opinion as well. Adding a ESP 32 with RTOS and a separate thread/core is all doable but I don’t think that is needed here, if there is no need for Wi-Fi communication I’ll pass ESP32. STM32-blue pill is a good choice and it can be overclocked as well and even without overclocking it can track/interrupt at 36MHZ in fast IO mode. I also believe this should also be possible with the Arduino 16 bit counter as well with the below scheme First pre-scaler for divide by 256 , same chip Use of a second Pre-scaler either same or any HC binary counter, with this we will be well in 16 bit count range for the complete 1 GHZ range and the counts can be gated (either SW or HW) at 1 sec / 100 mSec intervals to check the frequency The accuracy will then be dependent on the time base source and the loss of floating point number during divide by 256 and the Arduino can just fetch the count on a predefined interval.

[@byronwatkins2565]

If you need the precision and accuracy that you seem to imply, you need to replace the Arduino's resonator/crystal with a temperature controlled crystal oscillator. The hardware counter requires no execution cycles except to read it or to service its overflow interrupt.

[@EngineeringVignettes]

The third buffer circuit, for prescalar output, looks to be a good possibility. DC biasing would ensure that the counter input is normally logic-low. The prescalar then drives the transistor off to generate a rising edge pulse. Use of a thresold on the buffer seems to indicate that the prescalar has some analogue & amplification properties as well, it's not strictly digital. This type of buffer would rely on a good sink-current output on the prescalar (with help from that pulldown resistor), maybe another reason why it was designed that way? Cheers,

[@AllElectronicsChannel]

To get more resolution you can read the MSB of each cascaded counter in parallel using IO, adding then as MSBs of the internal software counter

[@andywlala]

How many digits of resolution (and accuracy) do you figure you will need ? Back of the envelope suggests that at %64, you will get ~2MHz output, and 1KHz channel spacing divides down to 15Hz post-prescaler. So 7 digits of resolution absolute minimum, more would be better - that might be kinda pushing things. While the Si5351 is a poor choice, as you've shown - what about parts like the ADF4351 (you have a board based on that, I believe) - that should have much better phase noise as the output is the PLL without a fractional divider, or how about a DDS (though ones that reach 140MHz tend to be harder to wrangle) ? I suspect that your avr loop time and resolution/accuracy (including CPU clock temp drift) will dominate your performance, but happy to be proved wrong, and anyway the journey is the thing, right ?

[@dri50]

I have been going down the same path trying to improve the accuracy of my existing frequency counter. I have already purchased a temperature controlled oscillator. But you still have the issue of getting it calibrated. So I'm currently researching using a GPS disciplined oscillator. That way there is no need to find a calibration standard.

[@PauloDutra]

If the counter uses one timer than the cpu exectution shouldn't be affected much, it will do work only when checking the counter value :)

[@rodriguezfranco3839]

I put that code in my arduino uno , and I been trying to measure a 555 timer , but it won't show anything it starts with 0 and then it shows the number 8 , code stats for arduino uno is analog pin 5 for the signal , did you add something to the code to make it work?

[@brianharper9798]

Don't you just love radio and electronics, you start off pulling an old radio apart and end up building a frequency counter. I must admit I generally end up going off on far worse tangents than that. Rather than two nanos maybe something like the STM32 (blue pill) would be better. Still usable within the Arduino ide and much faster.

[@RixtronixLAB]

Nice video clip, keep it up, thank you :)

[@ThinklikeTesla]

An RP2040 might work well for this. It has independent programmable IO cores that can count pulses at 100Mhz+ and other similar useful things without engagement from either of the main CPU cores.

[@rodriguezfranco3839]

I made it work , but I notice that it would only work if using i2c for the display cause most displays would use the pins that you need to input signal or that the code needs to use in order to work

[@chrisyoung3082]

Can you please post the parts list, circuit schematic, and code for that breadboard project please ... thanks !!!

[@IMSAIGuy]

I will be doing a proper project and will give out the code then

[@osmanov13]

Final part is here: kzbin.info/www/bejne/Z2WrpGiprah7jtk Please, add the link to the description of the video

[@jbrown468]

Very nice! Another option is to use an ESP32 and dedicate one core to the frequency counter. The FreeRTOS xTaskCreatePinnedToCore will let you do that.

[@IMSAIGuy]

That sounds like a nice solution. So much for me to learn

[@xhumari]

And ESP32 can count at 40 MHz (hardware counter based on 80 MHz clock) so you can get much better resolution. It can use the RMS device for precisely gating the counter, so you can count 40 MHz for 1 second at 1 HZ resolution. I saw a library for this: DavidAntliff - esp32-freqcount (oh, can't post a link I guess) (haven't tried, but I found the principle very interesting). Since this uses hardware peripherals, the core will remain mostly idle :)

[@jbrown468]

@@IMSAIGuy ME, TOO! :)

[@xhumari]

I found this so interesting that I spend this Saturday testing it. I manage to count rising and falling edges of a 17.3 MHz signal during 1 second, with resolution of 1 count. (Higher than that, readings were not stable.) The 17.3 MHz signal generated by my basic signal generator (a Uni-T UTG962E) measured beetween 17299732.5 Hz and 17299728.5 Hz during 20 minutes, with one measure per second. So that's 5 Hz drift in 20 minutes, and close readings were within 1 Hz. So ESP32's clock drifts a bit in time compared to my signal generator, but other than that, it looks stable. (I haven't tested for any drift linked to MCU's temperature). If a reference signal were available, the ESP32 would count both signals and apply a correction given the measured and known frequency of the reference signal. And of course the whole thing consumes virtually no CPU -- the counting is performed by PCNT device, the gating by RMT device, and an interrupt handler counts the overflows of the 16-bit counter. The graph of my measures is here: pbase.com/xhumari/image/172174767.original.jpg

[@Geek_Chef]

I believe a Teensy would work better in this case than the Nano.