Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 12 of 12

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

  1. #1
    Junior Member
    Join Date
    Dec 2019
    Posts
    10

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

    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?

  2. #2
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,326
    https://www.pjrc.com/teensy/td_libs_FreqMeasure.html

    The raw value is the number of cpu clock cycles per signal period that must be converted to Hz.

    FreqMeasure.countToFrequency(count);

  3. #3
    Junior Member
    Join Date
    Dec 2019
    Posts
    10
    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 by Musicman; 12-31-2019 at 04:34 PM.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,500
    Quote Originally Posted by Musicman View Post
    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.

  5. #5
    Junior Member
    Join Date
    Dec 2019
    Posts
    10
    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

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,500
    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.

  7. #7
    Junior Member
    Join Date
    Dec 2019
    Posts
    10
    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.

  8. #8
    Junior Member
    Join Date
    Dec 2019
    Posts
    10

    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?
    Attached Files Attached Files
    Last edited by Musicman; 01-01-2020 at 02:33 PM.

  9. #9
    Junior Member
    Join Date
    Dec 2019
    Posts
    10

    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
    Attached Files Attached Files

  10. #10
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,326
    Umm... if it's four times faster, why divide by three?

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,500
    Quote Originally Posted by oddson View Post
    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.

  12. #12
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,326
    Quote Originally Posted by Musicman View Post
    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 by oddson; 01-01-2020 at 04:24 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •