mne.preprocessing.find_ecg_events produces different output with vs without ECG channel

  • MNE version: 1.0.3
  • operating system: e.g. macOS Montery 12.6
ecg_events, ch_ecg, average_pulse, ecg=mne.preprocessing.find_ecg_events(raw_cropped, return_ecg=True, verbose=False)
print('Number  of ECG events detected with ECG channel present: ', len(ecg_events))

Output: 87

ecg_events2, ch_ecg2, average_pulse2, ecg=mne.preprocessing.find_ecg_events(raw_cropped2, return_ecg=True, verbose=False)
print('Number of ECG events detected - ECG reconstructed: ', len(ecg_events2))

Output: 101

We are using mne to build software for quality control of MEG data.
When trying to cover different cases, for example MEG data with/without ECG channel, we found that the output of running mne.preprocessing.find_ecg_events are significantly different (number of ECG events differs on average by about 25%). Tried on 5 different data sets from openneuro and our own lab and all showed the same pattern (except one). The screenshots can be provided if needed.
Have you encountered this problem before or have any advice on solving this issue?

Thanks in advance!

It is not really clear what you want to solve here from the perspective of data processing.
So if I understand correctly, the problem is that the outcome depends on the selection of the ECG channel/ dataset? It makes sense the result is different depending on the selection of the ECG channel ;-), so I am not sure why this issue warrants any solution in the postprocessing of the data in that case. The proportion of ECG events differes with each dataset and the algorithm is much more reliable in picking up ECG events (more sensitive) when using dedicated ECG channels as a guide.
But perhaps I misunderstood the question here.

Thanks for answering! The problem is in making reconstruction of ecg events more reliable.
Let’s say I have a data set with ECG channel present. I run mne.preprocessing.find_ecg_events on it - it gives me 70 ecg events.
I take the same dataset and omit ECG channel from there. So I let mne.preprocessing.find_ecg_events automatically reconstruct the ecg events on base of magnetometers - I get 100 events.
I would expect around 70 in both cases since I use the same data. If the number of ecg events for the same data is very different with reconstruction - it means reconstruction is not very reliable?
Tried 5 data sets with similar outcome.

Can this be fixed or some parameters set to make reconstruction more reliable?

I would like to use ecg reconstruction later on the data which has no ecg channel present - but I m hesitant to do so since it can produce wrong result.

this isn’t really a solution to your question, but it might make you less worried about it :slight_smile:

Let’s assume that the find_ecg_events algorithm works better when you give it a real ECG channel to work with. So then if the magnetometer-based heartbeat detection run finds more heartbeats than the ECG-based detection run, it means it’s got some false-positives. These will add some noise to the estimated average heartbeat signal, but because it is an average, at least some of that noise (maybe even most of it) is going to cancel out during averaging.

I would encourage you to quantify how different the results really are (beyond just “number of events detected”) and maybe even see how big an effect this is having on downstream results. For example, plot side-by-side the averaged heartbeat epochs from the two detection runs, or analyze how correlated they are. Then plot the scalp topography of an SSP projector created from each run. Are they very different? If not, maybe there’s no need to dig deeper. If they are, you can start looking at things like tweaking the filter parameters, trying other libraries (e.g., GitHub - berndporr/py-ecg-detectors: Popular ECG R peak detectors written in python), or using ICA instead.

I will add one more point to this, could you check the detection itself with plots similar to what I did here: ICA find_bads_ecg Function - #4 by mscheltienne

At least you will be able to see which kind of data produces false positives, and it might give you clues on what to do next.