FreqMeasure.read() What would the reading be at 600 Hz?

Status
Not open for further replies.

Musicman

Member
Perhaps a dumb question;
I am using "FreqMeasure" to read an optical encodor. With a 600Hz square wave on pin3, using FreqMeasure.read() what is the number I should be seeing in the monitor?
 
Thank you for your reply;
I know that the clock cycles per signal period can be converted to Hz,
but I do wish to know the Raw Value of the unsigned long (32 bits) number of CPU clock cycles that elapsed during one cycle of the waveform seen in the monitor by using Serial.println(FreqMeasure); of a 600Hz signal befor it is converted to frequency, as I wish to map period size to a volume value.
 
Last edited:
but I do wish to know the Raw Value of the unsigned long (32 bits) number of CPU clock cycles that elapsed

Well then, just delete the code (from the example) which converts the raw cycle count into frequency. Easy peasy!

The cycle count is from the timer hardware, not the CPU, so expect the count to be in terms of F_BUS, not F_CPU.


during one cycle of the waveform seen in the monitor

Then also delete the example code which adds up 30 readings and compute the average.

If your frequency is only 600 Hz, this will cause 600 lines per second to be printed to the serial monitor. It can easily handle that speed. But do be aware if you try this with much higher frequencies, you could end up trying to print more text than the USB bandwidth (if using Teensy 3.x) or than your PC is able to process (if using Teensy 4.0). The example prints the average of every 30 so it won't overwhelm the serial monitor when people try it with frequencies like 50 kHz.
 
Thank you for your reply
I have used FreqMeasure.read(); for the period measurements , this produces results in the monitor at a very slow rate,Is this because of the way the monitor updates its display?
If I have also tried your sugestion of deleting the example code which adds up 30 readings and compute the average. What I see when monitoring FreqMeasure the frequency of the readings are updating to slowly to display all the variations in the speed of turning the encoder. Is this again the way the monitor updates its display?
Many thanks
 
Try printing an incrementing integer on each line. Then if you have any lines in a row with the same number, you'll have something visually distinct to watch as they scroll rapid.

Regarding your question about how the serial monitor updates its display, the visual results vary depending on your operating system. On each system, results can vary depending on what other programs are active on your machine and how much CPU time and memory they are using. Some Linux systems even limit the number of refreshes per second depending on whether the mouse is located within the window. There simply is not 1 single answer to this question, and at least on this thread I can't even see if you're using Macintosh, Linux or Windows.

An incrementing number on each line should make this clear to see.
 
Using FreqPeriod on the Arduino Uno my 600ppt encoder when read by FreqPeriod, gives 'wheelPeriod' range of values such as c. 6000 (4 revs/sec) to 50000 (1/2 rev/sec) .... 1 rev/sec = (1/600) *16us = 26666.66.
Should I expect the same values for the period measurements in the serial monitor using FreqMeasure.read() on the Teensy?
Thank you and a Happy new year.
 
I am serial monitoring FreqMeasure.read() , frequency and a mapped volume.

I am serial monitoring FreqMeasure.read() , frequency and a mapped volume.

In answer to my last posted question I can see that values in serial monitor for the period measurement at 600Hz are c 1/600) *16us = 26666.66 using the Arduino Uno, and c 79999 , i.e. 4x larger.

I am assuming this is because the timer clock on the Uno runs at 16MHz and the Teensy3 core has F_CPU set to 48MHz four times faster.
If so to use the settings for period size that I have successfully used on my Uno I simply have to divide my FreqMeasure results by 3?
 

Attachments

  • FreqMeasure.countToFrequency.ino
    525 bytes · Views: 51
Last edited:
Dividing my FreqMeasure results by 3 does produce the results I require

I am replying to my own question; dividing my FreqMeasure results by 3 does produce the results I require.
I have attached my latest sketch which I think is a bit messy, but produces the period measurement needed.
Could someone show me how to clean / simplify it ?

Many thanks
 

Attachments

  • FreqMeasure.countToFrequency.ino
    561 bytes · Views: 54
why divide by three?

Arduino Uno's timer runs at 16 MHz. Teensy 3.2's timer runs at 48 MHz. That's why the ratio is 3.

That is, if you're using the default setting in Tools > CPU Speed, which configures the CPU for 96 MHz. The timers run at the highest frequency which is an integer division of the CPU speed not more than 50 MHz (their maximum rated speed). So this ratio of 3 only applies if running at 96 MHz or 48 MHz. If you set Tools > CPU Speed to something else, the ratio would be different. If you use 72 MHz, then the timers would run at 36 MHz, so the ratio would be 2.25 in that case.

If you were to use Teensy 3.6, the default settings run the timer at 60 MHz, so the ratio would be 3.75.
 
I am assuming this is because the timer clock on the Uno runs at 16MHz and the Teensy3 core has F_CPU set to 48MHz four times faster.
just scanned this.... don't know why the arithmetic didn't jump out.

Edit.... was going to ask where F_BUS rates are listed but I get what Paul is saying now.
 
Last edited:
Status
Not open for further replies.
Back
Top