Q10061 Measuring propagation delays with software triggering
I am investigating signal propagation in neurons, and I want to determine the distribution in time delays between applying a stimulus and observing a synaptic response. Is there a way to do this?
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.
L24076
The DAPL system commands described here are documented in the
DAPL 3000 Reference Manual.
There is also an online tutorial
about software triggering with several application examples.