openeeg-list — Public forum for everyone

Re: [Openeeg-list] Yahoo archive extracted successfully

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

Jim Peters wrote:
> Where are we going to host all this data, by the way ?  Once expanded
> into HTML, it is likely to be much bigger than 28MB.  Or was the idea
> just to get it off Yahoo's server for safe-keeping ?

Okay, Moritz gave me access to the site, and I've uploaded all the
HTML for the 'buildcheapeeg' list archives (which I generated using
hypermail):

  http://openeeg.sf.net/arch/

The results from hypermail look pretty good to me.  For instance, if
you click on [attachments] on the front page, you can see all the
attachments that have been posted over the entire life of the list.

In the end it took about 35MB of space (out of the 100MB we apparently
have on SF).  I still have the original MBox file if we need to
regenerate the HTML.

Any problems with this, let me know --

Jim

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

Re: [Openeeg-list] Considerations

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

Dave Fisher wrote:
> But it is important to give non-free developers the incentive to
> contribute to free-based work.  Thus, it would behoove all
> developers using a library to make sure that the library is solid
> and robust since it is a foundational aspect of their project.

Agreed.

> LGPL seemed to strike the balance that I was looking for, except for
> my fuzziness with Section 6 of the license
> (http://www.gnu.org/copyleft/lesser.html) where it states:
> 
> From Section 5:
> 
> However, linking a "work that uses the Library" with the Library creates an
> executable that is a derivative of the Library (because it contains portions of
> the Library), rather than a "work that uses the library". The executable is
> therefore covered by this License. Section 6 states terms for distribution of
> such executables.
> 
> From Section 6:
> 
> As an exception to the Sections above, you may also combine or link a "work
> that uses the Library" with the Library to produce a work containing portions
> of the Library, and distribute that work under terms of your choice, provided
> that the terms permit modification of the work for the customer's own use and
> reverse engineering for debugging such modifications.
> 
> So, let's say that you use OpenEEGlib to create a "work that uses
> the Library" (call it Project A) and that this work does not use any
> other open-source code.  Let's also say that Project A links to a
> run-time sharable version of the library.  My question is twofold:
> 
> 1) What needs to be made available to the customer in order to
> reverse engineer Project A (source code?  executable only? object
> modules?), and

I think "executable only" if it is linked to a shared library --
because it's not called 'reverse engineering' if you already have the
source!  I think the restrictions in this part of the LGPL are about
stopping people putting a licence clause in forbidding reverse
engineering of the executable.  They don't have to do anything to help
you reverse engineer it -- just not forbid it.  I think this is to
make it possible to legally run 'gdb' and figure out why the
executable doesn't work properly with the latest version of the shared
library, for instance.

> 2) Does the executable and/or object modules for Project A need to be
> made publically available to anyone to satisfy the LGPL?

No -- it says that you can 'distribute that work under terms of your
choice' -- i.e. for a fee, privately, under restrictive NDA licences,
or whatever you like, so long as you permit the reverse engineering /
debugging stuff to the individual users who have purchased your
executable.  

> I'm not sure if I am just not "getting it" or if it is, indeed, a
> fuzzy area open to interpretation.

I think it is just unclear to normal people because it has been
translated into legalese.  Also, it's not entirely clear what the
background intention of some of the requirements were (e.g. the
reverse engineering thing).

If you want to make these kinds of details clearer to non-free
developers, you can do what Larry Wall has done with Perl, and just
list a number of situations along with your interpretation of how the
licence applies to them in order to make developers feel happier.
(Also, some software adds 'exceptions' to the basic licence -- for
example, the Linux kernel is GPL-protected, but with an 'exception' to
clarify that making system calls to the kernel does not by itself
cause your app to fall under the GPL).

Also, note that Linux libc (which provides all the standard C library
calls, POSIX calls, and so on for Linux apps) is LGPL-protected.  So
just about any software that currently runs on Linux (commercial or
non-commercial) has already accepted those section 5/6 LGPL
restrictions.

Jim

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

Re: [Openeeg-list] Considerations

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

On Tue, 23 Jul 2002 22:47:43 +0100, Jim Peters wrote:

I have been out-of-town, but wanted to reply to this.

>Andreas Robinson wrote:
>> in anticipation of a reply from Dave, I have added LGPL to the list,
>> so that all views are expressed on the SF-page. For me, the license
>> is not terribly important so I'll keep modifying it until you agree
>> on something....SF lets us keep six different licenses at the same
>> time, so everyone can use what they like. :) However, I think we can
>> all agree on not using straight GPL, because it is difficult to use
>> commercially?
>
>My own personal preference is to use the GPL for apps, and the LGPL
>for libraries -- that was the original intention of those licences.
>That way no-one could take our app code and close-source it as a
>proprietary version, denying us access to their changes and
>improvements.  However they *could* link their own closed-source
>applications with our LGPL'd libraries without problem.

This has been a fuzzy point for me.  What I am striving for is a balance
between protecting the open-source code and yet making non-free use of that
code possible.  I do not want to give a commericial enterprise the ability to
take and absorb that open-source code.  I was not happy with MPL because it
seemed to make this possible, and yet I was not happy with GPL because it make
commercial use impossible.  Understand that I am no fan of the corporate world
(which is why I left it years ago), but yet I do appreciate that we live in a
capitalistic economy which is less than generous and understands nothing about
cooperative sharing.  I, as well as others, need to find a way to exist in this
system while at the same time transforming it.  I appreciate GPL as being a
step in that transformation process, but it cannot yet be fully realized.  But
it is important to give non-free developers the incentive to contribute to
free-based work.  Thus, it would behoove all developers using a library to make
sure that the library is solid and robust since it is a foundational aspect of
their project.  LGPL seemed to strike the balance that I was looking for,
except for my fuzziness with Section 6 of the license
(http://www.gnu.org/copyleft/lesser.html) where it states:

From Section 5:

However, linking a "work that uses the Library" with the Library creates an
executable that is a derivative of the Library (because it contains portions of
the Library), rather than a "work that uses the library". The executable is
therefore covered by this License. Section 6 states terms for distribution of
such executables.

From Section 6:

As an exception to the Sections above, you may also combine or link a "work
that uses the Library" with the Library to produce a work containing portions
of the Library, and distribute that work under terms of your choice, provided
that the terms permit modification of the work for the customer's own use and
reverse engineering for debugging such modifications.

So, let's say that you use OpenEEGlib to create a "work that uses the Library"
(call it Project A) and that this work does not use any other open-source code.
 Let's also say that Project A links to a run-time sharable version of the
library.  My question is twofold:

1) What needs to be made available to the customer in order to reverse engineer
Project A (source code?  executable only? object modules?), and

2) Does the executable and/or object modules for Project A need to be made
publically available to anyone to satisfy the LGPL?

I'm not sure if I am just not "getting it" or if it is, indeed, a fuzzy area
open to interpretation.

Dave.

Re: [Openeeg-list] ModularEEG update and firmware request

[Joerg H. <in...@jh...>]

Hi,

Andreas Robinson wrote:
 > Hi all,
 >
 > here's an update from the "hardware department".
 >
 > I have now a set of assembled, but so-far untested ModularEEG PCB's on=
 my workbench. There were two layout bugs, one
 > serious

What has it been ?

 > and one not, and a part was missing from the parts list. I also forgot=
 to order BC557's (a transistor) but
 > other than that, everything is ok so far. :o)
 >
 > I have a request for J=F6rg and/or Chris: I need some firmware to down=
load into the microcontroller. Do you have
 > anything that is working?

Because the modularEEG is 99% firmware compatible with the RS232EEG you c=
an
use the firmware in "RS232EEG_release010226.zip" on www.jhansmann.de/eeg

In the zip-file you find instructions about flashing:

"flashing the firmware _010601.txt"

and the firmware (c-sources and hex-file) itself
in a further zip-file "firmware001214.zip"

What you need is the "EEG02.rom" file and the SP12 programming tool.
If you want to recompile you also need a AVRGCC compiler.
(BTW: Chris had mentioned that that for the recent AVRGCC some patches
in the sources were required)

BTW2:
In the RS232EEG-firmware misses the generation of the calibration signal.=


 > The source + a compiled HEX file would be nice. A test program for the=
 PC to go with that
 > would be even nicer.

Rob Sack's Electric Guru is compatible with the RS232EEG / modularEEG ser=
ial
protocol.
You can (hopefully still) download it from
www.realization.org

 > Testing is going to be... interesting, as I don't have an oscilloscope=
 available right now.
 > On the other hand, it
 > puts me in the same position as most people...

Wish you success !


Regards,

Joerg

[Openeeg-list] ModularEEG update and firmware request

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

Hi all,

here's an update from the "hardware department".

I have now a set of assembled, but so-far untested ModularEEG PCB's on my workbench. There were two layout bugs, one serious and one not, and a part was missing from the parts list. I also forgot to order BC557's (a transistor) but other than that, everything is ok so far. :o)

I have a request for Jörg and/or Chris:
I need some firmware to download into the microcontroller. Do you have anything that is working? The source + a compiled HEX file would be nice. A test program for the PC to go with that would be even nicer.

Testing is going to be... interesting, as I don't have an oscilloscope available right now. On the other hand, it puts me in the same position as most people...

Regards,

Andreas

Re: [Openeeg-list] Considerations

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

Andreas Robinson wrote:
> in anticipation of a reply from Dave, I have added LGPL to the list,
> so that all views are expressed on the SF-page. For me, the license
> is not terribly important so I'll keep modifying it until you agree
> on something....SF lets us keep six different licenses at the same
> time, so everyone can use what they like. :) However, I think we can
> all agree on not using straight GPL, because it is difficult to use
> commercially?

My own personal preference is to use the GPL for apps, and the LGPL
for libraries -- that was the original intention of those licences.
That way no-one could take our app code and close-source it as a
proprietary version, denying us access to their changes and
improvements.  However they *could* link their own closed-source
applications with our LGPL'd libraries without problem.

There only reason the GPL is 'difficult to use commercially' is
because business people don't like giving their work away for free!
They seem to forget that they are getting the original GPL'd code for
free, though.  If a business is willing to release their changes to
the code also under the GPL, then there is no problem at all with them
using the code commercially.  They can even sell it!  The GPL has no
problem with people making a profit.

Less restrictive licences than the GPL (including the LGPL) are good
only in that they allow people to use the open-source code alongside
code under a *much more* restrictive licence (e.g. closed-source
commercial code).  It depends on how generous you are feeling towards
people who don't want to share their code with you.  The ultimate
'free' licence, of course, is "public domain", which means they can do
anything they like with your code.  I don't think anyone here is
feeling *quite* that generous.

I guess there are also pragmatic reasons for some of the other non-GPL
licences too -- such as trying to operate in an environment where the
software would simply not be used unless it was friendly to closed-
source developers, or unless it was compatible with other licencing
strategies that were already in place.

As they say -- the choice of a licence is not a step to be taken
lightly.  I think it is important to be clear about the implications
of some of these choices, and to clear up any misconceptions.


> Btw, thanks for downloading the yahoo archive! Since we don't have
> anywhere to put it right now, please hold on to it. Yahoo will keep
> buildcheapeeg available for 6 months, so there is no hurry to put it
> up somewhere else.

I'm talking to Moritz off-list -- it should be possible to put it all
up on the SF site fairly soon.

Jim

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

Re: [Openeeg-list] Considerations

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

Hi Jim,

in anticipation of a reply from Dave, I have added LGPL to the list, so that all views are expressed on the SF-page. For me, the license is not terribly important so I'll keep modifying it until you agree on something....SF lets us keep six different licenses at the same time, so everyone can use what they like. :) However, I think we can all agree on not using straight GPL, because it is difficult to use commercially?

Btw, thanks for downloading the yahoo archive! Since we don't have anywhere to put it right now, please hold on to it. Yahoo will keep buildcheapeeg available for 6 months, so there is no hurry to put it up somewhere else.

Regards,

Andreas

PS. This is a must-read for any programmer, just don't do what it says. (that's why it is a must-read)
http://mindprod.com/unmain.html
DS

Re: [Openeeg-list] Considerations

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

Dave Fisher wrote:
> I was looking at the MPL 1.1 license earlier and saw that they had a similar
> clause except that it is a "tri-license" (for MPL/GPL/LGPL) which states:
> 
>  * Alternatively, the contents of this file may be used under the terms of
>  * either the GNU General Public License Version 2 or later (the "GPL"), or
>  * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
>  * in which case the provisions of the GPL or the LGPL are applicable instead
>  * of those above. If you wish to allow use of your version of this file only

Well, if you are giving people the option of both the GPL and LGPL,
you might as well just say "LGPL", because that is simply a less
restrictive version of the GPL.  (We don't have the tens of thousands
of source files that the Mozilla project has to worry about, which is
one of the reasons they give for preferring to specify both).

I was just looking on the SourceForge site, and I noticed that someone
has put the MPL up as the licence for the whole project.  "Oh no!!", I
thought.  This is the worst possible idea.  If you say "Mozilla Public
Licence" to many open-source people they immediately think
"ill-conceived/broken/problematic licencing strategy, non-GPL
compatible, etc, etc".

If we are going to dual/triple licence things, can we make sure that
all the possible licences are listed on the SourceForge site, or
otherwise we might end up putting off potential developers.

My own feeling is to respect people's choice of licences, so long as
it doesn't cause major problems.  However, for myself I would use GNU
licences, and then review the situation later if someone found a
commercial application for the code that clashed with that.  It is
possible to relicence the code later so long as all the authors can be
contacted.

People have used the GPL before for the very reason that it *is*
incompatible with closed-source business use.  For example, FFTW
(www.fftw.org, a very fast FFT engine, used in BWView) was only
released under the GPL because this would not upset the existing
revenue stream for business FFTW licences for MIT (who own the FFTW
copyright).  So FFTW is free for GPL apps (and any other open-source
software with a GPL-compatible licence), but non-free code has to pay
to use it.

(Incidentally this licencing of FFTW will in fact immediately disable
the MPL option of any triple-licenced code in our project if we choose
to link with FFTW, as the MPL is not GPL-compatible).

Taking a strong GPL-only approach, as in FFTW, if some business wants
to use the openEEG code without releasing their own source code, we
could allow them to do so in exchange for some kind of sponsorship or
support for the project.  That is one of the things the GPL (and
perhaps LGPL in a few cases) would give us.  (They would have to pay
to licence FFTW in any case, if we used that library.)

Well, that is an option at least.  I'm not actually suggesting we
should take such a strong GPL-only 'free software' stance, especially
if people are uncomfortable with that -- I'm just pointing out the
range of possibilities and choices.

I think a combination of GPL and LGPL has worked well enough for many
projects in the past.  If people really want to be more permissive in
their licencing terms in advance, perhaps it would be better to choose
one of the more relaxed GPL-compatible licences (rather than using the
incompatible MPL).  I have a lot of respect for Larry Wall -- so I was
happier when we were discussing using one of the more recent Artistic
licences (i.e. a GPL-compatible one).


Anyway, for now the most important thing for me is to make sure the
MPL isn't listed as the *only* licence for the project.

I hope I'm making sense ...

Jim

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

[Openeeg-list] Yahoo archive extracted successfully

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

Okay, I now have all the messages from the Yahoo buildcheapeeg list in
MBox format.  I found a better script than the one mentioned before,
called 'yahoo2mbox' (do a Google search to find it), which picks up
the attachments and also fixes as many of the Yahoo-scrambled E-mail
addresses that it can (although it required a little hacking to get it
to work fully).  It does this based on being given some example
E-mails from which to strip valid addresses, and I fed it all of the
1600 or so messages I have accumulated since I've been subscribed to
the list.  So anyone who has posted since Sept 2001 will have valid
addresses, otherwise they will still be Yahoo-scrambled (e.g. in the
form <e_e_ling@h...>).

The file is 28MB uncompressed, or 13MB gzipped.  Next thing is to use
some tool to convert this into a bunch of web-pages with indexes and
thread links and so on.  I'm sure I could find some Linux-hosted app
to do that, but does anyone else have any experience with this or
favourite tools ?

Where are we going to host all this data, by the way ?  Once expanded
into HTML, it is likely to be much bigger than 28MB.  Or was the idea
just to get it off Yahoo's server for safe-keeping ?

If someone wants a copy of this, give me somewhere I can FTP it to,
and it's all yours!  (I can also ZIP it if you prefer).

Jim

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

Re: [Openeeg-list] What kind of shield for cable?

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

Hi John,

> But the artikel3 also mentions that the signal wire in
> each of the inputs can pick up mains, too, and that
> this is trickier to get rid of.  For one, they claim
> that the DRL circuit can be unstable (how?) if the
> electrode wires have grounded shields.  

That is because capacitive loading (as in shielding) increases the phase shift in the circuit. I'm a bit hazy on the details of control-theory (Jörg's the wiz), but basically you can cause the circuit to oscillate if the phase shift is greater than 180 degrees at a frequency where the gain is 1.0 or greater. That's actually how an oscillator works: you have an amplifier fed to its own output, with a 180 degree phase-shifter network in between. Think logic inverter. It is an amplifier and phase shift network in one. Connect its input to its output and it oscillates.

> So, finally, my question:  What kind of shielded cable
> should I be buying?  Are there ready-made shielded
> electrode cables?

I am a newbie on EEG, so I can't recommend any brands of ready-made cables to buy or not to buy. If you are going to make your own electrodes microphone cable might work, as it is made to similar requirements. I am using home made electrodes with cheap (< $1/meter) shielded microphone cable. The first half is a 2-lead cable, then it branches into two 1-lead cables, one for each electrode, but that is because I use  2.5mm stereo plugs (same as they use in portable CDs etc) and have one per electrode pair (except ground).

I have had decent results with these in the few tests I have made so far, but I did get a lot of 50Hz noise at first. This was mostly because of high and unbalanced impedances in the scalp. Preparing the scalp better gave better results.

I was not using the DRL here, and from the points you have brought up, we may need driven shields for it. However, Jörg has tested the DRL (without guarding I think) and it worked as it should then, so hopefully we won't need that bit. Fortunately adding a shield driver is simple, if push comes to shove. (However, the analog board design is a bit cramped currently so redrawing the design will be tricky.)

Regards,

Andreas

Re: [Openeeg-list] Considerations

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

On Sat, 13 Jul 2002, Dave Fisher wrote:

> [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?

	My personal idea of balance is LGPL, but since I probably won't have
time (codewise) for more than a few bugfixes, feel free to ignore me :).  Keep
in mind that any code that you personally write can be relicensed under any
license you  choose :).

> 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)?

	WANAL :).  My suggestion would be something like "The code belongs to
the individual authors, but is licensed under the LGPL" (or whatever license
we choose).  Or, look what other people are doing.  Or, even better, ask a
lawyer :).

Re: Braces (K&R / 80s / 90s)

	Not the 80s way please :).  I prefer K&R, but don't particularly mind
the 90s way :).

> I also see a lot of merit in *documenting* the code internally.  Not only will

	As a Perl programer, I agree :).

> Tim, is this the kind of information that can be folded into the FAQ, perhaps

	Only when we have consensus :).

> 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.

	It's on my list of things to do :).

>  Perhaps it should be checked into CVS complete with revision history so that
> other's can add to it?

	Good idea.

> Do you have aspirations of being the local Documentation/Tech Writer?
> Pretty please? :)

	I'm not sure about "aspirations" (does that mean I inhale an asp? :) ),
and I'm not sure how much time I'll have, but I certainly intend to maintain
the FAQ with questions that are frequently asked, and other useful
information.  Someday, probably, this will provide a starting point
for myself or someone else to write manuals, at which point that FAQ section
can just say "Refer to manual section ...".  :).


---------------------------------------------------------------------
| 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: Vol 1 #4 - mail delivery

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

On Sat, 13 Jul 2002, Jim Peters wrote:

> 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.

	I figure there must be some way to filter them, because I'm sure other
sourceforge types would want it, so I vote we see if we can get them to turn
it off.  Of course, I use pine which auto-converts anyway, so I don't mind
either way :).

> 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.

	I like the way pine asks me "Do you want to reply to the 'Reply-To'
address, or the 'From' address?"  :).  That makes it a lot harder to mess up.

	:)

---------------------------------------------------------------------
| 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] Version 0.0.1 OpenEEGlib/BioMom sources checked into SourceForge

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

On Sat, 13 Jul 2002, Dave Fisher wrote:

> Since this is a preliminary alpha release, I have set the version number to
> 0.0.1.  This follows the traditional number scheme of [major].[minor].[release]
>
> Where "major" releases will include fundamental structural changes to the code
> and design, which will probably break other applications based on it, "minor"
> releases include enhancements and additional features, but will not *usually*
> break existing code, and "release" indicates patches and bug fixes.  The
> "release" number also gives an idea of the maturity level of the major/minor
> level.  The higher, the better, because that means more bug fixes. :)

	Hmm.  Or should we have even-numbered minor releases be stable ones,
and odd-numbered be development, like the Linux kernel?

	:)


---------------------------------------------------------------------
| 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-----

[Openeeg-list] comparison of escrow services

[yaniv v. <yan...@ya...>]

hi 

i did a little research on the net of escrow services (services that collect a money , assure the seeler that the money is there , and only after the buyer checked the product and approved it , send the money to the buyer ) . 

here's the results :

http://www.escrowguardian.com/hFees.htm
works only for check and money order , 
but fees are 1.9% <5$ for a device 


www.epreview.net  
$12 for $0-$400 purchase


www.escrow.ca
5% for credit card , 2.5% for cash . 
so <$10 charge 

 



---------------------------------
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes

[Openeeg-list] What kind of shield for cable?

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

Hi,

One of my favorite articles on shielding so far is

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

although I'm just beginning to understand it.

One point they make is that there is the famous
commond mode that the patient picks up from
the local mains, and that this CM can be reduced by
the "driven right leg" circuit.  I think I understand
that idea, although I'm not sure why the "middle" of
the
instrumentation amp inputs (the two resistors that
determine the gain) is the CM feedback signal for DRL.

But the artikel3 also mentions that the signal wire in
each of the inputs can pick up mains, too, and that
this is trickier to get rid of.  For one, they claim
that the DRL circuit can be unstable (how?) if the
electrode wires have grounded shields.  

They also mention the "driven shield" idea but I'm not
going to try and follow that until I fully understand
the DRL.

In any case, I _have_ decided to build a perf-board
prototype using INA114 and 277 op amps with a DRL, but
I really do want to ground the shields of the
electrode inputs.

So, finally, my question:  What kind of shielded cable
should I be buying?  Are there ready-made shielded
electrode cables?

Thanks for any input!

John J.

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

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

[Oli S. <Ol...@sc...>]

> Btw, do you have a camera? A picture (or many) of your design (and
electrodes and surrounding setup) would help a lot in figuring out what
might be letting the 50Hz hum in. You can send it directly to me because =
we
want to keep the attacments down to a minimum on the list. I suspect J=F6=
rg is
interested too. :)
>
> Regards,
> Andreas

Wouldn't everybody love to see a pic? I sure would.
I wouldn't really be able to tell what I see, but I'd
still love to see it.  ;-)

regards,
Oli

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

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

Hi Chris,

> artefacts...  I could identify the EKG in that configuration.

Very good, this means it's working at least partially! :o)

By the way, perhaps you should measure the electrode impedances. You might be able to use a regular multimeter. 

However, different multimeters can use different amounts of current so be *very careful*: first test with two electrodes on your arm and have someone help you do the measurement. When you can get a good measurement (say 10kOhms) without feeling pain or discomfort, try the same on the head, but do not place the electrodes near the eyes on the first try...

I'm basing this on practical experience with my multimeter. If anyone on the list thinks this is a bad idea... please let us know. I did a little practical experiment with the tinyeeg a few days ago (my father being the willing test subject), and at first all we could see was 50Hz hum. Better prepping helped. And... believe it or not, running on batteries helped too though I think that becomes unimportant as soon as the electrode impedances are low (and equal) enough

>Has someone had good results with the modular-eeg-design ?

You are the first to build it actually. I have ordered parts and PCB, and expect all of it to show up at the end of this week. Of course, the layouts differ a bit, but it is basically the same circuit.

> When I connect CH1-, CH1+ and VREF/2, the signal has significant lower
> 50 hz -interference, centering at around 1023, not around 512 as
> expected. Testing the  VREF/2 voltage gives about 4 V (not the expected
> 2V) to GND and AGND (GND and AGND seem to be connected. I don't know if
> this is ok.)

>I more and more belive that I did something wrong in the board
> implementation.

Since you get four volts, something might be wrong with the voltage divider after the voltage reference, so let's start there.
Measure the unbuffered VREF signal leaving the digital board. Is it 2 or 4 volts? 
Assuming it is 4 volts: Disconnect the power supply, then trace the wire back to the voltage divider. Are both resistors soldered properly, and measure 10kOhms? The one going to GND is the prime suspect here - it may not be grounded properly.

> I someone has ideas, please reply. I cannot work at the project the next
> 2 weeks, but I surely will continue after coming back from holidays.

Have a nice vacation! We will fix this when you get back.

Btw, do you have a camera? A picture (or many) of your design (and electrodes and surrounding setup) would help a lot in figuring out what might be letting the 50Hz hum in. You can send it directly to me because we want to keep the attacments down to a minimum on the list. I suspect Jörg is interested too. :)

Regards,

Andreas

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

[Sathe D. <sat...@ba...>]

Chris,

You probably have taken care of the following already & this may sound=20
too simplistic but this is what comes to mind and might help you in=20
testing the board at the least.

I have seen that the 50 Hz interference gets picked up by 1) any kind of=20
wire loops formed outside the shielding and 2) by the human body itself.

To reduce this pick up, if there are any leads sticking out of the=20
shield (co-ax or box), try to twist them with a  ground lead.  The pick=20
up by human body can only be controlled by moving physically away from=20
all kinds of mains wiring.  If you are using batteries with the board &=20
laptop, take everything out into the garden or something. =20

I will have to freshen-up my bio-med stuff & look at the schematic etc.=20
before I can comment on anything else.

HTH

Dilip
------------------------------------------------------

Chris wrote:

>Dear J=F6rg, Andreas, Jim !
>
>Last days I spent some time im building a better shielding for board and
>electrodes, I made a case out of copper-platines and used shielded
>cables, mounted on a grid-like electrode cap. (one cable for each
>electrode, 1 meter long).
>I connected the shield to AGND and, in another try, to VREF/2. both
>settings did not change the situation of the 50 hz - interferences that
>can be reduced by touching Power Ground. I did some tests with the
>electrode-cap mounted and touching ground, but the signal i got was not
>good enough that i could identify brainwaves, there where only
>artefacts...  I could identify the EKG in that configuration.
>
>Snipped
>

[Openeeg-list] modular eeg work report II

[Chris <e93...@st...>]

Dear J=F6rg, Andreas, Jim !

Last days I spent some time im building a better shielding for board and
electrodes, I made a case out of copper-platines and used shielded
cables, mounted on a grid-like electrode cap. (one cable for each
electrode, 1 meter long).
I connected the shield to AGND and, in another try, to VREF/2. both
settings did not change the situation of the 50 hz - interferences that
can be reduced by touching Power Ground. I did some tests with the
electrode-cap mounted and touching ground, but the signal i got was not
good enough that i could identify brainwaves, there where only
artefacts...  I could identify the EKG in that configuration.

Has someone had good results with the modular-eeg-design ?

The ModularEEG I'm talking about is:

  ModularEEG - version1.15, Datum 4.3.2002
  File : modEEGamp1_15_std.sch  (single-sided, download via
  openeeg.sourceforge.net)

J=F6rg wrote:
>Fuer einen ersten Test verbinde CH1- mit CH1+ mit VREF/2.
>Das gleiche mit CH2-, CH2+ , VREF/2.
>Jetzt solltest Du auf Kanal 1 und Kanal 2 ungefaehr halbe Ausseuerung
>haben (AD-Wert so um 512) + etwas Rauschen (ein paar LSB des
AD_Wertes).

When I connect CH1-, CH1+ and VREF/2, the signal has significant lower
50 hz -interference, centering at around 1023, not around 512 as
expected. Testing the  VREF/2 voltage gives about 4 V (not the expected
2V) to GND and AGND (GND and AGND seem to be connected. I don't know if
this is ok.)

I more and more belive that I did something wrong in the board
implementation.

I someone has ideas, please reply. I cannot work at the project the next
2 weeks, but I surely will continue after coming back from holidays.

Best greets & sunny days !
Chris.

Re: [Openeeg-list] Considerations

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

I'm going to reply to a couple of messages at once since they are related.

Jim Peters wrote:

>it).  The alternative approach, as used in Perl, is to dual-license
>the source, so for example in Perl's case the user has the choice of
>whether to apply the GPL or Artistic license.

I was looking at the MPL 1.1 license earlier and saw that they had a similar
clause except that it is a "tri-license" (for MPL/GPL/LGPL) which states:

 * Alternatively, the contents of this file may be used under the terms of
 * either the GNU General Public License Version 2 or later (the "GPL"), or
 * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
 * in which case the provisions of the GPL or the LGPL are applicable instead
 * of those above. If you wish to allow use of your version of this file only

The GNU folks write this about MPL 1.1 on the web page you reference above:

"However, MPL 1.1 has a provision (section 13) that allows a program (or parts
of it) to offer a choice of another license as well. If part of a program
allows the GNU GPL as an alternate choice, or any other GPL-compatible license
as an alternate choice, that part of the program has a GPL-compatible license."

So after looking at the host of licensing options, I liked this one the best. 
It seems a nice bridge and balance between the two worlds.

As an aside for others -- MPL stands for Mozilla Public License, which was
fashioned when Netscape decided to release its browser as open source.  Thus we
have an example of a closed source project coming to terms with the open source
world.  MPL 1.1 is a result of this transition.

And...

Moritz von Buttlar wrote:

>Hi !
>
>Let's use some GNU license so that our gnu-logo makes sense. What about the
>lgpl ?

This way the GNU can stay and still makes logo-sense. :)  Projects that are
built using the OpenEEG SDK can be released under any of the following
licensing strategies: MPL, GPL, or LGPL.

A nice annotated version of MPL 1.0 (that has non-legalese comments) is here:

http://www.mozilla.org/MPL/MPL-1.0-annotated-fs.html

And the legal text for MPL 1.0 is here:

http://www.mozilla.org/MPL/MPL-1.1.html

They also have boilerplate templates that can be included in each of our
sources.  If this is a go, let me know and I'll attach it to the header of all
the source code files.  I think it represents the best of both worlds.

Dave.

Re: [Openeeg-list] Considerations

[Moritz v. B. <in...@ba...>]

Hi !

Let's use some GNU license so that our gnu-logo makes sense. What about t=
he
lgpl ?


 Moritz

--=20
Baltic-Microsolutions http://www.baltic-microsolutions.de
uC-DSP-PSOC Hardware/Software development
MSP430-Bootloader Software

Re: [Openeeg-list] Considerations

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

Dave Fisher wrote:
> 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


Also take a look at GNU's list of compatible and incompatible licences:

  http://www.gnu.org/philosophy/license-list.html

So long as your Artistic Licence is the 'Clarified Artistic License'
or 'Artistic License V2.0', according to this site, it is compatible
with GPL'd code, so if I write code under the GPL or LGPL and link
with your Artistic license code, there is no problem (as I understand
it).  The alternative approach, as used in Perl, is to dual-license
the source, so for example in Perl's case the user has the choice of
whether to apply the GPL or Artistic license.

Jim

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

[Openeeg-list] Re: [buildcheapeeg] Re: estimate

[Klaus W. <kw...@gw...>]

me'd be interested too. 
if Andreas could mount the parts it would be great :)

Klaus
salamander wrote:
> 
> i'd be interested.
> 
> cheers,
> andrew

Re: [Openeeg-list] Considerations

[Moritz v. B. <in...@ba...>]

Hi Dave !

> Licensing
> -----------------------------------------------------------------------=
----
>-
>
> Notice that I have been using Larry Wall's (the author of Perl) "Artist=
ic"
> 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 i=
t
> because it represents a nice balance between the more strict GPL style
> license and more lax BSD style.  I personally lean more toward BSD styl=
e,
> 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 contributi=
ng
> to the open-source supporting library.=20


I think the GPL license was chosen more by chance when I applied for the=20
SourceForge project webspace and had to select a license. At that time I=20
didn't know about the different licenses and their advantages/disadvantag=
es.=20
I think our project should be useful for the biggest amount of people=20
possible and therefore we should allow non-open-source spin-offs.=20

 Moritz

--=20
Baltic-Microsolutions http://www.baltic-microsolutions.de
uC-DSP-PSOC Hardware/Software development
MSP430-Bootloader Software

[Openeeg-list] Version 0.0.1 OpenEEGlib/BioMom sources checked into SourceForge

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

Ok; I just checked in a working version of the source code into OpenEEG's
respository at SourceForge.  It's over 8000 lines of fairly well tested and
documented code.  This should give us a good starting point.  Just a few notes.

I've only compiled this on Linux.  I do not know if it will work under Windows,
although it should, in theory, be portable.

I did not upload the packages for this release on SourceForge since I was not
certain what we wanted to us as an archival format.  Once we know, I will
upload them.  For Linux, it makes sense to use gzipped tarballs.  For Win32, it
makes sense to use ZIP or RAR.  So, for now, I've make both formats available
on my website at:

http://www.psychosensory.com/openeeglib/openeeglib-0.0.1.tar.gz
http://www.psychosensory.com/openeeglib/openeeglib-0.0.1.rar
http://www.psychosensory.com/openeeglib/biomon-0.0.1.tar.gz
http://www.psychosensory.com/openeeglib/biomon-0.0.1.rar

as well as

http://www.psychosensory.com/openeeglib/openeeglib.gif

because I did not want to import a binary file to the repository.  This is the
class UML diagram, which I can put in the repository if we want, but I should
probably change its name to be something more descriptive if we want to do
that.

Otherwise, you can ignore all of this and just checkout the source from CVS.

Since this is a preliminary alpha release, I have set the version number to
0.0.1.  This follows the traditional number scheme of [major].[minor].[release]

Where "major" releases will include fundamental structural changes to the code
and design, which will probably break other applications based on it, "minor"
releases include enhancements and additional features, but will not *usually*
break existing code, and "release" indicates patches and bug fixes.  The
"release" number also gives an idea of the maturity level of the major/minor
level.  The higher, the better, because that means more bug fixes. :)

Let's see... oh, also.  I used wxDesigner to put together the wxWindows GUI. 
We can talk about using this commercial app or find open-source alternatives
for RAD/GUI options.

I think that is about it for now.  I'm pretty brain-dead from working on all
this, so am probably missing something important to pass on, but hopefully have
covered all the critical areas.

Off to enjoy what is left of the weekend!

Dave.