LSL Biosemi App not receiving triggers

[apzamm]

Dear LSL developers,

I am collecting EEG data using the Biosemi LSL app, and sending triggers to the app via the parallel port (I was of the understanding that LSL's Biosemi app reads input from the parallel port). According to the Biosemi LSL wiki, triggers should be recorded along with EEG data as a single stream in LSL's LabRecorder (stream type = EEG), with triggers being stored on data channel 1.

However, when I load the xdf file into MATLAB (load_xdf.m), I do not see triggers on data channel 1. Instead, data channel 1 contains the value -8191999, repeated at every sample. Is there an alternative data structure in the XDF file where I might find the correct triggers? Or does the Biosemi app not read triggers over the parallel port and instead should I be sending them over the network to the Biosemi LSL stream?

Your help troubleshooting this problem would be greatly appreciated.

Thanks in advance, Anna Zamm

[chkothe]

Dear Anna,

can you confirm that you get the trigger values back when you record your data through ActiView and them import the resulting .bdf file into EEGLAB (since there's quite a bit of room for things to go wrong elsewhere with a parallel port connection)? If so, then there might be a problem with trigger receipt. The value that you see in channel 1 does indeed look like an empty trigger channel (the base offset on top of which your markers sit can be pretty arbitrary if I remember correctly). You can also check the channel type in the streams{mystream}.info.desc (or similar) struct that load_xdf returns and confirm that it's set to 'Trigger'.

Aside from this method it's indeed more common in LSL to just emit markers into LSL from your experiment script (as in any of the example scripts), which will then be recorded together with all the other data by the LabRecorder. If your script is in any of the supported programming languages then that should be pretty much trivial (5-10 lines of copy-paste code total depending on language), or if you use a stim presentation package that has LSL support built in, you should be able to use that, as well (e.g., Presentation).

Christian

On Mon, May 2, 2016 at 8:43 AM, apzamm notifications@github.com wrote:

Dear LSL developers,

I am collecting EEG data using the Biosemi LSL app, and sending triggers to the app via the parallel port (I was of the understanding that LSL's Biosemi app reads input from the parallel port). According to the Biosemi LSL wiki, triggers should be recorded along with EEG data as a single stream in LSL's LabRecorder (stream type = EEG), with triggers being stored on data channel 1.

However, when I load the xdf file into MATLAB (load_xdf.m), I do not see triggers on data channel 1. Instead, data channel 1 contains the value -8191999, repeated at every sample. Is there an alternative data structure in the XDF file where I might find the correct triggers? Or does the Biosemi app not read triggers over the parallel port and instead should I be sending them over the network to the Biosemi LSL stream?

Your help troubleshooting this problem would be greatly appreciated.

Thanks in advance, Anna Zamm

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/sccn/labstreaminglayer/issues/116

[apzamm]

Dear Christian,

Many thanks for your prompt response.

Yes, the trigger values are recorded in Actiview so I know that they are being received by the parallel port.

And yes, streams{mystream}.info.desc.channels.channel{1}.type = 'Trigger', so channel 1 does seem to be designated for recording triggers.

Yes, I am sending triggers into LSL from my experiment script, and this works just fine; the problem is is that my timing tests require use of a signal generator that only sends triggers over the parallel port. I would like to confirm that onsets of a periodic square wave are not jittered relative to the onset of corresponding triggers. However, I am not able to do this if the LSL Biosemi app does not read triggers over the port. Is there any way to confirm this?

Thanks in advance, Anna

[Foucl]

For me, the BioSemi App records the triggers just fine. We have a NI-DAQmx (digital only) setup which I interface with through pylibnidaqmx. Events can then be conviently extracted, e.g. through eeglabs pop_chanevent or any other method.

However, turning on the option to resample the data to 512Hz introduces so much ringing to the Trig1/STATUS channel that it's becoming impossible to reliably identify the trigger value. Do you have an idea if/how the resampler could be modified to leave the amplitudes of the trigger channel intact?

[dmedine]

This is an interesting problem. The BioSemi.exe application uses long FIR lowpass filters to get rid of frequencies in the signal that will alias after downsampling. This is what causes the ringing in the trigger channel (which I guess is a pulse signal?).

From looking at the code I, for one, can't see any 'quick fix' that will solve this problem. To me it looks like all trigger channels need to be treated separately and handled with a different resampling process than the EEG channels. Probably just resampling and not filtering at all would be preferable to the filtered version. The ideal thing would be to simply check the upsampled stream for triggers and if one occurs in (for example if the downsampling rate is 4 to 1) any of every 4 samples, then the downsample stream would have a trigger there. This could get a little tricky, though, depending on the width and fidelity of your trigger signal.

In any case, I believe some pretty serious overhaul to the BioSemi code is needed to solve this issue. Right now all the channels are handled the same way and to tease the trigger channels out of the processing chain is non-trivial.

On 11/1/2016 3:59 AM, Christopher wrote:

For me, the BioSemi App records the triggers just fine. We have a NI-DAQmx (digital only) setup which I interface with through pylibnidaqmx. Events can then be conviently extracted, e.g. through eeglabs pop_chanevent or any other method.

However, turning on the option to resample the data to 512Hz introduces so much ringing to the Trig1/STATUS channel that it's becoming impossible to reliably identify the trigger value. Do you have an idea if/how the resampler could be modified to leave the amplitudes of the trigger channel intact?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sccn/labstreaminglayer/issues/116#issuecomment-257539488, or mute the thread https://github.com/notifications/unsubscribe-auth/ADch7rRRm7f0Fk5GinNe_rvt3lZ2JcZPks5q5xumgaJpZM4IVdS7.