Measure the times of the rising edges of a digital stream using a USB-6341

[WRB]

I have a USB-6341 DAQ card. 

I am using Measurement Studio (writing code in C#) on a Windows 7 machine. 

I am fairly new to programming DAQ cards, so I might be asking something that is obvious (sorry if this is the case).

I am outputting a stream of digital pulses to an Analog Output channel.  I have wired this channel to a counter input channel.  I am able to measure the number of rising edges seen at this counter input channel (since the digial stream is continuous, the number of rising edges increases with time). 

I would like a timestamp for each rising edge and I would like to keep these timestamps in an ever-growing array (or perhaps bin these time stamps into a histogram). 

Can I configure the counter channel to provide this timestamp data? (rather than just counting)

Thank you for your help/

[James-K]

WRB,

There is not any time information associated with a counter channel which makes it difficult to timestamp counter data.  One option is to specify an existing sample clock (AI or DI) to use as a sample clock for the counter (note that you will run into errors if the sample clock is faster than the rate of edges you are counting).  

Also, is there a reason you are outputting a digital signal using an analog out rather than one of the digital IO lines?

[WRB]

My reason for outputting a digital signal using an Analog Output is because I intend to play with a range of signals (sine wave etc.) to see their impact on trigger detection (I'll also be adding noise etc.) - the starting signal just happened to be digital.

So, if I just wanted time data on the rising edges of my digital stream, what is the best technique?  I was using a counter just so I could see a response to my digital stream.

Thank you

[Mcdan · Accepted solution]

WRB,

The counter should be able to measure the relative timing between various edges of your signal.  To do this, you will want to set the counter up to do period measurement.  This will measure how long a complete period of your signal takes.  You can configure which edge you would like to begin measurement with.  You'll want to set up your measurement to be 'implicit' timed.  This sets the counter up to automatically take a measurement each time a period completes.  While this is not exactly a timestamp, you can figure out the distance between two edges by summing up the time of the periods between the edges in question.

I can think of one other technique you can use.  That would be to set the counter up to count edges of one of your device's timebases (it has 100 KHz, 20 MHz and 100 MHz timebases).  You'd then configure the task to use your signal as a sample clock (configuring it to use rising edge).  Each time the appropriate edge happens, you'll get the total number of ticks of the selected timebase ticks that have occurred at that time.  One thing to note here though, is that the counters are 32 bits wide, so your code will need to handle roll-over of this count if you're using a fast timebase and running for long periods of time.

Hope that helps,

Dan

[WRB]

Dan,

Thank you for these two suggestions. 

I will try the implicit period measurement first. 

It looks like I will get pairs of values: the number of high ticks and the number of low ticks - this will be repeated continuously.  In my particular situation I will use a relatively slow timebase (100 kHz) - the period of the signal of interest is only 0.5 seconds - I want to see if this period varies (in the range 0.495 to 0.505 seconds).  I'll configure my high pulse width to be 0.01 seconds - the low will be 0.5 - 0.01 seconds.  Once I have it working, I'll generate some pulse trains that have jitter included.

Does this all sound reasonable to you?  Thanks again.

[Mcdan]

WRB,

I think that sounds reasonable.  One note on the counter input channel types, as they can be confusing.  There are several overlapping channel types that do very similar things.  If you're interested in my first proposed method above, the types of interest will be:

1) Period - This should give you a single value per period

2) Pulse Chan Ticks/Time/Freq - These methods return the pulse measurement in terms of (High Ticks, Low Ticks)/(High Time, Low Time)/(Frequency, Duty Cycle)

If you are only interested in times between edges of the same polarity (ie whole periods only), I think method 1 would be more straight forward.

Hope that helps,

Dan

[WRB]

Thank you!  I got your suggestion to work. 

Although it work, a few things are still mysterious to me.  (I am using Measurement Studio from C# - but I'm sure things are similar in other languages.)

After creating the Task, I call "CreatePeriodChannel" and specify "CIPeriodMeasurementMethod.LowFrequencyOneCounter" since my signal is low frequency - this part makes sense.  However:

• There are several other parameters - two in particular allow me to put upper and lower limits on the expected value - but if I set these parameters to 0.3 and 0.4 seconds it still works (the actual value is 0.5 seconds).  Not that this is necessarily bad -- it just doesn't behave as I would have guessed.

The other mystery to me is that when I call _readTask.Timing.ConfigureImplicit(SampleQuantityMode.ContinuousSamples, 1) the second argument is supposed to define the buffer size, but I can't see that it has any affect.  If I read in groups of three data values, setting the buffer to 1 does not cause me any problems.  Probably I don't understand how the buffer operates.

If you have time I would like to hear your thoughts on these mysteries.

[Mcdan]

To answer these questions:

The min/max attributes are used to pick a timebase for the counter, unless you explicitly set it.  Essentially DAQmx should pick the fastest timebase possible that will measure all periods in the range specified by min/max.  If you explicitly set CICtrTimebaseSrc, then DAQmx will respect this setting.  Generally you don't need to set this, unless you want the counter to use an external source for its timebase.

For the buffer size, things are a bit tricky.  There is a section in the DAQmx help which deals with this, titled "How is Buffer Size Determined".  I believe that 'Implicitly' timed tasks would fall under the category of 'No rate specified'.  In this case, DAQmx will default to a buffer size of 10,000 samples.  It will then take max(10000, 'number of samples per channel') which you specify as 1 in your call to ConfigureImplicit.  This should result in a buffer size of 10,000.  What does this mean for your application? Probably not much.  As the counter acquires period measurement, it transfers the data to a FIFO on the device.  From there the samples are sent over the bus to USB buffers on your computer.  At some point, DAQmx will transfer the sample from the USB buffers into its own buffer (which is the one that you were asking about).  The data will sit in this buffer until you call read.  If there are enough samples in the buffer to satisfy this request, DAQmx will return them to you.  If there are not yet enough samples in the buffer, read will wait for them to appear.  Once they do, DAQmx will return them to you.  Since you are running at a relatively low rate, 10,000 samples is a lot of buffer (5000 seconds worth of data).  This really shouldn't matter though, because 10,000 samples worth of memory (40,000 bytes for period measurement on an X Series device) shouldn't have much of an impact on your system.

If you want to play around with these settings, DAQmx should allow you to set each attribute separately.  In addition, DAQmx should allow you to read these values back.  When you read them back, DAQmx should give you a 'coerced' value, meaning the value it actually picked on your behalf.

Hope that helps,

Dan

[WRB]

Thank you once again.  The implicit approach is working and the parameters make sense. 

For interests sake I'll probably try your other solution - but this won't be for a while.