I have a problem to find my correct events, because during data collection, the Biosemi system sent wrong extra triggers for some reasons, please see the screenshot. My correct triggers were sent correctly in the first line, but it kept sending 202020 triggers in the second line.
During preprocessing, I cannot find my correct triggers due to this error. By using find_events, it can find events, but then I want to print the events, it gives “You have 16 events shorter than the shortest_event…”.
I heard this error can be ignored in eeglab, can we do this in MNE? Could you please help me ignore the triggers in the second line. Thank you very much!
This error originates from your events having a duration of less than 2 samples. You can change that with shortest_event. However, I think you need to take a look at other parameters as well to tailor it to your needs: mne.find_events — MNE 1.3.1 documentation
I have tried different parameters and combinations. But it looks like MNE merges the 2 lines of triggers and the 202020 contaminates the correct ones. I don’t have trigger named 512, and I barely see my correct triggers, so it seems that it doesn’t matter how do I select events, no correct ones would show up.
Are there two separate trigger channels or just one? Can you not manually filter the events you want? If they stack (i.e. add up when occurring at the same time), maybe you can still find a criterion which tells you which events to keep.
Thank you very much for the help~ I tried it, but still got error “You have 16 events shorter than the shortest_event. These are very unusual and you may want to set min_duration to a larger value e.g. x / raw.info[‘sfreq’]…”.
I tried to set min_duration=2, it can run, but returns event ‘512’ which is the wrong event. I guess the system may merge events somehow.
if there are 2 separate stim channels, and one of them has the correct events and the other one is garbage, then try passing mne.find_events(raw, stim_channel='name_of_the_good_stim_channel')
The BioSemi system uses the lower 8 bits for actual trigger codes and the upper 8 bits for status updates about the system. This is what is generating these weirdly high event codes. In my opinion (yes, let’s add yet another opinion to this thread ) is to use the mask parameter of the find_events function to have it only pay attention to the bottom 8 bits of the status channel: