From: yaniv_vi_at_yahoo.com
Date: 2001-07-13 07:28:13
hi
it's really cool that your all starting to work seriously on specs!!!
i have one comment :
when you think about this software , i think it should be fit to
next version of cheapeeg.
my view of the next versions are (just ideas)
1. very low cost version , that the input to pc will come from
soundblaster input .
2. a neurofeedback+biofeedback device . i read some abstarct that
combining nfb and bfb is much faster way to learn self control on
both . i don't know exactly how it would be implemented ,
but i think minimum 8 channels , with sampling rate that would
make emg (muscle) feedback available .
i'll post some message to our nfb pros and ask .
does it make it alot more complicated ? why ?
so if the sw could fit top this it would be much better .
also i thin it should be build in such a way the all or at least
most companies with nfb /bfb device could work with it by just
writing the sw driver .
also one little idea : is there as possible interface to some kind of
math language like matlab / some grapick programming language , etc ?
because it would be much easier for research and trying all sort
of things , like fuzzy logic or many others , and after some new idea
shown it's worth - then some programmer could code it .
maybe also find some tool/language that a nfb practicioner could use
very easily and have the option to connect it to the sw.
this is a very good way to promote innovation .
the only problm that might be is real time . how do you sole such
problem ?
sincerly yaniv vilnai .
--- In buildcheapeeg_at_yahoogroups.com, Buttlar <mb981282_at_m...> wrote:
>
> 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