[Eeglablist] EEGLab, BioSemi ActiveTwo mk2 and event markers

[Lloyd Smith]

Dear Andreas,  

Thank you for your response and the suggested workaround.  The ActiveTwo
trigger input port and software design do not limit the type of trigger
cable, triggering device, logic, etc. that can be used to introduce
markers, and this is an advantage over other systems.  However, the
flexibility of this approach does place a bigger burden on analysis
software.  In essence, the Status channel is rich with information, but
the information is encoded in a raw form that needs to be digested to
identify triggers and other events.  On the positive side, the raw form
of the Status channel is rich with information that can provide much
more than the simple event marker interface provided with most EEG
systems.  FYI -- the spurious events reported by EEGLAB users in BDF
files are NEVER found by BESA, EMSE SUITE, BrainVision Analyzer, PolyRex
(converter to Neuroscan), etc.  This is the only reason I continue to
suggest that someone might want to review the EEGLAB code that reads the
events from the BDF Status channel.

Lloyd Smith
Owner
 
Cortech Solutions, LLC
321 N. Front Street, Suite 113
Wilmington, NC 28401 USA
Tel: 910-362-1143
Fax: 910-362-1147
Cell: 910-431-2811
E-mail: LSmith at cortechsolutions
Web: www.cortechsolutions.com

-----Original Message-----
From: Andreas Widmann [mailto:widmann at uni-leipzig.de] 
Sent: Monday, July 16, 2007 5:23 AM
To: eeglablist at sccn.ucsd.edu
Cc: Lloyd Smith
Subject: Re: [Eeglablist] EEGLab, BioSemi ActiveTwo mk2 and event
markers

Dear Lloyd,

sorry, I can not withhold a partial comment:

> This problem is reported to me at least once a week by EEGLAB users -
it
> is a known issue in EEGLAB that all ActiveTwo/EEGLAB users are
grappling
> with one-at-a-time.
(1) Indeed, this is a problem being reported also to me at rather
regular intervals, but:
(2) This is *NOT* an EEGLAB issue and there is nothing EEGLAB or
BIOSIG developers could do about (except informing their users about
possible workarounds).

> If you are using
> our standard 8-bit trigger cable, then this value is spurious
(generated
> by EEGLAB or BIOSIG)
This value is *in the data* and and is *not* generated by EEGLAB or
BIOSIG. There is no way to determine for a bdf reader software
whether an 8- or 16-bit trigger cable is attached to the trigger input
box and whether this value might be intended or not.

So far, this problem indeed has only been reported to me by labs using
cables where bits 9 to 16 were not shortened to ground. However,
un-shortened trigger channels resulting in unpredictable data is imho
a problem of hardware design (respectively documentation) rather than
reader software. Pulling up open trigger input lines only requires a
small circuit. I'm sure this is possible as it is in fact realized by
competitor products.

> description of the BDF Status channel that explains how the valuable
> status data (cm in/out-of range, battery low/OK, etc) are encoded in
the
> Status channel.  I believe that these useful pieces of information are
> still ignored by EEGLAB, but it would be nice if they were properly
read
> and encoded.
There is an EEGLAB compatible sample implementation for a bdf reader
(pop_bdfread.m,
http://www.uni-leipzig.de/~biocog/widmann/eeglab-plugins/index.html)
which removes CMS out-of-range sections from the data and inserts a
boundary trigger at epoch onsets (there's also a 'holdValue' option
which should work around the problem described by Bill; however, reading
sections of files is not (yet?) supported).

Best regards,
Andreas