Cut fNIRS data gaps within a long recording section for GLM analysis

đź’¬ Support & Discussions
1

Hi everyone,
I am working with a 8-12 NIRx NIRScout device, I am doing an event-related design with the recording of six blocks of 16 trials each and I am doing GLM analysis with multiple events within each trials (encoding, retention delay, response etc…).
In order to do that, I have to record the six blocks in one session, and my participants have breaks in-between each block.
The problem is that the NIRx acquisition software doesn’t allow to stop-and-start the recording within a session, so I’m also recording the between-blocks signal.
In order to do a proper GLM analysis across blocks, I need to get rid of these between-blocks recordings.
Until now, I’ve been using the NIRSToolbox because it was easier for me to create a MATLAB function that cut my data during these gaps. The problem is that after I do that in MATLAB, the importation in MNE is almost impossible to get right (maybe because of subtle changes due to my custom-made function).
Since I want to use MNE-NIRS, I’m looking for a way to this between-block cleaning of the data within MNE-NIRS, so that I can do my GLM right.
Did anyone encounter that kind of problem? If so, how do you cope with it? I’m up for any advice to resolve this problem :slight_smile:

Thank you so much !!
Jérémie

2

Hello, do you have trigger / event signals in your data? If yes, you could potentially use mne.preprocessing.annotate_break() to automatically mark segments where no triggers occurred for a longer time (i.e., breaks) for exclusion.

Best wishes,
Richard

3

Hi Richard, thank you for your answer !
Yes I do have triggers that I can use to annotate these breaks.
But then, how would you “get rid” of the data in those breaks so that the continuous recording doesn’t include these parts for the GLM?
Thank you again :slight_smile:
Jérémie

4

Hello, I’m not sure how the GLM thingy retrieves the data, but normally, MNE tools should automatically exclude data that is annotated as “bad” (i.e., with an annotation description that starts with the string bad_). I assume this will be the case for the GLM code as well!

Best wishes,
Richard