Life Science

cancel
Showing results for 
Search instead for 
Did you mean: 

Has anyone worked with Open EEG machine using labview to process signals?

Hello! I see there is some info regarding EEG's (Electroencephalograms) and I also see few of them have gotten far. I want to re-open this topic and see if I can get help from you Labview, Data Acquisition and Signal Processing experts to one and for all set the precedent of a working EEG.
 
There is a project at SourceForge (openeeg.sourceforge.net) in which a whole bunch of people worldwide contributed in order to create a low budget EEG.
Hardware problems were cleverly solved, and now you can download the blueprints, component list, etc. from the site, and even buy the assembled unit from Olimex for a fraction of the cost of a professional EEG.
 
However, there is no really good software for it, and I was thinking maybe this would be a fine project. To make a program that can help run OpenEEG from Labview, can anyone help me?
 
Open EEG has all the amplifiers, isolators, etc and there is one atmel AVR microcontroller on board which does all the sampling and ADC, and sends the info via Serial RS-232 protocol into the computers serial port. So I thought we could open that COM1 and take that info from within our VI, and start the part that is unknown for me, turning numbers into a continous signal that can be FFT and bandpass filtered down to a 1 to 20 Hz range i.e.
 
Another way to go here would be to use a DAQ hardware from NI, and tap into the OpenEEG amplified signals that go into the AVR DAC's, that way the info would go into the computer quick and painlessly, yet the processing is still unknown for me, and it also requires a bit more bugdet since buying the DAQ board is needed.
 
How about it? I guess it should be quite easy once decypher the way data arrives into the serial port (@57,600 bps)... The thing that also worries me is the fact that too much info would be arriving for labview to process, (128 samples per second per channel, 2 channels), is this too much? I once made an aplication that received streams of 29 bytes via serial around 12 streams per second, and labview would get really slow on a pentium 4 @ 1.6 GHz 385 MB RAM.
 
So thats pretty much my idea for the project, so if this interested anyone, please, would you help me?
jpangulo
 
 
0 Kudos
Message 1 of 6
(8,527 Views)
If you can capture the processed data through the serial port I would start there. Is that interface well-documented?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 6
(8,513 Views)
If you can capture the processed data through the serial port I would start there. Is that interface well-documented?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 3 of 6
(8,512 Views)
There are a number of opensource software projects (as well as closed source) already associated with the openeeg project.  What are you looking to do to differentiate yourself from those projects?  Are you part of the software mailing list for the openeeg forum?  If so, you should be able to get the API documentation for the serial interface.  Once you have answers to this, then I think the place you need to start is with a requirements document for the project you want to do... Open it within the OPENEEG forum, and then request help.  I love to do little science projects (no pun intended), but you are soliciting help for a problem you have not defined yet.  Also, despite your earlier issues with the serial port, I would not knock that approach yet.  Once you have your code project defined, and something up and running.  Then consider a different hardware interface.  That being said, code project should reflect the possibility that it may be receiving data from something other than the comm port.  IE USB, Ethernet, or yes, direct DAQ access.  this project will evolve over time.  Are you prepared for the committment that entails?


Paul
0 Kudos
Message 4 of 6
(8,505 Views)

Thanks for replying so soon. Well the mai problems with the OpenEEG software is that none of them are finished, and in order to get somewhere with them one should know how to program FFT and other complicated numerical aproaches for signal processing in C or Java, in labview its really different (or so I think), if anyone has downloaded from the OpenEEG Software page a program called Bioexplorer, it is a really nicely done program which reminds me a lot of labview, you just pick and place filters, bar graphs, spectrum analizers, etc. the program is $400 dollars and I think something similar could be done in labview.

My long term application would be a DSP that would do everything that we will do in labview, I would like to make a standalone application that you could connect to your scalp, and via leds or other actuators, create feedback. Yet first I would need to understand the processing of the signal if later I want to have it done inside a DSP.

You can check out some of my work in robotics in www.youtube.com/juanpablocanguro I have some nice videos there, and will commit to the time it takes to see this project through.

The objective as I see it is to create a Labview application that resembles Bioexplorer closed source software. If anyone downloads that software you will probably realize its not a lot of trouble, its a straight approach pretty much (I would think).

Thanks, I'll keep posting, check my videos and imagine a robot that responds to the presence of certain brainwaves!

0 Kudos
Message 5 of 6
(8,490 Views)
Hi everyone, please dont loose interest in this project. So I've found the info regarding communication protocol between OpenEEG machine (with Firmware version P2)and serial port. The machine sends via RS-232 protocol a packet consisting of 17 bytes of information to the serial port. first two bytes are 0xA5 and 0x5A (sync bytes), then third byte reads 0x02 (which stands for the version of the firmware), fourth byte is a packet counter which increases by one each time a packet is sent, then come 6 pairs of bytes which report each of the 6 channels in a 10 bit resolution, thats the reason why it uses 2 bytes per channel (format is Big Endian), and the last byte which I really dont understard, yet is always the same 0x0f. Here's a bit of the string I captured from the serial port using BioExplorer:
 

a5 5a 02 01 00 00 00 00 00 16 00 15 00 16 00
14 0f a5 5a 02 02 00 00 00 00 00 16 00 15 00
16 00 14 0f a5 5a 02 03 00 00 00 00 00 16 00
15 00 16 00 14 0f a5 5a 02 04 00 00 00 00 00
16 00 15 00 16 00 14 0f a5 5a 02 05 00 00 00
00 00 16 00 15 00 16 00 14 0f a5 5a 02 06 00
00 00 00 00 16 00 15 00 16 00 14 0f a5 5a 02
07 00 00 00 00 00 16 00 15 00 16 00 14 0f a5
5a 02 08 00 00 00 00 00 16 00 15 00 16 00 14
0f a5 5a 02 09 00 00 00 00 00 16 00 15 00 16
00 14 0f a5 5a 02 0a 00 00 00 00 00 16 00 15
00 16 00 14 0f a5 5a 02 0b 00 00 00 00 00 16
00 15 00 16 00 14 0f a5 5a 02 0c 00 00 00 00
00 16 00 15 00 16 00 14 0f a5 5a 02 0d 00 00
00 00 00 16 00 15 00 16 00 14 0f
 
So, any ideas on how to receive this information using labview? remember this info arrives at 57,600 bps, which means 423.6 of this packets arrive per second!!! of course we only need info out of two channels and maybe just check the counter to see if we have lost any packets and keep a lost packet count. So what do you think? any ideas on this?
THANKS!
0 Kudos
Message 6 of 6
(8,458 Views)