Timestamp for each TTL signal input

[limp]

Dear all,

I am trying to accomplish something similar as the OP.  

I have a device that outputs periodic TTL level pulse signals and I would like to be able to timestamp each falling and rising edge of these signals. That is, I want to take a timestamp each time the signal exceeds a certain trigger level (e.g. 2 V) and similarly each time the signal goes below the same trigger level. I consider that the smallest width a pulse could have is around 50 - 100 us (microseconds) and the largest around 10 ms. The resolution that I want to have is at least 1 us (the higher, the better) with ideally the same level of measurement precision.  

Considering the fact that the NI 6221 has a 32-bit 80 MHz timer, this gives me a resolution of around 12.5 ns, which is perfectly adequate. The final processing of my program will take place in Matlab, but I think that I can take the measurements from LabView and then put the data into Matlab for post processing. I don’t want to do any “real-time” processing, but only post-processing in Matlab after all the timestamps have been acquired.

Do you think that the Cascaded Counter Timestamp.vi ‏that John_P1 posted should do the work for me? Do I need to do any changes to that?

Many thanks,

Ioannis

[John_P1]

Not quite--a "sample clock" is only rising or falling edge, not both.

You need to configure a "semi-period" measurement in order to get the counter to latch samples on both rising and falling edges.  The latched time is always relative to the previous sample, so if you want a cumulative total you'll need to add up each sample (the plus side is you don't have to worry about a rollover).

Best Regards,

[limp]

Thank you very much John.

No, I don’t need a cumulative total, but I need to find the (timing) difference between each 2 pulse widths, each two consecutive rise edges and each two consecutive falling edges. So, If I have the (monotonically increasing) timestamps of each pulse edge, I can do that processing in Matlab which I am more familiar with.

So, I guess in my case I have to worry about a rollover.

Also, another thing that concerns me a bit is the resolution of the measurements. Will the DAQ device send a timing sample to LabView only at each pulse edge? If yes, I think I won’t have to worry about the limited bandwidth of USB2.

May thanks,

Ioannis

[John_P1]

The output of the DAQmx Read will be an array of times with the high and low times interleaved (see the M Series User Manual).  From this you should be able to calculate whatever timing measurements you are looking for.  You don't have to worry about rollovers since the counter is resetting on every edge (using the 80 MHz timebase it takes the 32-bit counter around 53.7 seconds to rollover, so as long as your pulse widths are less than this you will be fine).

The way this measurement works is that the counter increments based on a known internal timebase (80 MHz).  At the time of the rising/falling edge, the value of the count register is sampled into a buffer and the count register is reset back to 0.  So the resolution of the measurement is 12.5 ns (inverse of the timebase), but the data throughput is going to be dependent on your input signal (the count register is 32 bits so you end up with 4 bytes per sample).  50 us high and low times would result in a 20 kHz sample rate which is only 80 kB/s of throughput over the bus.

Best Regards,

[limp]

Dear John,

I took your advice and I configured a "semi-period" measurement based on the link you suggested.

I have tried to configure the vi so that I take 1000 (Semi period) time samples. I also configure that a semi-period may range from 12.5 ns to 200 ms. I think that in this setting the 80 MHz timebase is selected.

Now, when I run the program, I get the following error:

Error -200284 occurred at Meas Buffered Semi-Period-Continuous.vi

Possible reason(s):

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger,   make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo

Corresponding Value: Current Read Position

Property: Offset

Corresponding Value: 0

Task Name: _unnamedTask<1>

Can you guess what might get wrong?

I have attached the .vi.

Finally, something else that I notice is that even if I change the value on a label box in the front panel and press the “Enter text” icon, the old values re-appear when I re-open my .vi file. So if you open the .vi now, you won't see my settings, but some default ones.

Many thanks,

Ioannis

[John_P1]

The read call is timing out--if you're trying to read 1000 samples at once and your semi-periods are only 200 ms then this would take 200 seconds to complete the acquisition (but the read timeout on the example is set to 10 seconds).

If you reduce the number of samples to read per loop to 1, do you still get the timeout error?  If so, then your signal is probably not connected to the right terminal.

I can't view your VI by the way as I only have up to LV 2011 installed on this computer.

You can set the default values of your controls by using Edit>>Make Current Values Default, or on a per-control basis through the right-click menu of the specific control.

Best Regards,

[limp]

Thanks John,

Yes, I still get the same error even if I configure it for 1 sample.

I am starting to think that I have connected my signal to the wrong input! I have connected it to Counter 0 source.

Also, the semi period of the (TTL) signal should be around 50 ms.

Regards,

Ioannis

P.S. Thanks for the "Make Current Values Default" tip.

[John_P1]

Connect it to the gate instead of the source.

Best Regards,

[limp]

Thanks,

This definetely improved things as I can now see that some readings are getting acquired.

However, after about 50 sec the program stops and throws the same error again.

Shouldn't it stop after one sample got acquired (or at least at the 10-sec timeout period)?

Regards,

Ioannis

[John_P1]

Well each sample corresponds to an edge from your external signal.  If the external signal stops or isn't present, then you are no longer sampling any data.

The read call blocks until you have acquired the number of samples you have asked for or the timeout is reached.  If there is no data being generated and you are waiting for data in DAQmx Read, you'll get a timeout eventually.

Even though I linked you a shipping example, you generally don't want to call the read like for this very reason--it's undesirable to have your code stuck waiting for data to become available when it may or may not ever happen.  Here are some ideas on what you could do to deal with the timeout issue.

1.  If you're using a PCI/PCIe DAQ card, you can poll Available Samples per Channel to determine if there is data to read or not.  This isn't as useful on a USB or etherent device since the data will often remain buffered on the device until you try to read and isn't actually "available".  

2.  If you're using a PCI/PCIe DAQ card, you can use DAQmx Register Every N Samples Event to generate an event whenever your desired number of samples has become available.  This isn't as useful on a USB or etherent device since the data will often remain buffered on the device until you try to read and isn't actually "available".  

3.  You can read continuously in a loop but set the timeout to some reasoanble number and specifically handle the timeout case in your code.

4.  You can configure DAQmx Logging ("Log Only" mode) and avoid reading altogether if your end-goal is merely to have a file which contains all of the sampled data.

Best Regards,