<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML DIR=ltr><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"></HEAD><BODY><DIV><FONT face='Arial' color=#000000 size=2>A colleague and I are having trouble getting EEGLAB 4.515
to read event codes from a BDF data file. The file in question reads fine
in BESA, so I am confident that it is intact. We were able to replicate
the problem with a small BDF data file containing just noise and 11 event
markers, so I have posted the small file showing the problem here: <A
href="http://www.cortechsolutions.com/Temp_Downloads/testdata2.zip">http://www.cortechsolutions.com/Temp_Downloads/testdata2.zip</A>. </FONT><FONT face=Arial color=#000000 size=2>I tried designating the last
channel as the event channel upon initial import, but using that method EEGLAB
finds no events (and proceeds to delete the Status channel). When I do not
designate the event channel on data import, but I use the separate import event
markers function, I get basically the same result - no markers found. Any
assistance we can get would be much appreciated.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>By the way, I have noticed that there is a new
function in EEGLAB that masks the middle byte and the most significant byte on
the status channel. I can see how that is useful (assuming you are not
having trouble reading events like I am), but people should be aware that
the most significant byte of the Status channel in
ActiveTwo encodes events like pause and resume, so it could be problematic
to ignore these events if you used the pause/resume functions during a
recording. As far as I can see, ignoring the most significant byte could
lead to discontinuous data points spanning a pause/resume event being treated as
if they are continuous. In some cases that may not be a problem, but in
others it could be a significant problem. Also, the most significant
byte encodes CM out of range (CMS or DRL electrode not connected) and
low-battery events. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>On a related topic, I noticed the thread ending at
about
<DIV><FONT face=Arial size=2><A
href="http://sccn.ucsd.edu/pipermail/eeglablist/2005/000780.html">http://sccn.ucsd.edu/pipermail/eeglablist/2005/000780.html</A> probably
precipitated the addition of the mask function noted above. I don't know
why people are seeing ringing, but if it is related to the middle byte and most
significant byte interfering with clear interpretation of the trigger events on
the status channel, then I suspect another solution would be to read and log the
events on the most significant byte in a way that users can easily access them
(and avoid analyzing across discontinuities, for example). For reference,
here are the events logged in the most significant byte of the Status channel in
ActiveTwo:</FONT> </DIV>
<UL>
<LI>
<DIV style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Bit 16 is set high at
the beginning of a new "epoch". </FONT></DIV>
<LI>
<DIV style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Bits 17-19 can be
ignored. </FONT></DIV>
<LI>
<DIV style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Bit 20 encodes the "CM
in range" status. It's a long story, but it essentially tells the
user whether the data they are measuring are real data or just noise. If
CM is in range, bit 20 is high; if CM is out of range, bit 20 is low.
</FONT></DIV>
<LI>
<DIV style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Bit 21 can be
ignored.</FONT></DIV>
<LI>
<DIV style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Bit 22 is high when the
battery is low. </FONT></DIV>
<LI>
<DIV style="MARGIN-RIGHT: 0px"><FONT face=Arial size=2>Bit 23 can be
ignored.</FONT></DIV></LI></UL>
<DIV> </DIV><A
href="http://sccn.ucsd.edu/pipermail/eeglablist/2005/000780.html"></A></FONT></DIV></BODY></HTML>