From: lenngray_at_yahoo.com
Date: 2001-07-12 18:00:47
--- In buildcheapeeg_at_yahoogroups.com, "Ken Michel" <michelangelo46_at_h...> wrote:
>
> ...
>
> 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 -
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:31 BST