FreqMeasureMulti on Teensy 3.6 : precision over a few minutes?

Status
Not open for further replies.

hobi

Member
Good Morning,

I would like to use a Teensy 3.2 or 3.6 to perform timings measurement of 3 digital signals.
Those signals are expected to be digital pulses with a frequency of 1.5Khz up to 6Khz, and I need to record the rising edges timing of those 3 signals during a few minutes.
Ideally, each time a rising edge is present on one of the 3 inputs, i would get an absolute time that would be sent over the serial port / USB.
As I understand, the FreqMeasure is not doing that exactly, as we get as information a time elapsed since last rising edge occurs. Is this correct?

If we accumulate those time elapsed over a 5 minutes period, are we going to accumulate a large error, or the elapsed timings returned by FreqMeasure Multi will be accurate down to a clock cycle?

I basically use the Teensy as a 3 way logic analyser over 5 minute...

Thanks for your help.
 
Hi Paul,
Thank you for giving me a so fast answer.
IJust to be clear, this would mean that I will get a time measure accurate @ 1clk cycle at 60Mhz... which is really more precision than what I need!

Greeting from NXP France ;-)
 
I understand your request was for an absolute time, or "time stamp" for each rising edge. What I read about that library https://github.com/PaulStoffregen/FreqMeasureMulti is that you get the count of (60 MHz) F_BUS clock ticks between two successive rising edges of your input signal. For example with 5 kHz input, you would get a string of numbers close to 12000 because there are that many 16.67 nsec clock periods in one 200 usec signal period. If you don't miss any edges, then you can add each interval together to get a total elapsed time stamp relative to the first edge, but that part is up to you and not internal to the library.
 
Yep this is indeed what I understood! Thanks for the confirmation. I can also undeclock the cpu... not sure though that this will lower the 60mhz clock...
 
Scanning the FreqMeasure notes - it suggests it is good for nearer 1 KHz signals - there is a bit of _isr code behind it - and setting up three pins at 6 KHz - YMMV - and especially if not running at Full or OC speed.
FreqCount vs FreqMeasure
FreqCount: best for 1 kHz to 8 MHz (up to 65 MHz with Teensy 3.0 & 3.1)
FreqMeasure: best for 0.1 Hz to 1 kHz

The Multi aspect adds overhead checking which pin - that text may have been for T_3.2 or prior. T_3.6 at speed can handle more interrupts/sec for sure. But three overlapping pins might show odd results … so YMMV but slower clock will stay in _isr longer.
 
Scanning the FreqMeasure notes - it suggests it is good for nearer 1 KHz signals - there is a bit of _isr code behind it - and setting up three pins at 6 KHz - YMMV - and especially if not running at Full or OC speed.


The Multi aspect adds overhead checking which pin - that text may have been for T_3.2 or prior. T_3.6 at speed can handle more interrupts/sec for sure. But three overlapping pins might show odd results … so YMMV but slower clock will stay in _isr longer.

Ok, seems indeed that some checks are needed. I will test with 3 async clocks, and will check for errors. Underclocking may not be the best thing. Let's see and thanks for the warning.
 
Status
Not open for further replies.
Back
Top