High-frequency noise in source waveform after filtering

Hi,

I am doing source analysis with MEG/EEG data and came across some weird behavior where I couldn’t find the problem yet:

When extracting the time courses from a label (doesn’t matter which one), the time courses of 4 out of 19 participants show some high frequency noise, despite a .05-20 Hz bandpass filter. The attached screenshot shows one affected (left) and one normal participant.

I use the same script for each participant and the raw and epochs.info show the desired 20Hz lowpass filter. When I plot the evokeds, it still looks clean, but the time course extracted from the stc is noisy.
I tried combining files (raw, epochs, fwd, cov…) from a noisy and a normal subject to narrow down the origin and it seems to be the epochs.
However, with epochs.plot() they look similar, so the noise is not obvious here. And the infos look similar regarding the settings.

Any idea, where this is coming from or how I could solve this?
I can obviously filter the extracted waveform, but I would like to understand what’s causing this.

I’m using MNE 1.8 on Ubuntu 24.04

Best,
Laura

P.S: I am happy to share data or code, but I wasn’t sure which part of the code would be helpful, as the same code produces different results depending on subject and the full code is quite long.

Here are the two exampe epochs.info:

epochsNoise.info
Out[164]:
< Info | 21 non-empty values
acq_pars: ACQch001 111001 ACQch002 111002 ACQch003 111003 ACQch004 111004 …
bads:
ch_names: MEG 001, MEG 002, MEG 003, MEG 004, MEG 005, MEG 006, MEG 010, …
chs: 118 Gradiometers, 7 Stimulus, 64 EEG, 1 ECG
custom_ref_applied: False
description: These data were measured with Neuromag-122
dev_head_t: MEG device → head transform
dig: 150 items (3 Cardinal, 4 HPI, 64 EEG, 79 Extra)
events: 1 item (list)
experimenter: eeg
file_id: 4 items (dict)
highpass: 0.1 Hz
hpi_meas: 1 item (list)
hpi_results: 1 item (list)
lowpass: 20.0 Hz
meas_date: 2022-02-21 08:02:24 UTC
meas_id: 4 items (dict)
nchan: 190
proj_id: 1 item (ndarray)
proj_name: aep
projs: planar-Raw-0.000-1370.655-PCA-01: on, planar- …
sfreq: 1000.0 Hz
subject_info: 3 items (dict)

epochsSmooth.info
Out[165]:
<Info | 21 non-empty values
acq_pars: ACQch001 111001 ACQch002 111002 ACQch003 111003 ACQch004 111004 …
bads:
ch_names: MEG 001, MEG 002, MEG 003, MEG 004, MEG 005, MEG 006, MEG 010, …
chs: 118 Gradiometers, 7 Stimulus, 64 EEG, 1 ECG
custom_ref_applied: False
description: These data were measured with Neuromag-122
dev_head_t: MEG device → head transform
dig: 150 items (3 Cardinal, 4 HPI, 64 EEG, 79 Extra)
events: 1 item (list)
experimenter: eeg
file_id: 4 items (dict)
highpass: 0.1 Hz
hpi_meas: 1 item (list)
hpi_results: 1 item (list)
lowpass: 20.0 Hz
meas_date: 2023-08-02 04:22:52 UTC
meas_id: 4 items (dict)
nchan: 190
proj_id: 1 item (ndarray)
proj_name: aep
projs: planar-Raw-0.000-1363.050-PCA-01: on, planar- …
sfreq: 1000.0 Hz
subject_info: 3 items (dict)

Hi,

It’s difficult to really say by looking at these plots but I am not so sure the “high frequency noise” falls outside the beta band.

Maybe you’ve tried this already, but personally I would plot a PSD before and after filtering, and also I would try lowering the low-pass cutoff to see if/when the noise disappears.

Cheers,

Not sure if this is related, but are amplitudes in the range of 10-12 expected? What is the unit? µV?

Chiming in here - Which source recon method do you use? Can you show us the sensor and source time courses of a dataset with this problem?
Edit to add: and is this true for all of the source time courses or only in specific regions/labels?

Thank you for your replies!

Following @sotpapad suggestions, I checked the PSDs again and the confirmed that the filter worked as suggested. They also looked highly similar for noise and normal subjects.
I tried the filtering with a 15Hz cut-off which resolved the issue. So I wanted to find the “threshold”-frequency, where this works.
It turns out that just re-filtering with 0.05-20Hz now also solved the issue (I could have sworn that I tried that before).
But: the PSD for the original epochs (filtered once) and the double-filtered once look virtually identical. The screenshot shows this for one condition.

So I guess, we can say that my problem is solved and no one has to invest a lot of time.
But since I still don’t understand it, ideas are still welcome :smiley:

@cbrnr This should be in Am and is the range that we usually find in our experiments, so nothing uncommon as far as I can judge.

@britta-wstnr I am using MNE with a mean_flip to extract the time course. This happened for different ROIs. I attached screenshots with the evoked.plot and randomly spaced traces in the stc.plot()
There you can see that some regions are more affected by the high-frequency noise than others, but it’s generallys there for all traces.


Thanks again to everyone!
I’ll stick to double-filtering for now, but I am curious if anyone has another idea.

Best,
Laura

Good that you solved it, a bit weird though.

I have seen similar “problems” using notebooks when some variables are kept in memory and do not behave as expected after changing some parameters.

:male_detective: I’m intrigued.
I see that you use EEG and MEG, presumably combining them. I wonder if you get some unexpected effects from that … Any chance that you have looked at the EEG-only and MEG-only source recons for the affected data sets?

That’s a good idea, I’m using a notebook… more powerful than the previous desktop machine, but this experiment also has a lot of conditions, so memory demands are certainly high.

But the incorrectly applied filter should still show in the psd and epochs plot, right? :thinking:

:male_detective: I’m intrigued.

Love that :smiley:
I haven’t looked at MEG and EEG separately yet, but I will do and let you know.

It should. In order to be sure I would create a simplified notebook and run each cell only once for a “clean” subject. Then, restart the notebook and re-run everything for a “noisy” subject. If the problem is fixed chances are something did not execute as expected before. If it persists something weird is happening and will require more debugging.