[FieldTrip] ft_definetrial setting trial onset at the end of triggers

[Schoffelen, J.M. (Jan Mathijs)]

Hi Benjy,

Thanks for your extensive report. It contained almost all information for the keen reader to work out the cause of the issue and to present a workaround. The only missing piece of information is the specifics of your acquisition system, but given your affiliation, and the fact that UPPT001’ seems to work as trigger channel, I guess that you are working with a CTF-system.

Here’s my diagnosis and verdict:

Your trigger channel signal’s morphology causes FieldTrip’s ft_read_event function - which is the low-level reading function that tries to make sense of a digital trigger channel, among others - to make suboptimal choices about the definition of an ‘event’. One of those choices pertains to whether an event should be defined based on an ‘upflank’ or a ‘downflank’ of the digital signal. In your case, while you expected the ‘upflank’, FieldTrip clearly decided to take the ‘downflank’. Something seems to be off with respect to the ‘baseline’ value of the trigger signal, judging from the last figure in your e-mail. I don’t know whether the offset is systematic across the whole recording, and to some extent it does not matter too much (because the data cannot be changed anymore), but clearly - in your case - the detection scheme for the default value of detectflank (which in your case should be ‘up’) did not work well. Explicitly specifying this in your case, as cfg.trialdef.detectflank = ‘up’ (I think, please check this in the documentation/code) should result in the large majority of events being correctly detected (apart from the ‘1’ events that start from above). It’s a bit speculative with respect to the cause of your issue, but if you wish to avoid this in future recordings I suggest that you check whether your trigger device allows for triggering in ‘level mode’ (in addition to the more commonly used ‘pulse mode’). If some of the bits of your trigger channel are in level mode (in your case, I suspect bit ‘4’ to be the rogue one), this could explain the morphology of the trigger signal.

The fact that the triggers precede the actual presentation on the screen results from the hardware setup and the exact way in which the experiment was programmed. If you want to align time point ‘0’ with the photodiode signal, I would actually start by using the photodiode signal to define events, rather than post hoc shifting the events detected from the trigger channel. You could consider writing your own trialfun to achieve this. To get some inspiration, please have a look at https://urldefense.com/v3/__https://www.fieldtriptoolbox.org/example/detect_the_muscle_activity_in_an_emg_channel_and_use_that_as_trial_definition/__;!!HJOPV4FYYWzcc1jazlU!9xkYjXPdrL-OhN4TCJi2x8wtiNFyH6niFHQJugQyRN8l07H2nruG-y_LcuK92MXJbAPg8J1HOU2G48TZ-Y0yRTH_zerbPKTi2GAKLA$  and perhaps also at fieldtrip/fileio/read_trigger.m

Good luck,

Jan-Mathijs

On 9 Mar 2023, at 14:46, Barnett, Benjy via fieldtrip <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>> wrote:

Hi Team,


I’m having an issue with defining my trials in what I think is a very simple set up. I have ten events in a trial. They are just stimulus on for 250ms, then off for 100ms - 10 times. The first stimulus in the sequence has a trigger value of 1, and the rest have a trigger value of 2. The trigger is on for the duration of the stimulus.

Here is my trial definition code:


        cfg                         = cfgS;
    cfg.dataset                 = dataSets{d};
    cfg.trialdef.eventtype      = 'UPPT001';
    cfg.trialdef.eventvalue     = 1; % stimulus 1
    cfg.trialdef.prestim        = 0.5;
    cfg.trialdef.poststim       =4;
    cfg.trialdef.nTrls          = nTrls; % number of trials per block
    cfg                         = ft_definetrial(cfg);

    % get it
    data                  = ft_preprocessing(cfg);

As you can see, I’m just using the generic trialfun_general function. However, for some reason the trials are being epoched according to the end of the first trigger, rather than the start.

Here is a plot of the issue: the blue line is the triggers over trials 2-35 in a block across time (all plotted on top one another). The purple lines are a photodiode signal that signals when the stimulus was actually presented to screen. The onset of each trial is for some reason aligned with the end of the trigger corresponding to the first stimulus. Can anyone suggest why this would be the case?

<image (2).png>

One theory I have is because, for some also unknown reason, in the first trial of the block, the trigger is now negative, rather than positive (image below). Still, here the trials are epoched to start with the ed of the first trigger. Could it also have something to do with the trigger being on at the start of this trial?

<image (3).png>

Finally, how can I go about aligning the triggers and the photodiode? I.e. so that the trial onset is aligned with the onset of the first photodiode signal, but also such that the triggers are shifted to align with the photodiode signal too. So that, in the end, I would end up with data that had the first stimulus’ onset at time point 0, and triggers that corresponded to the exact time the stimulus was shown, as measured by the photodiode.

I appreciate all your help and wisdom :)

Benjy
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!8tdkBFH3RXBUDUSZGgtQXwi21oFTjNu1w6bZkb9_uiXGsR3VMInu7fqUvxo-D4dJmO8Qmw0pHZKPVbuWtfjhNDXYVVRscUIj1KnSPQ$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20230310/b8d6b503/attachment-0001.htm>