One way to measure the time delays is with software triggering. Use input sampling to monitor your stimulus waveform on one channel, and your response waveform on a second channel. Locate the arrival of the stimulus signal in your first input signal channel, typically using a LIMIT command to detect a level threshold. Then locate the arrival of the response signal in your second input channel, using another LIMIT command. Because these two LIMIT commands apply to adjacent channels with data flowing at the same rates, the timestamps they produce can be compared. Adjust the trigger HOLDOFF property to reject spurious events between test cycles, and adjust your hysteresis (dead band) on both LIMIT commands to avoid redundant bursts of triggers.

Arranged in this way, the first software TRIGGER element will observe the stimulus pulse, while the second TRIGGER element will observe the response pulse.

Now use two TSTAMP tasks, to convert the triggering event data into corresponding number values that you can access. Place these numbers into LONG pipes ptstim and ptresp that you define. Take pairwise differences between the numbers in these two pipes with a DAPL expression task, placing the results into the pipe ptdelay that you define. You can scale these results according to the real time interval between sampling instants, to receive your time delay results in physical time units.

To summarize, your DAPL configuration might look something like this:

  reset

  // Define the pipes and triggers 
  trigger  tstim mode=normal holdoff=250
  trigger  tresp mode=normal holdoff=250
  pipes    ptstim long, ptresp long, ptdelay float

  // Define sampling configuration and time scaling here...

  // Define detection thresholds here...
  constant   stimlevel word = 10000
  constant   resplevel word = 5000
  constant   stimreset word = 5000
  constant   respreset word = 2000

  pdefine  measure_delay
    // Detect stimulus pulse and response
    limit( IP0,  INSIDE,stimlevel,32767, tstim,  \
      INSIDE,stimreset,32767)
    limit( IP1,  INSIDE,resplevel,32767, tresp,  \
      INSIDE,respreset,32767)

    // Convert events to numerical form
    tstamp(tstim,ptstim)
    tstamp(tresp,ptresp)

    // Compute the delays and deliver results
    ptdelay = (ptresp-ptstim) * TIMESCALE
    merge(ptdelay,$BinOut)
  end
  

Strange results will occur if the sequence of stimulus-then-response is somehow disrupted — if a stimulus signal is just missed at process startup, if a response is too weak, or if there is an extraneous response due to some kind of temporary outside disturbance. Another approach to consider, for better process reliability, is to use the TOGGLE command instead of two independent LIMIT commands. The TOGGLE command enforces a strict alternating sequence between starting and stopping events.

There is a possible hazard that the computation of ptdelay in the configuration above will reach the saturation limits of the 32-bit timestamps if your experiment runs for several days continuously, producing a "glitch" response.