Reading in data from a new CTF system with ECC

Michael Wibral wibral at MPIH-FRANKFURT.MPG.DE
Wed Nov 29 22:22:41 CET 2006


thank you very much. The trialfun_general indeed does the job (at least
for my simple design).

Best Regards,

>Hi Michael
>On 29 Nov 2006, at 15:11, Michael Wibral wrote:
>> I'm trying to read in data from a CTF 275 channel system.
>> ...
>> When I use trialfun_ctf_continuous to read in the data no triggers are
>> found and as a consequence no trials are defined - I wonder whether
>> there is a problem with things like the 'STIM' channel and the
>> [backpanel, frontpanel] stuff as the machine doesn't seem to have any
>> back or frontpanel - but the ECC instead.
>I indeed think that the problem is that trialfun_ctf_continuous
>assumes back and frontpanel. The code in that trialfun predates the
>read_event code, and it is not maintained. You can use
>trialfun_general instead, or make your own trialfun. Read the help of
>definetrial to see what trialfun_general can do for you (not too
>much, but it might be enough).
>Alternatively, have a look at the bottom of the page
>to see a straightforward example trialfun. For that, you should also
>look into read_fcdc_event.
>We also use pseudocontinuous data at the Donders. Note that you have
>to do cfg.datatype='continuous' in preprocessing and artifact detection.
>> I have also tried to trial the data inside the CTF Software (using
>> newDs
>> with the corresponding markers) and then to use trialfun_ctf_epoched
>> with the same result.
>Also the trialfun_ctf_epoched is very old.
>> BESA reads the triggers however without problems, both, their values
>> (1,2,3...) and der names. so I think the data format shouldn't have
>> changed too much.
>No, the dataformat indeed did not change that much. It is also
>already implemented in the read_fcdc_event code, and the general
>trial function (or custom trial functions) can work with it.
>best regards,

More information about the fieldtrip mailing list