From: Joerg Hansmann (info_at_jhansmann.de)
Date: 2001-12-07 15:02:54
Hi,
----- Original Message -----
From: Doug Sutherland <wearable_at_earthlink.net>
To: <buildcheapeeg_at_yahoogroups.com>
Sent: Friday, December 07, 2001 9:21 AM
Subject: Re: [buildcheapeeg] What we should do...
...
> > Without these, we could get a simpler design (like
> > Joergs first RS232EEG).
>
> I'd like to hear Joerg's opinion on this. Which one
> should be target for building prototypes?
I agree with Moritz.
The modularEEG offers many advantages compared with
RS232EEG and should therefore be the current target.
Furthermore it should be possible to get a "light" version
of the analog part by not-inserting some components and bypassing
them with wires. e.g. the 5th order anti-alias filter
could be easily bypassed, because it has a gain of 1.
...
> > It would be nice if we could get some substructures
> > with individuals responsible for different parts of
> > the project.
>
> Right now it's hard to tell even where to start. The
> code for the microcontroller based designs will be
> very different that ComADC for example. We need to
> pick one and go with it.
I do not agree. The code is basically the same.
Only the com-port time-counter-routine has to be exchanged
with a statemachine that parses the RS232 datastream.
I have written some quick and dirty experimental software in C++,
that can read the EEG-data stream, display data in realtime,
make FFT on it, calculate band-power and give feedback tones
when a threshold is exceeded.
(
The software was written using the freeware DJGPP compiler and
the multiplatform game library "allegro".
However for future developments I would use the
SDL-library (simple direct media library, multiplatform)
instead of allegro and the use of a SDL compatible GUI
)
So the basic techniques for reading the raw data stream
from comEEG and RS232EEG / modularEEG exist at this moment.
> > The most interesting part will be the open-source
> > software development. But this can only really start
> > if the programmers have devices....
>
> Yes. I am ordering the Atmel microcontrollers and
> most of the other parts right away. I will have a go
> at home etching the ModularEEG PCB as soon as Joerg
> says it's ready for using.
>
> Question: There is a sample data stream in the
> RS232EEG download.
Yes. e.g.
"Eeg01output_fixed_000822.hex"
> Is this the same format as the
> newer ModularEEG?
No. It is the elder Version 1 Protocol.
The new Version 2 Protocol is described in:
"protocol (version 2).txt"
/*
enhanced protocol (version 2):
byte synch_1 // is always $a5
byte synch_2 // is always $5a
byte version // is 0x02 (tells the PC, which protocol is running)
byte frame_counter // is 0x00 at startup. increment 1 for each data frame. wraparound 255->0
byte ch1_high // bit pattern is 000000bb. bb are the 2 high bits of 10 bit AD-value
byte ch1_low
byte ch2_high // bit pattern is 000000bb. bb are the 2 high bits of 10 bit AD-value
byte ch2_low
byte ch3_high // bit pattern is 000000bb. bb are the 2 high bits of 10 bit AD-value
byte ch3_low
byte ch4_high // bit pattern is 000000bb. bb are the 2 high bits of 10 bit AD-value
byte ch4_low
byte ch5_high // bit pattern is 000000bb. bb are the 2 high bits of 10 bit AD-value
byte ch5_low
byte ch6_high // bit pattern is 000000bb. bb are the 2 high bits of 10 bit AD-value
byte ch6_low
byte switches // 1 byte digital inputs (PD2..PD5) in the lower 4 bits.
all together 17 bytes per frame.
Note that channel data high and low byte are swapped compared to the previous version.
By this measure together with the unique pattern in synch_1 and synch_2 it is guaranteed,
that re-synch (i.e after disconnecting the data line) is always safe and not just by chance.
*/
The new protocol uses an additional framecounter and has swapped channel byte order to make
re-synchronization safer.
> Can we start programming without
> the hardware?
Theoretically yes.
Regards,
Joerg
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:33 BST