Calculation of RPM from an analog waveform signal

[jcannon]

Hi everyone,

I am attempting to measure an analogue waveform that is essentially a square-wave pulse from a position sensor on the flywheel of an exercise bike where I need to calculate flywheel RPM...

To do this, my logic tells me I need to:

1. Determine the time interval between adjacent rising edges (dt) by:
   • Finding the index of each rising edge.
   • Determine the difference between adjacent indices (x).
   • Calculate dt as: x/sample rate.
2. Calculate instaneous RPM as: RPM= 60/dt.

It has been a few years since I have used LabVIEW and I cannot for the life of me work out how to find the dt values!... I have tried the Basic Level Trigger.vi function and a host of other methods with no success...

I am working to a very tight deadline with this project... Any help would be greatly appreciated...

Thanks for your time.

Regards,

Jack

LabVIEW 2014

[Kevin_Price]

If you read data as a *waveform* type, the dt value is automatically included.  Have a look at the shipping examples for finite or continuous voltage input using regular DAQmx functions.   

-Kevin P

[jcannon]

Hi Kevin,

Many thanks for your response...

Sorry, on re-reading my post it was not clear... I can determine the time interval between samples based on the known sample rate (i.e. 1/sample rate).

I need to determine the time period between each adjacent pulse in the signal... So find the index or timestamp for each rising edge (N1), then calculate the difference between adjacent rising edges across pulses as: N1-N0... So something similar...

I just can't seem to work out for how to find the location of rising edges for each pulse in this continuous signal...

I hope this is clearer.

Thanks again.

[Kevin_Price]

What you wrote was plenty clear, I was careless in my reading.

I had some idle minutes tonight to whip up the following little subvi for you.  There's a hardcoded constant for the voltage threshold (1.5) that you might want to turn into a wire-able control to make this a bit more versatile.

-Kevin P

[Henrik_Volkers]

My first try would be something like this:

You should capture at least 5 to 10  periodes of your signal ... .. so you have to deal between update rate (number of samples)  and lowest detecable RPM ..  

EDIT: And for a cheap solution: try the soundcard input 😄 ... the typical 20Hz highpass should pass 5-10Hz signals ... but the tone detection migth snap to a harmonic and indicate 3 times the speed  😉