[Eeglablist] Event codes in BioSemi BDF data files

[Lloyd Smith]

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:  http://www.cortechsolutions.com/Temp_Downloads/testdata2.zip. 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.
 
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.  
 
On a related topic, I noticed the thread ending at about 
http://sccn.ucsd.edu/pipermail/eeglablist/2005/000780.html 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: 

*	
	Bit 16 is set high at the beginning of a new "epoch".  
*	
	Bits 17-19 can be ignored. 
*	
	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.  
*	
	Bit 21 can be ignored.
*	
	Bit 22 is high when the battery is low.  
*	
	Bit 23 can be ignored.

 
<http://sccn.ucsd.edu/pipermail/eeglablist/2005/000780.html> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20051209/374f627d/attachment.html>