From: Joerg Hansmann (jhansmann_at_g...)
Date: 2000-10-22 14:20:40
Hi Rob,
----- Original Message -----
From: Rob Sacks <editor_at_realization.org>
To: buildcheapeeg <buildcheapeeg_at_egroups.com>
Sent: Saturday, October 21, 2000 11:14 PM
Subject: Re: [buildcheapeeg] Software
...
> The only thing I can think of for the future is,
> maybe we should increment it so we can check
> whether all the blocks are getting through to the PC.
>
> Is the static synch byte that we have now always
> zero?
No. They have a unique pattern, that will not show up in the rest of the data.
byte synch_1 // is always 0xa5 (hex A5)
byte synch_2 // is always 0x5a (hex 5A)
> I've attached the documention and source code for
> the BrainMaster internal software. (They are
> posted on Tom Collura's BrainMaster website
> at ftp://brainmaster.com/pub/brainm/code/.)
>
> As you will see, there are several block formats.
> I am using this one:
>
> // sss00000 dddddddd dddddddd
> //
> // First byte is synch byte. sss (MSBs) are the synch
> // bits. 0s are always 0. The second byte is data for
> // channel 1, third byte is data for channel 2.
>
> The format of the data bytes is described here:
>
> ftp://brainmaster.com/pub/brainm/code/command.doc
>
> Es macht mir nichts wenn die beide maschine
> verträgliche sind.
Nachdem ich jetzt das Brainmaster Protokoll
gesehen habe, lege ich auch keinen grossen Wert
mehr auf Kompatibilitaet. ;-)
> (That was supposed to be German. It's been
> about 20 years since I last used it.)
Did you learn it in school or have you visited germany ?
> It doesn't matter to me whether the two machines
> are compatible. However, I've noticed three things
> about the BrainMaster which it would be nice
> (if we can) to do differently.
>
> 1. The synch byte increments each time, but
> the increment is not constant. This defeats
> part of the usefulness of incrementing because
> it prevents the PC from simply subtracting two bytes
> to see if it's in synch. The increments run like
> this in successive blocks:
>
> 00100000 databyte databyte
> 01000000 databyte databyte
> 01100000 databyte databyte
> 10000000 databyte databyte
> 10100000 databyte databyte
> 11000000 databyte databyte
> 11100000 databyte databyte
> 00100000 databyte databyte
>
> I.e., the synch byte goes 1-2-3-4-5-6-7.
> It skips zero.
Ok. I have added this point to the new protocol:
enhanced protocol (version 2):
byte synch_1 // is always 0xa5
byte synch_2 // is always 0x5a
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.
> 2. There is no single command that can be sent
> at any time from the PC to the BrainMaster to
> reset the BM to a known state. Instead, the PC has
> to deduce which state out of five the BM is
> in so it knows what commands to send. It would
> be nice to have one command that can be
> sent at any time to stop the machine and make it ready
> for new parameters.
Ok. That should be possible.
> 3. At least one important internal parameter of
> the BM (the sampling rate) cannot be set unless
> the BM is first turned off and turned back on using
> the physical switch on the machine. (Maybe this
> is my mistake, maybe I am not putting it in the right
> state first to accept this command.) It would be nice
> to be able to change anything about the machine
> from software in the PC without turning it off and
> on physically.
That should be possible too.
Regards,
Joerg
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:27 BST