275ch CTF stimulus channel and new CTF data format

[Sanja Kovacevic]

Hi Robert,

Your answer helped a lot but there was also another problem. My stimulus
channel “on” states were not 9, but 5 or 6  samples long. That's why I was
getting all zeros for both frontpanel and backpanel. I adjusted trigshift
(line 60) to 0  as the trigger values were either 0 or the predetermined on
values. For all of my datasets I've looked at so far, there is no rising
time for the stimulus channel. So, I guess this is another (nice) change in
the new CTF 275  acquisition program...

On another note, I ran some timefrequency analyses on the sensor level and I
wanted to plot the data using multiplotTFR. I'd like to use the information
from the header when plotting the sensors.  However, if I use the
gradiometer structure created with read_ctf_res4, i.e.  cfg.layout =
hdr.grad, I get an error message
??? Undefined command/function 'dist'.
Error in ==> createlayout at 93
    d = dist(prj');

You mentioned in one of your previous replies that sensor position and
information is not being read correctly for the new CTF 275 datasets. (BTW,
what tells you that read_fcdc_header does not read it correctly?) If I use
ctf_read_res4 (ctf2matlab toolbox as mentioned by Tom Holroyd) I should be
getting correct gradiometer information (right?).Well. I tried it both ways
and I get identical position information with read_ctf_res4 (fcdc) and
ctf_read_res4 (nimh). Orientation information differs in that that nimh code
stores only first coil orientation, whereas the fcdc code stores both coil
orientations. Both codes adjust for the possibility that sometimes coil
orientations stored in res4 file may be pointing toward center.

 It is still not clear to me what happens later with orientation information
and what effect of using only first coil orientation would be... What I
would ultimately like to do is to run time frequency analysis (on the sensor
level first, but also on the virtual sensor level) for each subject in the
group and be able to compare the results using some statistical approach.
However, first I need to establish whether the data is correctly read.

I appreciate your and any other fieldtriper help,

Sanja


On Fri, 6 May 2005 09:21:48 +0200, Robert Oostenveld
<r.oostenveld at FCDONDERS.RU.NL> wrote:

>Hi Sanja,
>
><--let's move our email exchange over towards the discussion list-->
>
>On 5 May 2005, at 22:50, Sanja Kovacevic wrote:
>
>> Thank you for helping me with this. I changed the filetype and
>> read_ctf_res.m files as you suggested, and I was able to read in the
>> data, however now I got problem with definetrial.m. Actually, I think
>> the problem is with read_ctf_trigger as the 275 CTF dataset does not
>> have a channel named 'STIM' but 'UPPT001' (line 63 in
>> read_ctf_trigger). That was easy to fix by replacing STIM with
>> UPPT001.
>>
>> However, I don't understand why you use (line 70 and 71 in
>> read_ctf_trigger.m)
>>
>> bpstim = fix(stim / 2^16);
>> fpstim = double(bitand(uint32(stim), 2^16-1));
>
>WHen I started at the donders and implemented this, I was told that our
>151 ch system has a "frontpanel" and a "backpanel". I never looked very
>acurately at the electronics cabinet and all the cables that go into
>it, but I guess that they refer to the way in which the cabinet is
>placed in our lab. Somehow, the CTF system's own triggers are put on
>the frontpanel, and the triggers that are generated on the stimulus PC
>are put on the backpanel. Since people write their stimulus programs on
>the presentations pc, and define/write trigger values in the 16
>bit-range on that computer. They appear in the higher 16 bits of the 32
>bit STIM channel, which is confusing since then the values don't match
>the ones on the presentation computer. Therefore the 16 lowest and 16
>highest bits are separated and treated separately. On line 70, the
>highest 16 bits are shifted downward by 16 bits (i.e. divide by 2^16).
>On line 71, the highest 16 bits are masked away, keeping only the
>lowest 16 bits.
>
>> The trigger values on our CTF system use lower 8 bits, i.e. possible
>> values of the triggers are from 0 to 255. I am now quite confused with
>> what happens to my trigger values. The bottom line is that I have all
>> zeroes for backpanel and frontpanel.
>
>I think that you should look at the so called "frontpanel" triggers
>(whose bits are not shifted).
>
>> BTW, could you give me or point to an example of a user specified
>> trialfun that would include trials where trigger with value of 10 ir
>> trigger with value of 138 occurs?
>
>You mean either a 10 or a 138? Just from my head:
>
>function [trl] = trigger138(cfg)
>hdr      = read_fcdc_header(cfg.dataset);
>event    = read_fcdc_event(cfg.dataset);
>trl      = [];
>prestim  = 0.1;
>poststim = 0.5;
>for i=1:length(event)
>   if strcmp(event(i).type, 'frontpannel trigger')
>     if (event(i).value==10) | (event(i).value==138)
>        % found trigger of interest
>        trl(end+1,1) = event(i).sample - prestim*hds.Fs;
>        trl(end  ,2) = event(i).sample + poststim*hds.Fs;
>        trl(end  ,3) =                 - prestim*hds.Fs;
>     end
>   end
>end
>
>You could put prestim and poststim (time in seconds) in the cfg
>structure, to keep the function more flexible. From this example, you
>caneasily  to make a conditional function, i.e. find the sample at
>which a trigger 138 occurred and which was preceded by a trigger 10.
>
>Alternatively, you can also use the standard code, i.e. without a
>custom trialfunction, to achieve the same. Try this:
>
>cfg = [];
>cfg.dataset = 'something.ds';
>cfg.trialdef.eventtype  = 'frontpannel trigger';
>cfg.trialdef.eventvalue = [10 138];
>cfg.trialdef.prestim    = 0.1;
>cfg.trialdef.poststim   = 0.5;
>cfg = definetrial(cfg);
>
>best regards,
>Robert