Problem FreqCount Lib No read after 12MHz

Status
Not open for further replies.
KE4EST

KE4EST

Member
Hello All first time poster.
I have searched and search so I apologize if this has been asked or explained before.
I am using the FreqCount library that Paul wrote on a teensy 3.5.
It works really great until after about 10 MHz. Then it starts losing accuracy and then after 12 MHz it starts showing a drop in frequency.
Hit somewhere around 16-17 MHz and it just shows 0. I am using the library and example just just as Paul has it.
I am also using the buffer circuit on the same page, only thing different is I am using a 2N2222, but am using a 74HC14.

Has anyone ran into this? Is my transistor too slow? Wanted to ask before I start changing out parts.
According to the description the teensy 3.0 and 3.1 show be able to go to 65MHz. Is there something different with the 3.5?
I need to at least be able to go to 40MHz for the time being, I could use a divider, but wanted to know what is going on?
Thanks
 
About a year ago I was experimenting with counting frequency using an Arduino and a Teensy LC. I did not keep great notes but I do recall that I was having problems counting as the frequency was increased. I was also using the buffer circuit similar to what you described. When I quit using the buffer, I was able to reliably count up to 16 MHz with the Teensy LC. The Arduino was only able to get 5 or 6 MHz.
 
Thanks for the reply! Funny how you just posted this and not only 10 minutes ago I bypassed the 74HC14 buffer. Still have the transistor circuit in place but now it is worse, it starts cutting out at around 5 MHz just like an Arduino uno. :(
I looked at the data sheet for a 2N2222 and it says it can switch up to 100MHz so I am still at a loss here as to what is going on.
 
OK, getting somewhere here! Using an Si5351 circuit and rotary in encoder on another board as a test I got it to read up to 65MHz.
I bypassed the circuit all together and fed the signal out of my test setup straight into the pin on the teensy, watching that voltage didn't go over 3.3V.
Trying other signal sources though it would not read. So an pre-amp still needs to be used, I just have to do some more experimenting.
 
I just did a test here too, got up to about 65 MHz. I made a video, it's uploading now....

Edit: here's the test I did.

 
Last edited:
Thank you very much Paul, for making the video and thoroughly checking this out!
The whole goal here is to make a full homebrew Frequency counter.
Now if I could just come up with a divider circuit that can handle at least 150MHz.
I tried the 74HC4017 and after around 50MHz I got erroneous readings, quick look at the data sheet and it said if I recall 49MHz max. Heck the teensy 3.5 can count higher.
I would like a counter that would be able to got up to at least the 2 meter ham band, but 440 would be nicer. :)
 
Thanks Paul. Looking at the data sheets, I really like the first one. I may just give that a try. :)
Was hoping for a DIP chip but I can make that work.
 
Paul I have another question. Could the library be optimized for the teensy 3.x boards that are a real 32-bit.
Or perhaps have a library just for 3.x boards. Just thinking out loud here.
The accuracy of the counter gets worse the higher in frequency you go, still pretty good for a home-brew counter mind you. :)
If I feed it a stable 60MHz signal for example it is reading about 66-68 Hz too low.
Is this a hardware limitation causing this, or could accuracy be improved using say double instead of float or uint64_t instead of uint32_t in the library ... or am I way off. :confused:
 
KE4EST said:
Could the library be optimized for the teensy 3.x boards that are a real 32-bit.
Click to expand...

It already is. 32 bit numbers are used, even on the 8 bit AVR chips.

Is this a hardware limitation causing this
Click to expand...

Good question. Honestly, Freescale's documentation on the LPTRM timer leaves quite a lot to be desired.

There's reason to believe it might be doing some sort of clock sync that loses accuracy above F_BUS/2 (which would be 30 MHz).

or could accuracy be improved using say double instead of float or uint64_t instead of uint32_t in the library
Click to expand...

The library uses uint32_t, which could count up to 4.29 GHz over a 1 second gate interval, so numerical precision just isn't an issue here.
 
PaulStoffregen said:
Good question. Honestly, Freescale's documentation on the LPTRM timer leaves quite a lot to be desired.

There's reason to believe it might be doing some sort of clock sync that loses accuracy above F_BUS/2 (which would be 30 MHz).
Click to expand...
That makes sense. I will just compensate in software.

PaulStoffregen said:
The library uses uint32_t, which could count up to 4.29 GHz over a 1 second gate interval, so numerical precision just isn't an issue here.
Click to expand...

Of course, I was just using that as an example, probably not the best. :) Yes, uint32_t is plenty. :)
 
KE4EST said:
I will just compensate in software.
Click to expand...

If it really is hardware sampling metastability, there probably isn't any reliable software compensation. The only solution would be keeping the input below 30 MHz (or half of whatever F_BUS speed you use).

Of course, that's based on a big "if". Freescale's documentation has conflicting and confusing info in this particular case.
 
Status
Not open for further replies.
Back
Top