From: frans (f.smith_at_c...)
Date: 2001-07-13 18:55:46
Hi Yaniv and other members,
I was thinking of a MODULAIR BFB/NFB SYSTEM.
*Computer interface including .
* Module 1, EEG for neurofeedback.
* Module 2, ECG
* Module 3, GSR (very effective for anxiety)
* Module 4, Temperature FB.
* Module 5, EMG
If one suffers from high blood pressure or anxiety one can choose the best module.
In such cases one can experience BFB for this is not
only effective, but also easy to do. NFB is not some-
thing you can do just like that.
Also if you read different cases, you would find that
a combination of NFB/BFB is common use.
For example: a jong man with attention dissorder
was trained with NFB, but the therapist also found
some anxiety, therefore using Temp. FB to compleet
the therapy.
To make NFB accessible for everyone is okay, but
its also common use that professionals first study BFB.
I think a good basic foundation in general BFB will
be best for all non-professionals.
I am aware of the fact that such a design brings a lot
of problems, sinds- for example- amp-input/design
depents on what data to process (EEG,EMG).
Perhaps EEG, EMG, GSR, TEMP, ECG modules
each a compleet set/analog part.
A multi-functional digital interface (without analog part).
In this case one can buy or build the pc-interface and
then choos a module, to start with.
Such a system would be accessible for everyone.
Software design incl. games would be better sinds
SW-members could concentrate on a specific module,
become more professional in that area of BFB.
This is for the benefit of the group.
A this moment everyone would try to build SW for
only one system. SW for EEG would be much more
complex for some members who would like to help programming but cannot match up with EEG. A module for only blood pressure or hearbeat (not ECG) is simple
but would give less experienced programmers a change
to improve there skills, and also would make those
active members. Working on different modules would
then result in lots of SW so as to find the best SW or
to compare/change/improve designs.
The project then would be accessible for starters
in HW/SW/microcontroller tech/digital systems...
All could learn al lot in this case.
Also the experience with the modules by all members
- once build in proto- would give all of us practical
information to improve our overall skills and knowlegde.
Finally, a starters module like GSR would be not so
expencive and therefore ideal for beginner/student or
experimenter with low-budget.
So my fellow-members, a modulair system would
reach more people, poor, rich, student, proffesional,
HW/SW builders/constructors, potential customers,
people with special demands (illness, peak performance).............
Thanks..
Best Regards.
Frans.
----- Original Message -----
From: yaniv_vi_at_yahoo.com
To: buildcheapeeg_at_yahoogroups.com
Sent: Friday, July 13, 2001 8:28 AM
Subject: [buildcheapeeg] Re: Software requirements
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
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
buildcheapeeg-unsubscribe_at_egroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:31 BST