Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 28 of 28

Thread: Teensy 4: Measuring multiple frequencies

  1. #26
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,039
    I put the 10 frequency code on github.

    https://github.com/PaulStoffregen/FreqCountMany

  2. #27
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,039
    Normally FreqMeasure isn't recommended for higher frequencies, mainly because the resolution diminishes as shorter periods are measured. But joepasquariello found some really impressive ways to work around the resolution limitations!

    The other issue is the CPU overhead of interrupts. Since FreqMeasure needs an interrupt for each waveform cycle, the CPU usage scales up linearly as the frequency increases, and of course the CPU usage is multiplied by the number of waveforms you try to measure.

    The measurement's sensitivity to interrupt latency caused by other libraries, USB communication, and general timer usage can also matter. In that regard, FreqMeasure is excellent.

    FreqCount also has limitations, mainly that measuring small changes in frequency requires long gate intervals (or the sum of many shorter ones). But the interrupt overhead of FreqCount is fixed, one interrupt per gate interval, and with .FreqCountMany a single interrupt captures all 10. The effect of latency is that the interval may end slightly later, so you might get a gate interval which is 1000.01 us followed by 999.99 us on the next interval. You'll still get the correct total number of counts, but the frequency might appear to be slightly higher in the interval which was lengthened and slightly lower in the following interval.

    FreqMeasure is very insensitive to interrupt latency, at least until it become so bad that it approaches 1 period of the measured waveform. As long as the interrupt response isn't so delayed that a measurement is missed, the actual measured value is based on hardware capture of the hardware timer, so you get a "perfect" result which isn't altered by the interrupt latency.

    The number of timer bits, either native to the timer, or extended by software trickery with the timer overflow, plays a factor with both. On FreqMeasure, more bits means a longer period can be measured. On FreqCount, more bits allows a longer gate interval. But gate interval can be effectively lengthened by summing many smaller intervals, which is what the FreqCountMany code does.

    Not sure if this really answered your question about the possible benefits of using the 32 bit GPT timers...

  3. #28
    Junior Member
    Join Date
    Oct 2018
    Posts
    1
    Hi Paul.
    Thank you very much for such such an improvement in the many frequency reading with Teensy 4.0/4.1. I am working on a multy channel frequency reading device. The higher frequency reading is equally important as the number of channels for my device. I can decrease the number of channel to be able to read maximum frequency that Teensy 4.0 provide me. I am not so much expert on timer & clock issue. I tried to follow your response about 150 MHz question.
    Do you mean that I can reach maximum frequency 150 MHz by decreasing the number of channels to 4 to reach 600 MHz.
    Another question is maybe foolish but can I read 433 MHz with Teensy 4.0?
    Or what is your suggestion about it?

Posting Permissions

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