From: Buttlar (mb981282_at_m...)
Date: 2001-07-12 15:23:13
Hi !
Great that you start getting together the specifications :)
>As a project leader in several previous development efforts I begin
>by asking questions revolving around previous design decisions
>especially about hardware. Although my expertise is not in interface
>APIs I can ask a few pertinent questions.
>
>1) I understand by reading many of the posts that the hardware will
>contain the A/D converters and an RS-232 serial port is the expected
>output method. If I am wrong, please correct me. Why is this method
>chosen? Have you considered a USB port? parallel port? Have you
>considered using a well designed sound card to perform the A/D
>conversion? What were the critical design constrains that lead to
>this choice? Answers to these questions can help with the definition
>of requirements for the software interface API.
RS232 is available on most systems. Itīs fast enough for our purpose, easy
to design the hardware and the software,
easy to isolate (at least easier then USB), easy to debug, cheap. Soundcard
was considered but it has a lot of disadvantages regarding
optical, linear isolation and an built-in bandwith limit for low frequency
signals. Parallel port would be possible but it doesnīt give advantage over
the serial port except higher bandwith for data (but we donīt need higher
bandwith). We also considered IrDA.
This would be a great alternative to RS232 because it has inherent
isolation safety which would maybe decrease the amount of safety testing
required.
The problem is that the implementation of the complete IrDA software
architecture (IrCOMM layer) is quite difficult on a microcontroller
and thereīs no GPL/open source code available. The question is if thereīs
some direct access to the raw data received by the host PC
so that it would be possible to develop oneīs own protocol. If this is
possible, IrDA would be a great choice. Maybe you could check that out
somehow ? The implementation of the hardware IrDA specifications is quite
easy.
>
>2) What software platforms and OSs does the CheapEEG software need to
>support? This will require a variety of input for each additional
>configuration needed.
Iīd like Linux and Windows support. It would be great if we could develop
the software using gcc and then compile it
for windows and linux without changing much of the code.
>Is there any on-board memory or CPU control
>expectations for the hardware sensing unit?
The cheapeeg can also receive commands. Once sampling is started, the
cheapeeg will send data on itīs own without any
special commands/timing or whatever needed.
>
>3) What is the precision needed? sampling rates? quantity of data
>expected? timing constraints?
It would be great if the software would process at least 16 bit data so
that we can upgrade the cheapeeg later without
rewriting the software. Sampling frequency <=256Hz, 2-4 channels
>
>4) For neurofeedback, an output API will be needed in addition to an
>input API. What are the expected output mechanisms? visual? audible
>or EM signal? What devices are expected to be used for entrainment?
>Computer screen? headphones? Light glasses? Mag-stim headset?
>combination of above?
Probably a combination of the above. Maybe we could use fuzzy-logic to
trigger the feedback devices ?
I think that would be a great technique to use for triggering only when
multiple requirements are fulfilled.
Did anybody ever use fuzzy logic for neurofeedback ? Iīd like to experiment
with that.
>
>5) What kind of user interface is expected to operate the unit? DOS
>or LINUX textbased? control only? Windows XX, BEOS or LINUX GUI with
>graphical display and sophisticated recording, management and control?
X-Windows/Linux and Windows. Graphical display would be desirable.
Moritz
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:31 BST