A problem with change detection on digital inputs and timing, with PCI-6259.

[Jane_neurophys]

Hello,

I am using an M Series board, PCI-6259, to detect changes in multiple digital input lines, store each change and also store a time stamp for each.  I am using a C program and DAQmx function calls.  I would like to use this to record the times of events associated with neurophysiological data.

I created 3 tasks.  The first one configures change detection for the digital input lines, and exports the signal that is generated upon each change, to RTSI2.  The second task uses counter 0 to create digital pulses at a frequency of 20 MHz, using  DAQmxCreateCOPulseChanFreq.

The third task uses counter 1 to count the edges that come from the pulses of counter 0, using DAQmxCreateCICountEdgesChan.  It uses the signal from RTSI2 as its sample clock, so that it records the number of edges so far from counter 0 each time there is a change detected on one of the digital i/o lines.

Here is part of the C code:

 DAQmxErrChk (DAQmxCreateTask("tasknumb1",&taskHandle));
 DAQmxErrChk (DAQmxCreateDIChan(taskHandle,"Dev2/port0","",DAQmx_Val_ChanForAllLines));
 DAQmxErrChk (DAQmxCfgChangeDetectionTiming

(taskHandle,"Dev2/port0","Dev2/port0",DAQmx_Val_FiniteSamps ,40));
 DAQmxErrChk (DAQmxExportSignal (taskHandle, DAQmx_Val_ChangeDetectionEvent ,  "RTSI2"));

 DAQmxErrChk (DAQmxCreateTask("tasknumb2",&taskHandle2));
 DAQmxErrChk (DAQmxCreateCOPulseChanFreq(taskHandle2,"Dev2/ctr0","",DAQmx_Val_Hz,DAQmx_Val_Low,0.0,20000000.00,0.5));
 DAQmxErrChk (DAQmxCfgImplicitTiming(taskHandle2,DAQmx_Val_ContSamps,5000));

 DAQmxErrChk (DAQmxCreateTask("tasknumb3",&taskHandle3));
 DAQmxErrChk (DAQmxCreateCICountEdgesChan

(taskHandle3,"Dev2/ctr1","",DAQmx_Val_Rising,0,DAQmx_Val_CountUp));
 DAQmxErrChk (DAQmxSetCICountEdgesTerm

(taskHandle3,"Dev2/ctr1","/dev2/Ctr0InternalOutput"));
 DAQmxErrChk (DAQmxCfgSampClkTiming

(taskHandle3,"RTSI2",50000.0,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,40));

I provided changing states to 2 of the digital inputs -- line 0 and line 3, using external signal generators.  Here, a 32-bit digital read of the change detection task buffer will result ina value of 1 if line 0 were in a high TTL state, and a value of 8 if line 3 were in a high state, and a value of 9 if lines 0 and 3 were both in a high state. 

I used a fairly slow input signal on the digital input lines -- a 250 Hz square wave, so there were 4 msec between rising edges, and it had a duty cycle of .25. (1 msec high, 3 msec low)

It seems to work fine to detect changes of state and timestamp them, provided the changes occur at different times on the 2 input lines.  However, as a test, I connected the same input signal to lines 0 and 3 (just using a BNC 'T' connection), and expected changes with both lines

going high and low simultaneously.  (That is, the task buffer would contain 0, 9, 0, 9, etc.) It does this, but fairly often it records a separate change of state for each line. (ie, values of 1 or 😎 However, the input on counter 1 only seems to get a single sample clock pulse in these instances, because it only stores a single value for its edge counting input.

Here is an example of some input data. First, a buffer of times, in seconds:

0.002935
0.003938

0.006933
0.007937
0.010932
0.011935
0.014930
0.015934
0.018929

0.019933
0.022928
...

0.031929
0.034924
0.035927
0.038922

And the corresponding events read from the change detection buffer:

       buffer[0] =   9
               [1] =   0
               [2] =   9
               [3] =   0
               [4] =   9
               [5] =   0
               [6] =   9
               [7] =   0
               [8] =   1
               [9] =   9
               [10] =   0
...

               [15] =   9
               [16] =   8
               [17] =   0
               [18] =   9

Data words [8] and [9] indicate that line 0 went high first, then line 3 did.  But the corresponding data words in the edge counting buffer do not indicate such separate edge changes. Data words [15] and [16] imply that line 0 went low first.  The extra data words in the change detection task cause the number of changes detected to not equal the number of timestamps.  So, it is not possible to match up the series of changes with the series of times.

We do have circumstances where we can get simultaneous changes of state on more than one digital input line, so I need to fix this. 

I can send the full C program, if you like.  Thanks for any help you can give.

Jane

[Brooks_C]

Hello Jane, 

From what you've detailed here it sounds like the change detection clock that you're exporting and importing on RTSI2 is either generating the 2 pulses fast enough that the counter input can't register both pulses or it is only sending a single pulse.  If you have an oscilloscope available I would recommend exporting this clock to a PFI line so that you can scope the trigger to see if both pulses are being generated or if only a single pulse is being generated. 

Also, rather than using the first counter to generate a 20 MHz clock you can just specify the 20MHz time base and the source for your count events task and achieve the same result (a 20 MHz count) with a single counter. Let me know what you find and then we can work on a solution for this issue. 

If this is a hardware limitation it may be difficult to determine exactly what order and when each change happens since all events are registered without regard for the specific line, but we'll see what we can do.  If you don't have an oscilloscope available let me know--I should be able to try this out sometime Monday. 

Cheers,

Message Edited by Brooks_C on 08-15-2008 05:05 PM

[Jane_neurophys]

Hello Brooks,

I exported the change detection clock to a PFI line and looked at it on a scope.  I can only see one pulse, and it is about 150 nano seconds wide.  (It looks the same as a signal that is created when I put a square wave into only 1 of the DI lines.)  The M series user manual says that the DAQ devices synchronize each DI input signal to the 80 MHz sample clock and sends it to the change detectors.  At 80 MHz, that is only 12.5 nanoseconds per clock cycle.  Maybe there were sometimes 2 pulses but they

overlapped.  I don't really know how the change detection sorts out the signals.  I mean, how does it actually process the

changes when the data are 9,0,9,0,9,0, etc, as in my example above?

For my  purposes, it would not matter if it stored simultaneous  changes of 2 DI lines as a single 32 bit word or as separate events that had slightly different time stamps.  That is , if the time stamps are even a few microseconds apart that would be

good enough.  But I need to have a timestamp for  each change that is reported, otherwise the data can't be used at all.

If there were a way of detecting changes by using a slower clock than the 80 MHz timebase, that might resolve this for me.

Thanks,

Jane