openeeg-list — Public forum for everyone

Re: [Openeeg-list] Re: Vol 1 #4 - mail delivery

[Dave F. <df...@po...>]

On Sat, 13 Jul 2002 19:03:43 +0100, Jim Peters wrote:

>For lists that are open to non-subscribers and get a lot of
>cross-posted discussions, it makes less sense.  But perhaps it would
>be good to turn them on for this list ?  This means that the list adds
>a Reply-To field containing the list address to each message, so that
>people hitting 'reply' have their reply sent back to the list by
>default.  (Otherwise they have to always use 'reply-to-all').

I would rather a Reply-To also, as I know that I am going to mess up and send
mail directly to the writer, as I ironically almost did with this post!  I will
now have to go up and change the "To:" field because I forgot to "Reply to
All."

Oh, and my crossposted messages bounced back from Yahoo, so I see progress is
being made to get things moved over to here, the sourceforge list. :)

Dave.

[Openeeg-list] Considerations

[Dave F. <df...@po...>]

[crossposted to both Yahoo and Sourceforge list, please respond on Sourceforge
openeeg-list]

Some project related considerations:

Licensing
----------------------------------------------------------------------------

Notice that I have been using Larry Wall's (the author of Perl) "Artistic"
license for my stuff.  This may not be the best choice now that I think about
it (a scripting language is different from an SDK), but I chose it because it
represents a nice balance between the more strict GPL style license and more
lax BSD style.  I personally lean more toward BSD style, though.  My reasoning
is that a support library can be protected as an open-source project, but
spin-off applications using that library have the prerogative of being either
open or closed.  Even if someone chooses to create a closed app, it would
behoove them to be involved in contributing to the open-source supporting
library.  While I know that wars have been fought over this issue (and I have
*no* desire to have that happen!), I see that the licensing strategy posted on
Sourceforge is GPL.  If there is no interest in any of the more balanced
licensing strategies, can we at least change this to LGPL for the SDK?

A more comprensive discussion for licensing strategies can be found here:

http://www.stromian.com/Public_Licenses.html

Copyright
----------------------------------------------------------------------------

I have removed my Copyright line from all the source code files.  Does anyone
have a suggestion for what kind of Copyright notice should be included in the
header of every source code module?  Can the group as an entity carry the
copyright (as in "Copyright (c) 2002, OpenEEG Source Code Project", or does
this need to be a legally recognized entity (such as a person or corporation)?


Source Code Guidelines
----------------------------------------------------------------------------

I recall some discussion on this a while back.  I feel that we need some kind
of framework (and there are *many* examples of guidelines posted for different
projects on the web).  However, I personally do not want to take this to the
extreme where every jot and tiddle is defined, right down to how many spaces
exists between the parenthesis on if-statements or whether you part your hair
on the left or on the right (or not at all, for that matter).

Perhaps the most picky thing we can agree upon are the use of braces.  There
are three popular methods right now, from the original K&R way:

if ( ... ) {
    [do something]
}

to the 80's way

if ( ... )
    {
    [do something]
    }

to the 90's way

if ( ... )
{
    [do something]
}

Personally, I have used all three and am currently using the 90's way.  Who
knows, perhaps we'll come up with another way?

I also see a lot of merit in *documenting* the code internally.  Not only will
this help other programmers to know what was going on in your head when you
wrote something like:

[thread creation code... then]

if ( !thread )
{
    thread = new DummyThread;
    Thread::_self.setKey(thread);
}

return( thread );

It will also help *you* to remember what in the world you were doing months
later when you come back to certain sections of code.  The above, btw, is a
real example that led me to abandon Common C++ (as well as Andreas' suggestion
and coaxing :).  For example, why is a new instance of a thread being created
that has nothing to do with the currently running thread or thread that you are
trying to create?  It led to erroneous results in my own threaded application,
and I have no idea what the rationale was for allocating a "fake" thread
on-the-fly rather than generating an exception.  Documentation would have
helped immensely here after I tracked the error down to this little section of
code deep in their own library.

Doxygen notation

I *love* Doxygen!  It is a great way to create class documentation.  For an
example of an old version of one of my previous alpha-alpha libraries, go here:

http://www.psychosensory.com/linuxeeg/sourcedocs/index.html

Some guidelines to remember are:

Use @author for each class.  This will help us know where to direct questions.
Use @param and @return for each method.
Use @see when appropriate.

Use:

/**
 * Class documentation here...
 */

to document classes and methods (and I think variables, but I'll have to
double-check that).  The "/**" notation signals doxygen that this is a
documentated item.

See http://www.stack.nl/~dimitri/doxygen/docblocks.html#docblocks for more
information.

There are two primarily styles -- JavaDoc and Qt.  I think JavaDoc makes more
sense and just plain looks prettier. :)


"FIXME:" notation

You will notice that I use the notation "FIXME:" in the source code when I come
to a place that either needs work, change, or is just a short-term patch for a
problem that needs more attention.  This is a helpful way to get a change in
place that works, but is not fully complete.  It is a way of acknowledging that
sometimes we do things for an immediate fix, or because an idea is not fully
implementated, or that we lack all the information we need to accomplish a
task, and will need to resolve it more fully later.  Noting when we are doing
this in the code makes for better robust code later as those kinds of changes
will not become a part of a working, final release.

There are other issues that I'm sure we'll want to consider, but that's all
come to mind right now.  Well, not true, but that's all I want to talk about.
;-)

Tim, is this the kind of information that can be folded into the FAQ, perhaps
something under the Software section?  I don't think I've mentioned it before,
but a FAQ was an excellent idea and really helpful for new people coming on
board.  Combined with Michal's notes, I can see this being a valuable resource.
 Perhaps it should be checked into CVS complete with revision history so that
other's can add to it?  Do you have aspirations of being the local
Documentation/Tech Writer?  Pretty please? :)

Dave.

Re: [Openeeg-list] Re: modular eeg work report

[Dave F. <df...@po...>]

[crossposted to both Yahoo and Sourceforge list, please respond on Sourceforge
openeeg-list]

On Thu, 11 Jul 2002 21:14:14 +0100, Jim Peters wrote:

>I wonder how many of the 347 people subscribed to the old list will
>make it over ?  Perhaps posting occasional teasers to the old list
>(saying "There is a good discussion of so-and-so on the new list")
>might get more people to move.

Well, I was scratching my head until this morning because I read those
"teasers" on the Yahoo discussion list and still saw no new messages in my
local OpenEEG mail folder.  Then I realized that I forgot to set up a filter
for my mailer and all the openeeg-list messages were being caught by my SPAM
filter.  Oops. :)  A couple of key-clicks later and I'm here.

Also... <trumpet fanfare>, I will be checking in an alpha version of source
code for all to play with.  More on that later.  For now, here is a teaser from
the README (hopefully the margins for my mailer will not butcher it *too*
badly).  This will change just a bit since it combines what will be two
branches (library and application) and I'll split it into two README's, but
otherwise will remain the same.

                        OpenEEG Biofeedback SDK Library

    Description:

    The OpenEEG Biofeedback SDK Library provides a data transport system
    for one or more biosensory devices, such as EEG, GSR, EMG, etc.
    devices.

    License:

    This program is free software; you can redistribute it and/or modify
    it under the terms of the "Artistic License" which comes with this
    library.

    This library is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    Artistic License for more details.

    You should have received a copy of the Artistic License with this
    library, in the file named "Artistic".

--------------------------------------------------------------------------

Program documentation can be found in the 'doc' directory.  Specifically,
load 'doc/html/index.html' in a browser.  This documentation was generated
by Doxygen from the OpenEEGlib source code.

General Overview

There are two primary aspects to the use and control of devices -- the
BioDevice object itself, and the Data Processing Node Network.  Once
a device object is created, it can be registered with the DP network.
Any other data producing and/or processing class can also register
with the node network, thus creating a series of dependent input-output
linked relationships.

An example of the use of this framework can be found in biotest.cpp.  This
program illustrates the use of the 'node network' as well as the creation
of a device and a data monitoring class.

A UML diagram of the classes can be found in the file "openeeglib.gif".

--------------------------------------------------------------------------

Linux Compilation Instructions

In order to compile, you will need to install the following libraries in
the following order:

GTK+ 1.2               : http://www.gtk.org (compile first glib and then gtk+)
TIFF                   : http://www.libtiff.org
wxWindows/GTK 2.3+     : http://www.wxwindows.org

If you want symbolic debugging information in any of the above libraries, use
"./configure --enable-debug" when you build them.  

    Note: for development purposes, it may be prudent to compile
    wxWindows/GTK with "--with-gtk --disable-no_rtti --disable-no_exceptions"
    and/or "--enable-gtk2" if GTK 2.x is used.  As of 7/10/2002, GTK 2.x has 
    not been tested with OpenEEGlib.

Then, simply run "makeall" in the ./src directory.

In order to test, run "src/app/biotest" for a console test, or "src/app/biomon"
for a GUI monitoring application.

Note: this has been tested using g++ 2.95.  g++ 3.0 may work, but has not
been tested.

Compile command line options:

The following macros should be defined, which can accomplished by passing
them to g++ on the command line:

    -D_REENTRANT -D_THREAD_SAFE -DDEBUG (the latter for development releases)

Also, make sure that you use the same flags used for wxWindows for OpenEEGlib.
This can be ensured under Linux by passing `wx-config --cxxflags` to g++ 
under Linux.

--------------------------------------------------------------------------

Linux Tweaks

It may be necessary to increase the priority of your serial port (if you
are using a serial BioDevice.  Use irqtune (http://cae.best.vwh.net/irqtune)
to accomplish this.  First, attach a running device to the serial port,
run "irqtune -n -o" to get the IRQ number of the port, then run:

    irqtune nn

where 'nn' is the IRQ number of the serial port.  This can be added to the
initialization of the system at boot time using update-rc.d.

Another performance increase may result from turning DMA transfers on for
your IDE interface.  Use the utility program "hdparm" for this.  For example:

    hdparm -d1 /dev/hda

will turn on DMA transfer for /dev/hda if the IDE interface supports it.

--------------------------------------------------------------------------

ADDING NEW DEVICES

The following are the steps to follow in order to add a new device.

1.  Create the device class by inheriting BioDevice.  You will need to
    implement the two pure virtual functions BioDevice::ReadData() and 
    BioDevice::WriteData() and wxThread::Entry() (and 
    wxThread::OnExit() if wanted).

2.  Add new BioUnits, if any.  Add new BioUnit to biounit_enum and
    biounitlist[] in biosysinfo.cpp.

3.  Add new BioDataTypes, if any.  Add new BioDataType to biodatatype_enum
    and biodatatypelist[] in biosysinfo.cpp.

4.  Add the device entry to openeeglib.conf configuration file.

That's it!  If you are also going to add the device to BioMon, the
monitoring test application, then you will also want to do the following:

[FIXME:  this information is not completely accurate as the BioMon
app is going through revisions which will effect this.  df, 7/10/2002]

1.  Create wxDialog box for the specific setup/configuration of the 
    device.  See biomongui.h/cpp and biomongui_wdr.h/cpp.  I used
    wxDesigner to create the dialog boxes; hence the "wdr" wxDesigner's
    resource files.

2.  Add call to setup configuration dialog box call to
    DlgDeviceSelect::OnSetup().  See biomongui.cpp.

--------------------------------------------------------------------------

Configuration File

The OpenEEG library makes use of a configuration file that contains
specific device information for various biofeedback equipment.  The name
of the file is "openeeglib.conf" on both unix and MS Window systems.  It
is usually located in the installed system directory for the program.
However, it can also be stored in alternate locations by defining the 
environment variable OPENEEGLIB_SYSPATH.

Right now during development, the OPENEEGLIB_SYSPATH will be checked, and
if that is not defined, the current directory will be searched.  This
should probably change -- see biosysinfo.cpp for more information
concerning the location of the configuration file.

--------------------------------------------------------------------------

TO DO's and Limitations

+   This list needs to be updated and is not complete.

+   Need a file class in order to read data from disk, and not just
     the serial port.

+  Need to be able to index forward and backwards through data stream
    for playback/record functions.

+  Need a "control channel" which will handle information such as
    battery level of encoder, serial number, operating mode, etc.

+  Need DSP filters

+  Need a packaging system (such as automake/autoconf).

--------------------------------------------------------------------------

Re: [Openeeg-list] Re: Vol 1 #4 - mail delivery

[Jim P. <ji...@ua...>]

Andreas Robinson wrote:
> > I vote to not have HTML copies of plain text msgs sent to the list.
> 
> Hmm, I guess that HTML is not filtered and cleaned up here which is
> bad because there are a lot of people that send HTML-mails without
> even knowing. We could use a filter that either makes mails
> beginning with <HTML> bounce, or reduces them to plain text. I'll
> send a mail about it to Sourceforge admin - it should not be hard
> for them to implement... if they have time...

I think the problem is that many E-mailers send multipart/alternative
sections by default -- i.e. two sections, plain-text and HTML.  My
mail-client (mutt) ignores the HTML alternative, but I guess some
mail-clients don't, and display both.  Really it is up to the original
sender to turn off the HTML alternative (or the recipient to use a
client that understands multipart/alternative).  I don't think that
Yahoo is any better -- I managed to find several messages on the old
list with exactly the same problem.


Just one thought -- SourceForge now once again lets you turn on
Reply-To headers in the Admin section (I've just turned them back on
for my SBaGen list).  This subject generates some (heated) debate, but
I personally prefer the Yahoo-like default of having them turned on
for a closed list.

For lists that are open to non-subscribers and get a lot of
cross-posted discussions, it makes less sense.  But perhaps it would
be good to turn them on for this list ?  This means that the list adds
a Reply-To field containing the list address to each message, so that
people hitting 'reply' have their reply sent back to the list by
default.  (Otherwise they have to always use 'reply-to-all').

Personally, I can live with either option if you want to use
SourceForge's default --

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                 ji...@ua...
                          (_)  /=\  ~/_  (_)
 Uazú                  (_)    /=\    ~/_    (_)                http://
 B'ham, UK          (_) ____ /=\ ____ ~/_ ____ (_)            uazu.net

[Openeeg-list] Re: Vol 1 #4 - mail delivery

[Andreas R. <and...@st...>]

JBilderback wrote:

> I vote to not have HTML copies of plain text msgs sent to the list.

Hmm, I guess that HTML is not filtered and cleaned up here which is bad because there are a lot of people that send HTML-mails without even knowing. We could use a filter that either makes mails beginning with <HTML> bounce, or reduces them to plain text. I'll send a mail about it to Sourceforge admin - it should not be hard for them to implement... if they have time...

> I have mixed feelings about attatchments ... are there no other alternatives?

Sorry about the big file... I looked everywhere on SF to find a place to unload it. Yahoo has 20 megs of space for files but SF only offers space for the project itself (homepage, source code etc). They used to have a "multimedia-file" section, but I could not find it now.

I guess we have a problem or two ... Suggestions?

> It appears the post office will fly a pound from US to most of europe
> for under $10. I suppose I'd be willing to trans ship if that sort
> of thing proved useful and a substantial savings.

Thats very kind of you. Hopefully we will never have to do it that way. Europeans must be able to find everything in Europe, americans in the US, etc. The PCB's from Olimex in Bulgaria are shipped worldwide for about $8, so they pose no problem.

/Andreas

[Openeeg-list] Re: Vol 1 #4 - electrodes etc.

[JBilderback <ji...@hu...>]

I vote to not have HTML copies of plain text msgs sent to
the list.

I have mixed feelings about attatchments ... are there no
other alternatives? (wading thru a digest where the posters have
left 5 previous replies attached and unediited can be challenging
enough without the addition of 80k attachments. OTOH ... they
are easier to spot and skip)

> 
> * Finally, these electrodes look pretty cheap ($18 for 100 pieces, AgCl on plastic), though I can't > vouch for the quality or anything: http://www.electrodestore.com/EEG/EEG-p13.html (Jim, shipping to > Europe is about $30 for a one-pound package - I asked them)

It appears the post office will fly a pound from US to most of europe
for under $10. I suppose I'd be willing to trans ship if that sort
of thing proved useful and a substantial savings.

The Hal project has some low cost electrode design info ... using
button snaps to hold electrodes, etc.

Re: [Openeeg-list] Hello! Found you guys today!

[Andreas R. <and...@st...>]

Hi David (and everyone else who is new :o)

Jim Peters answered some of your software questions, so I'll have a go at the hardware ones.

Since you have a really nice daq-board, your next step is to buy or build the signal conditioner. We are still in the process of building and testing the first prototypes for EEG. (Actually, right now I'm just waiting for the PCB to arrive from the manufacturer...)

If you can solder, you can get yourself a piece of veroboard and some parts and build your own amplifier, for maybe $30 for two channels. I've attached a pdf with the schematics. (Does this list accept attachments? I guess we shall see...) It is not entirely tested for weak spots (offset handling etc) and you may want a low-pass filter, but just for testing it should be ok as it is.

Btw, I'm pretty certain you must put it in a metal box, and shield the electrode cables, or you will only see 50/60Hz hum rather than EEG. The work-report from Chris a few days ago, hints at that. I hope he has time to try some fixes, and report back to us how it went.

* The Awakened Mind is sold used (although the book I got looked brand-new) at Amazon. Just search for "C. Maxwell Cade". There are some technical details there, and some descriptions on what they did and how they did it (technology-augmented meditation that is). Hmm, it appears the price has gone up.

* Another book, "A Symphony in the Brain" by  Jim Robbins gives an introduction and some history and people of the field of clinical biofeedback.

* Some information about bioamplifiers (for electrical engineers...): http://www.biosemi.com/publications.htm It's a gold mine if you want to design amplifiers.

* A FAQ. Yes somewhere... Tim Nelson is the maintainer if I remember correctly... I don't have his mail address, so if you're listening Tim, it's time to post it here I think. :)

* Michal Wallace did an excellent job of going through the archives and summarized what he found. I hope it finds its way into the FAQ somehow (a large task!). http://groups.yahoo.com/group/buildcheapeeg/message/2872

* Dave Fisher is still working on some details he wants done, but I expect we will have an alpha-version of the software checked into CVS before long.

* Finally, these electrodes look pretty cheap ($18 for 100 pieces, AgCl on plastic), though I can't vouch for the quality or anything: http://www.electrodestore.com/EEG/EEG-p13.html (Jim, shipping to Europe is about $30 for a one-pound package - I asked them)

Well, thats it for now.

Regards,

Andreas

Re: [Openeeg-list] Hello! Found you guys today!

[Jim P. <ji...@ua...>]

David Horner wrote:
> I have been trying to get a Bio-Feedback system together myself.  I
> am happy to hear there are other people working on a free and open
> system!  I am a software engineer and have just purchased a
> expensive PCMCIA data aq. card from NI.  I would like to help in the
> efforts for the free Bio-Feedback software.
> 
> I need to get my self a test system up and running.  Right now I
> just have the data aq. card.
> (http://sine.ni.com/apps/we/nioc.vp?cid=4371&lang=US) I am looking
> for a good place to aquire electrodes and whatever else I might
> need.  I am also looking for good books (can you suggest some)?  Can
> someone point me in the right direction?  Is there an FAQ for this
> group?

I'm not the right person to answer most of these questions, but I
thought someone should answer.  At the moment, we are moving everyone
off an old eGroups list to this new SF list, so not everyone is here
yet to answer your questions.

There are a few hardware guys who have been working on several designs
for the circuitry, based on feeding the data in through the serial
port.  The big problem is isolation -- there should be no current path
between your body and ground via the electrodes, otherwise touching an
accidentally live case would cause discharge to ground through the
worst possible path -- i.e. hand -> brain -> electrodes -> PC ->
ground.

They are using an optical coupling to achieve this.  However, if you
are doing things in your own way, using a PCMCIA card, and you are
willing to take a risk, or run the laptop off batteries and make sure
there are no other connections to anything grounded, you could perhaps
use the signal amplifier stages of the circuits that they have been
working on.

One of the circuits (ModularEEG) is in the trial-production stage.
Andreas is the one to talk to about this.

On books, Jim Meissner suggested "The Awakened Mind" by Max Cade, but
that appears to be unavailable, and I have not yet looked on the
second hand sites for a copy.

On software, so far we have had quite a bit of discussion, and Dave
Fisher is working on a C++ framework, which he has working at a basic
level with his ProComp hardware.

I did some work on the signal analysis a while back, and ended up with
BWView, designed to quickly get a visual understanding of brain-wave
files.  The analysis is much much better than the normal FFT approach,
but takes more processing power, and is only really suited for
analysis after the data has been recorded.

  http://uazu.net/bwview/

On electrodes, someone else will have to answer.  It really depends on
where you are based.  In the UK people seemed to almost assume I was a
terrorist or something, asking for electrodes without a medical
background.  I may have another go soon.  In the US and Germany I
think there are sites to get hold of them much more easily.

I hope this will do until we get some more people over to this list.

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                 ji...@ua...
                          (_)  /=\  ~/_  (_)
 Uazú                  (_)    /=\    ~/_    (_)                http://
 B'ham, UK          (_) ____ /=\ ____ ~/_ ____ (_)            uazu.net

[Openeeg-list] Intro

[jjgrps <jj...@ya...>]

Hi all,

I've been threading my way through all of the groups
related to the openeeg project, starting with

http://home.earthlink.net/~wearable/biopsy/

and including the various sourceforge and yahoo groups
and so on.  Its a bit confusing right now; for
instance, I can't tell if this email list corresponds
to the yahoo groups lists, or if the (soon to be
defunct?) yahoo group postings correspond to the
sourceforge messages, or what, but anyway I'm having a
good time and seem to have figured out at least a few
things about the openeeg project.

I'll post some of my observations and especially
questions in another email, for now I just wanted to
say hello and see if this is the place to post!

Later,

John

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

[Openeeg-list] Hello! Found you guys today!

[David H. <dh...@me...>]

Hey,

    I have been trying to get a Bio-Feedback system together myself.
I am happy to hear there are other people working on a free and open =
system!
I am a software engineer and have just purchased a expensive PCMCIA
data aq. card from NI.  I would like to help in the efforts for the free =
Bio-Feedback
software.

I need to get my self a test system up and running.
Right now I just have the data aq. card. =
(http://sine.ni.com/apps/we/nioc.vp?cid=3D4371&lang=3DUS)
I am looking for a good place to aquire electrodes and whatever else I =
might need.
I am also looking for good books (can you suggest some)?
Can someone point me in the right direction?
Is there an FAQ for this group?

Thanks,

Dave

[Openeeg-list] Final comments on buildcheapeeg (cross-posted)

[Timothy S. N. <wa...@sm...>]

Two final comments:
1.	I still think multiple lists are valuable.  openeeg-hw, openeeg-sw,
	openeeg-releases (exists), and openeeg-users.  *But*, I think that
	openeeg-list should be subscribed to all of them.  Because once I have
	the hardware myself, I'm mostly going to be interested in the software
	(so I'd subscribe to the sw list).  But until then, I want everything,
	so I am subscribed to the openeeg-list.
2.	I think we should post a final comment on this forum saying where
	we've moved to, and hopefully someone will still keep an eye on it to
	redirect newcomers.
3.	Hopefully between my FAQ and Michal's notes, I'll be able to develop
	an even better FAQ, and maybe be able to post it on sourceforge.  When
	I get time :).

	:)


---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wa...@sm... | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.1
GCS d? s: a-- C++>++++$ US+ P++ L++ E- W+++ N+ w+> M-- V- Y+>++ 
PGP->++ R(+) !tv B++ DI++++ D+ G e>++ h!/* y-
-----END GEEK CODE BLOCK-----

Re: [Openeeg-list] Re: modular eeg work report

[Jim P. <ji...@ua...>]

Andreas Robinson wrote:
> a) Switch to shielded cables.

This is something that Jim-M mentioned some time ago.  In his design,
he had no 50Hz filtering at all, and he had each electrode cable
individually shielded right up to the electrode (i.e. to within
millimeters of it).

If/when I try and get my crude EEG circuit working again (with proper
electrodes this time) that I what I plan to try.  After all, the less
50Hz we get into the system the better.  Jim-M did very well with his
recordings.


> If not, there are at least two other people here to help you; Jörg
> and Jim Meissner (though neither has subscribed to this list yet.)

I wonder how many of the 347 people subscribed to the old list will
make it over ?  Perhaps posting occasional teasers to the old list
(saying "There is a good discussion of so-and-so on the new list")
might get more people to move.

We'll see ...

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                 ji...@ua...
                          (_)  /=\  ~/_  (_)
 Uazú                  (_)    /=\    ~/_    (_)                http://
 B'ham, UK          (_) ____ /=\ ____ ~/_ ____ (_)            uazu.net

[Openeeg-list] Re: modular eeg work report

[Andreas R. <and...@st...>]

Hi Chris,

I read a bit about interference ...

http://www.biosemi.com/publications/artikel3.htm

First of all, the 50Hz interference is lower when there is no isolation to power ground - which explains why it starts working when you touch GND1, but not when you touch analog ground. However, for safety reasons, we can't use that method... :-p

Second, shielding the cables is very important - they pick up a lot of interference - so try fixing that first. You may have to use the metal box again, too.

Third, if the DRL is not working (this is really Jörgs territory - have you mailed him about it? He's a bit busy so he might not reply right away) you must connect an electrode to (virtual) ground (VREF/2) instead, or else you won't have any ground reference whatsoever.

About that 100uF capacitor: forget I mentioned it - it probably won't do much good. At first I thought your problem was related to high impedance in the battery, but now I think it has more to do with shielding...

A couple of remarks about the design:

Guarding was excluded in an effort to keep the design simple. There are EEG circuits that work without guarding, so we assumed it should work for us as well, particularily with the DRL. If we can't get your board to work correctly, we may have to rethink.... (A guard driver can be patched into your board so don't worry that you have to rebuild the whole analog PCB - I'll draw a patch-board for you.)

About the second 7805 in the new version of the digital board: The idea is to replace the DCDC converter with two batteries, for those who want to, and save the expense of the DCDC converter ($10). That is why the second 7805 and the DCDC converter should not be used at the same time. Since you already have a DCDC converter, you can ignore this completely.

> does this mean to zero the 50Hz-bin in the fft and retransform to time-scale
> ? could such signal processing be done 'on-the-run' at the avr  ?I'm heaviliy

Well, I was thinking about a IIR-filter (compare with FIR...) that runs on the PC and operates in the time-domain, not frequency domain.  However, in this case, it looks like the amplifiers are saturated with the 50Hz signal. No amount of digital filtering can get rid of that.

So for starters, try this, in order

a) Switch to shielded cables.
b) Add metal shielding for the whole amplifier board.
c) Disconnect the DRL electrode from the DRL-amplifier and connect it to virtual ground instead. Perhaps you can use a switch (make sure it is shielded) so that you can change between DRL and GND easily. That way it becomes easy to determine wheter the DRL works or not.

I really hope this helps... :-)
If not, there are at least two other people here to help you; Jörg and Jim Meissner (though neither has subscribed to this list yet.)

Regards,

Andreas

[Openeeg-list] Re: [buildcheapeeg] Re: Goodbye Yahoo?

[Jim P. <ji...@ua...>]

Jim Peters wrote:
> Alternatively, maybe we could start with "openeeg-hw", and split off
> software discussion into "openeeg-sw" or "openeeg-dev" at some later
> point.

I notice that someone has already setup 'openeeg-list' on sf.net.  Is
this our new list ?

  http://sf.net/projects/openeeg
  http://sf.net/mail/?group_id=35817

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                 ji...@ua...
                          (_)  /=\  ~/_  (_)
 Uazú                  (_)    /=\    ~/_    (_)                http://
 B'ham, UK          (_) ____ /=\ ____ ~/_ ____ (_)            uazu.net