Frequency Counter

[DaleC]

I'm building a solid state power amplifier for amateur radio. I need to get just the MHz that the amp will be fed (1.8 to 54MHz). I am using the stock FrequencyCount with a Teensy 4.1. It is accurate to 30MHZ and not any beyond that. I would think that with a 600MHz clock, the Teensy could handle that.

Am I right? Where do I need to look?

[defragster]

Seems like 30 MHz was the upper end of the limit observed in beta for 4.0 or 4.1.

@mjs513 might have feedback on that? He tested against a freq generator. Not sure if there is an alternate way to adjust the clock or a way to use an alternate clock input directly.

[mborgerson]

Could you just divide the input signal by two with an appropriate flip-flop or counter IC? You would lose some resolution, but you would not have to worry about messing with the software innards of the frequency counter library. I did a divide by 8 in a project some years ago and the counter chip also had the advantage of squaring up the input and adding some hysteresis.

[PaulStoffregen]

Have you tried shorter gate time?

[PaulS]

Since I'm interested in measuring MHz's as well, I tried example "Serial_Output_T4.ino".
The serial monitor shows a rock-solid "50000000".
Even when setting

  analogWriteFrequency(8, 75000000);   // very short jumper from pin 8 to pin 9

shows a stable "75000000".

But apparently I don't understand analogWriteFrequency very well: when I set the frequency to 60000000 or 62500000 or 65000000, it also outputs 75 MHz. Setting the frequency 55000000 outputs 50 MHz.
I read this page, but I'm missing something.

Paul

[DaleC]

Thanks for the info. It seems that I need to condition the input a bit before giving it to the Teensy. Currently, with a square wave, 5V on the high sice, -1 on the low side, it counts far closer. My goal is only to determine what frequency band I'm on. basically, 1.8 0 2.0MHz, 7.0 - 7.MHz ... I could happily count for a millisecond and get all I need, which would be far more ideal than counting for a full second.

However, it now looks like the problem is not in the code but in the conditioning of the signal.

I'm new to Arduino, have been programming C since 1985. What I now need to do is to grab those parts of the example which are a bare minimum for counting over a short period of time.

Piece of cake!

[PaulS]

However, it now looks like the problem is not in the code but in the conditioning of the signal.

Exactly, when I had a 75mm jumper cable between pin 8 & 9, it did not work well. So I had to bent a wire for the shortest distance possible.
Mind you, Teensy 4.x pins can only handle 3V3 maximum!

Paul

[RichardL]

Hi Dale,​
I'm using a T4.1 in a frequency meter application and with decent front end signal conditioning can achieve 70MHz. In my application I use a LTC6752 comparator that is good for 280 MHz; but take care if you try this, it can introduce multiple edges at low frequencies and the manufacturer recommends increasing the hysteresis. If you are using a T4.x make sure you limit the input signal to 3.3V max. I do this by running the LTC 6752 and a few other low power parts from the 3V3 output of the T4.1. Using 5V could be bad news!

I achieved a c.70MHz upper frequency limit with a T3.2; and had hoped the limit would increase with the faster T4.1. It didn't.

In the latest Beta install of TeensyDuino the FreqCount() examples appear to be missing; hopefully a new version is on the way.

The temperature coefficient of the T4.1 clock crystal is not that good and a compensation system is necessary to reduce this error and also the calibration error. I'm showing 21.00000 MHz +1 -0 for hours after calibrating with a 100mSec gate. This is not a problem if your objective is to find the current band you are amplifying, a 10uS period will provide sufficient resolution. (The original FreqCount() example would work down to a 1uSec gate period, a resolution of 1MHz... but it had other problems!.)


A colleague uses the T4.0 to measure the frequency of signals passing through his SWR bridge and apply appropriate band calibration. He experienced quite a lot of difficulties covering 1.8MHz to 432 MHz (using different sensor heads) but was successful in the end.


73
G8CDD