Hi,
I have a question regarding the minimum signal duration to estimate tPAC. Here it says a minimum of two fp cycles for ground-truth synthesized data. I was wondering if this is the same for real data. I am trying to find the equilibrium between using too big of a window compared to one not big enough.
Hi,
Yes, it is recommended that you set the window lenght at least equal to two periods of the minimum frequency of interest you specified for f_p range.
For example if you are interested in 3-6 Hz the window length should be at least 2 x (1/3) = 0.66 sec. Of course if you have longer data (e.g. resting state recordings) increase in this window length would result in higher SNR and more accurate results.
If you want to check multiple bands, it is recommended to check the separately so you could set your window length shorter for example if you look at beta band for f_p (compared to delta).
Thank you for your reply. I just have a few more questions for you:
(1) Is there a reason why the ouput from tPAC has always the label E1 even when changing the channel to display? I just want to make sure the output indeed corresponds to the selected channel since it does change from one channel to another.
(2) I am using an input with length of 1 second, but the output displays less than that. Is tPAC not compute using the whole second? Is this affected by the length of the sliding time window?
(3) When extracting the comodulogram (not time resolved), can the so obtained map be considered an average of the PAC across the window used?
Thank you for your help,
Lorenzo.
Is there a reason why the ouput from tPAC has always the label E1 even when changing the channel to display?
The first "E1" string is actually part of the file name, which does not make much sense.
When changing the channel in the Display tab, it updates correctly the label in the figure ("E5" on your screen capture).
To avoid having only the name of the first channel in the tPAC file, I propose this change: Bugfix: tPAC file name with more than one selected channel · brainstorm-tools/brainstorm3@ca42ace · GitHub
@lorenzo664 Update Brainstorm to get this fix.
@Samiee Can you please make sure it doesn't break anything?
(2) I am using an input with length of 1 second, but the output displays less than that. Is tPAC not compute using the whole second? Is this affected by the length of the sliding time window?
You output file is 1 second long (-500ms to +500ms).
Can you please post a screen capture of the inputs of the process?
(3) When extracting the comodulogram (not time resolved), can the so obtained map be considered an average of the PAC across the window used?
From the code, I'm not sure it works this way...
@Samiee ?
