Counter/Timer Waveform

Question

I would like to convert period measurements (RPM data) received from my counter/timer board into waveform data type so that I would be able to conduct frequency analysis on the data (e.g. FFT). Have tried with limited success interpolation & decimation techniques. Would be grateful for any suggestions.

Answer 1

Malfesto,
I had a look and can offer up a few comments:
1. I don't understand your comment about "truncation error" in the slow speed pulses case. Perhaps your are remarking about the "glitches" in the slow data embedded in the block diagram array? More on this a bit later...
2. At least at a quick glance, the interpolation seems a little funky. I didn't spend a ton of time wrapping my head around it so maybe it's actually ok, but I saw a finite difference that would act like a derivative of the period, and a scaling factor based on the average period -- things that make me go hmmmm.
Also, if you zoom on the graphs for the Slow Data, you can kinda see that the "Post Processing Graph" looks like a derivative of the "Pre Processing Graph". I suspect you need to rework your interpolation method.
3. When I did a similar project, I think I first converted all the periods to frequencies and also generated a "sample time" array that was the cumulative sum of the periods. (I toyed with tweaking the time array so that the timestamp would correspond to the midpoint of the interval that I had converted to a frequency. I don't recall now whether that tweak proved useful enough to bother with).
Once I had laid out arrays for frequencies and (unequally-spaced) sample times for those frequencies, I could generate an equally-spaced time array at a desired "virtual sampling rate" and interpolate to create new "virtual frequency" values. Since I was merely post-processing data, I think I also used the native LabVIEW array functions 'Threshold 1D Array' and 'Interpolate 1D Array' in the interpolation process.
Now, before going into an FFT you'll want to remove the huge DC offset. This may be as simple as subtracting the mean or median frequency from all entries if you are nominally at constant speed.
4. Your raw dataset for Slow Data has suspiciously periodic glitches in the periods. There is a very strong and dominating pattern that repeats every 16 intervals. Your typical period is registering about 10 million timebase cycles. However, in every set of 16 periods, you get one period around 27 million and another around 35 million.
I don't know how you gathered your "Slow Data" values, but there seems to be a systemic error in the measurement. That sort of one-sample discrepancy looks very suspicious. I'd urge you to determine the source of those glitches and try to eliminate them. They don't appear to be telling the truth about the motion you wish to characterize. The device you measure doesn't by chance start and stop or go back-and-forth during your measurement, does it?
Hope this helps.
-Kevin P.