275ch CTF stimulus channel and new CTF data format

[Robert Oostenveld]

Hi Sanja,

On 26 May 2005, at 3:13, Sanja Kovacevic wrote:

> 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

This is something that was noted by Tom Holroyd as well. Furthermore, 
according to him the 275ch systems can have trigger channels that are 
not called 'STIM' (which is what our read_ctf_trigger assumes). The 
latest version of fieldtrip has an addition to read_fcdc_event, which 
automatically detects and reads all stimulus channels, does a flank 
detection and returns the value with no timeshift. The events will have 
the name 'STIM', 'UTGR001' etc. Thhe 'bakckpanel' and 'frontpanel' 
trigger with a 9 sample shift at 1200 Hz will remain to be supported 
for Donders people. I suggest that you have a look at the new code 
(which again only works sofar for the fcdc importer, but that should be 
easy to fix).

> 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...

The slow rising trigger value might be due to our presentation computer 
and not to the CTF hardware itself. I am not sure though, I just knows 
that it is a feature of our MEG setup.

> 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');

I just checked, dist turns out to be a function from the neural 
networks toolbox.
 >> which dist
/opt/matlab-7.0.1/toolbox/nnet/nnet/dist.m
There is no reason to use it, I will add my own implementation of dist 
which replaces the NN functionality. See attached file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dist.m
Type: application/octet-stream
Size: 609 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20050526/f7327316/attachment.obj>
-------------- next part --------------


> 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?)

I don't know actually. The header information from the nimh and the
fcdc res4 importers are structured differently. The read_fcdc_wrapper
around it does not shape all elements of the nimh hearer into the same
format, and in particular the grad information is not assigned. SO I
guess that "incorrect" only means incomplete.

> If I use
> ctf_read_res4 (ctf2matlab toolbox as mentioned by Tom Holroyd) I
> should be
> getting correct gradiometer information (right?).

yes, I have no reason to assume that it is not correct. It is just
shaped into a different structure. B.t.w. I recall that the ctf header
contains the informatino twice, once in dewar coordinates and once in
head coordinates.

>  It is still not clear to me what happens later with orientation
> information
> and what effect of using only first coil orientation would be...

MEG data is the magnetic flux through the coil. If the coil is oriented
in the opposite way but the field is the same, the flux is the
opposite. However, somewhere in the reading routine there is a flag
being used to indicate that the field has to be inverted, i.e. the MEG
data is always represented as outgoing flux. That means that the
forward computation also has to compute the outward flux for a given
coil, and that in turn means that teh coil has to be oriented outwards
(using the right hand rule)

> 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.

For sensor level analysis you do'nt have to worry about the gradiometer
orientations. If you compute virtual channels with SAM, you also don't
have to worry. If you want to use the fieldtrip beamformer, the
grad-structure should be correct.

Robert