measuring time between number of edges

[pax]

Hello,

 

we have a sensor that gives back pulses per meter on TTL-level. For measuring the distance we use counter0 on a pci-6229 device and calculate the distance every 100ms. So far so good. But calculating the speed within this cycle will give back an oscilating speed between certain discrete level because of the high resolution of time. Therefore we want to use the same signal as an input to analog ai3 (the other counter is used for some other purpose) and calculate the time between a fixed number of falling edges.

Here we have some problems detecting the edges. We compare with zero-level including some tolerance and get lots of TRUE-states instead of one because of beeing in a loop, detection itself works pretty good. So how can we just get one value per edge?

The other big problem is calculating the time. Tick count may work, but it is not very accurate and the structures to use it are a bit confusing. Timestamps may be another solution.

The Final structure should work like this:

Start counter for edges and time simultaniously, stop timer at edge number x, give back elapsed time, reset all counters and start over.

We are not very keen on LabView by now but very thankful for any kind of help.

 

Paul

[Alain_S]

You mean that you have speed oscillations because the number of pulses in successive 100ms intervals differ. Is that it?

Now you feed that pulse signal through an analog input, what's the scan rate used?

"Problems detecting the edges" Do you use one of the "Peak detection" vi's?

"Time problem"

Basically you expect only two voltages on your analog signal, 0 and 5V, right?

But because of resolution you get other values also 0.1, 4.9 and so on. So comparing with zero-level isn't good.

I would first clip the signal using the "Y[i]=Clip{X[i]}.vi" (what a name !!) between 1 and 4 so that all voltages lower than 1 will result in exact 1 and all above 4 will result in exact 4.

Now you can search for consecutive 1's and 4's. The number of samples between them multiplied by the scanrate will give you the exact time between pulses.

No need of "Tick Count" or other Timestamps since you know the scanrate

Hope this helped you further... ...

Message Edited by Alain S on 08-13-2009 05:18 PM

[Cory_K]

You should take a look at this palette:
Signal Processing >> Waveform Measurements

There's all types of nifty functions such as 'transistions measurements', 'pulse measurements', etc.

I'm sure you'll find what you are looking for.

[JÞB]

Pax-

You will also want to make sure that you are using hardware timing on the 6229 and not relying on the software timing.  Software timing is derived from the system clock which is not accurate.

[pax]

Thank you all, we will try to fix the problem today and think Alain's idea is very good. we already heard of problems with the system clock and it would be great if we can avoid it. so back to the lab

i hope i manage to reply the right way, its a bit confusing that you can just reply to certain entries and not the thread itself...