From: dev (dev_at_c...)
Date: 2001-07-12 19:45:10
I have just joined this group and still getting an overview of everything
that is trying to be done. I am relatively new to eeg, but I have been
studying it for a while now to build a good computer brain interface. I have
over 12 years experience in Computers, a wide range of everything, graphics,
3d modeling, troubleshooting, electronics, and of various different
platforms. So here is my 2 cents for now.
Software needs to be Windows 2000 or WindowsXP based, all DOS and windows
9x/ME is obsolete already. As for linux, I love it, but unless you have a
competent programmer in C/C++ as well as GTK or any of the 30 GUI language
for X-Windows, you will be wasting a lot of time. If you want to go that
route, make sure you use C/C++ so it can be easily ported back and forth.
And how do you plan on analyzing the data? Or are you just displaying it
with a GUI first? I have seen some that feed 16 inputs from 32 electrodes
into a Back prop Neural Network that can be trained for certain thought
patterns.
-- Jeff
> 2) What software platforms
I'd say just make it run on Win98/ME/2000 and that'll handle
95% of the current desires. Make it run on Linux in addition,
and you'll be at the 99% level likely for at least 10 years.
> 3) What is the precision needed? sampling rates?
Professional stuff starts at 12 bits-per-sample, two channels,
256 samples-per-second (on each). The analog/digital stuff in
the proposed circuits here seem to target 10 bits-per-sample.
That's probably fine, since a couple of actual low-end clinical
systems just use 8 bits-per-sample, though that's pushing it.
The 256 samples-per-second seems to be acceptable, as the highest
frequency most people ever use is 42Hz, and 256/sec seems to be
the standard export format. Four channels is probably all that
could ever be asked for for NFB, though QEEG'ers might want 32.
I'd settle for two. Even handling two sets of electrodes starts
not being fun.
> 4) An output API
There need to be two windows that provide feedback. One for
the subject, one for the operator. Even for non-clinical use,
and for subect-is-the-operator, I'd say this is the case. The
subject screen has some kind of games/animation -- with sound.
This should be handled via plug-in modules to allow flexibility,
as "games" covers a lot. The operator screen should also be via
plug-ins, as handling operator info has a lot of variability,
depending, at least, on how many channels are implemented. One
really useful operator screen is a "bilateral frequency mirror"
as the operator view for a two-channel system. The Windows
systems I specified can automatically use multiple display-cards,
so the two windows can easily be separated onto two monitors.
Everything beyond this is gravy.
- Lenny Gray -
To unsubscribe from this group, send an email to:
buildcheapeeg-unsubscribe_at_egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:31 BST