CTF trigger time shift

[Moo-Marc]

Hello,

As the following FieldTrip behavior was copied into the Brainstorm code for reading CTF stim channels a long time ago, could I please ask for clarification on the origin of this shift?

fieldtrip/fileio/private/read_ctf_trigger.m

Line 45 in c607aec

% this is needed because it takes some time for the rising flank to get to the correct value

My initial guess was that it might be related to the roughly 4-sample "group shift" from the antialiasing filter on the analog channels, but since the Fieldtrip code refers to the back and front panels, I believe it may refer to the older electronics rack where these triggers were generated from individual analog inputs. I presume this fixed time delay was either described in a CTF manual, or at some point you carefully measured it? Did you find it applied equally to inputs from various sources? Did you ever test the parallel ports, or across different versions of the CTF electronics? I could possibly test this with our ECC, and eventually with the newer electronics which we're planning to get.

For reference: Brainstorm issue, Brainstorm forum.

Thanks for your help!
Marc

[robertoostenveld]

It is the shift to read out the correct value, the sample at which the value is assigned remains at the first  rising flank. It deals (or better: dealt) with the occasional staircasing that can be due to the bits of the parallel port switching on too slow (indeed multiple TTL level analog inputs). So it is not a feature of the CTF system, but rather a feature of the stimulus PC parallel port and the two not being synched with a strobe-bit.

We observed it around 2002 (or 2003 according to the copyright statement in the code) in our 600Hz and 1200Hz recordings, determined the time based on that, and the trigshift number stuck and never needed to be changed for us, as we always send triggers that are >10 ms long.

We did not test whether this applied to other sources, as we only had the one CTF151 system back then and one stimulus PC. We also did not explicitly establish whether other CTF sites needed it. Note that this is in 2003, before we even started sharing any of our code under the name "FieldTrip". The Donders-specific names backpanel and frontpanel also date back to then, due to the way the CTF151 electronics rack was placed and where we respectively connected the stimulus PC and the button boxes.

I just checked the very first trigger in our Subject01.ds, which was recorded around that time.

dat = ft_read_data('Subject01.ds', 'chanindx', 1, 'begsample', 1, 'endsample', 900) 
plot(dat, '.-')

and it does not show it. I don't recall details, but suspect that it only applied when we used the lower and higher bits together, so more likely to happen with a 255 value than with the low (integer) trigger values that we have in Subject01.

I don't see any reason (in the FT code and from memory) why it would still be needed for datasets from the new ECC which we got when we upgraded to the CTF275 system around 2008 or so. In read_trigger.m (which is actually the main function rather than the read_ctf_trigger) the trig shift is also by default 0. We don't use backpanel and frontpanel triggers any more, so the read_ctf_trigger code could in principle be deleted.

[Moo-Marc]

Thanks Robert! That's very clear and useful as usual. Cheers