Go Down

Topic: FreqPeriodDue LIB - more precise frequency measurement / Arduino DUE (Read 2420 times) previous topic - next topic


Apr 14, 2016, 03:50 am Last Edit: Apr 14, 2016, 03:56 am by DAN_X Reason: grammer issue

Experimenting just again with the measurement of period time of square wave signal with a constantly decreasing frequency.
Long measurement window times are not possible, because I need to see the change of the period time in the highest possible resolution.
Therefore fast measurement cycles are very important.

The range of frequency is between 5kHz and 230 kHz. This equals to a span in period time from 200 uS to 4.35 uS.
Should be no problem for the DUE.

The best measurement results I've observed by testing the FreqPeriodDue library.

It's capturing the period time values really fast and I'm writing them into a buffer array for later processing.
But the problem is, the high frequency measurements are far away from correct and in the lower frequencies it is not really better!

Code: [Select]

The error list:

real signal measured signal (Arduino-FreqPeriod-Due LIB)

230.000 Hz 248.520 Hz
220.000 Hz 237.288 Hz
210.000 Hz 227.027 Hz
100.000 Hz 103.703 Hz
 50.000 Hz 50.909 Hz

The problem seems to be the wrong interrupt concept of this library. Here in the forum "Magician" recognised already this interrupt issue.

Code: [Select]

 attachInterrupt(periodPin, FreqPulse, FALLING);

But what is the solution, how it can be fixed?

Would be so great having finally a reliable period measurement LIB for the DUE as well!



Hi there,

In a previous post I have announced a library for using the TC modules (Timer Modules) channels of DUE's Atmel ATSAM3X8E micro-controller. You have the announce in this post:


The name of the library is tc_lib, and is available at: https://github.com/antodom/tc_lib

The TC module channels available in the ATSAM3X8E working in capture mode can measure duty and period of digital signals directly on hardware. The capture objects available on tc_lib abstract the use of TC module channels in capture mode.

For doing what you want you should use capture objects, using them it is easy, just have a look to the example capture_test.ino which  comes with the library. The library does not use function attachInterrupt() to measure the frequencies, but the interrupts of TC modules when using them in capture mode, so I think you will be able to get to higher frequencies. Have a try, but I think you can get to measure 1 Mhz signals correctly.

Please, just let me know if you get to something using tc_lib :)
I hope it helps.


You do measure too much frequency, and I would expect jitter to be the reason (little disturbances resulting in FAILING interrupt although not the next wave high has been seen).

I had the same problem with infrared speed sensor giving too much jitter. From a colleague (a hardware guy) I learned that a Schmitt trigger would avoid the jitter. But I am more a software guy and did create a softawre solution to avoid jitter in my measurements. You can find the details in this posting(thread):

Since you measure frequencies up to 250KHz setting dt=3 should work for you. I don't have the hardware to generate clean frequencies like you seem to have. Please try and let us know whether measurements get better by software jitter suppression.



Hi Antodom, hi Hermann!

This sounds really promising, thank you very much.
I will make a full testing with a good signal generator + oszi and will post the results during the next days.

It's very important to determinate the period time (frequency) of each wave cycle in the time window (max. 2ms) of the measurement.



Hi Dan! Have you test the library? I read several posts from you. I'm doing a project similar than yours and I want to ask you if you could get more accurate values with this library.
It would be very useful for me :)


I wrote a library for AVR and Teensy3 which does this using timer capture.


It's designed to be extended to other chips by redefining macros for the various timers in FreqMeasureCapture.h.  So far, nobody has bothered to port it to Due.   I keep hoping someone might do it someday...


Hi there @abonellitoro,

In the following posts you have several tests underdone by @HermannSW (thansk HermannSW) to know the limits of tc_lib:

I think they can help you to have a better idea about tc_lib, they report measurements of signals with frequencies greater than 20Mhz.

I hope it helps.


Oh! @antodom , @Paul Stoffregen thanks to both of you. I will check everything and I'll tell you later how the project goes.

Go Up