65Re: [buildcheapeeg] Re: hi folks
- Dec 2, 2000Hi Rob,
----- Original Message -----
From: Rob Sacks <editor@...>
To: buildcheapeeg <firstname.lastname@example.org>
Sent: Friday, December 01, 2000 6:09 PM
Subject: Re: [buildcheapeeg] Re: hi folks
> Hello Jörg,
> > A little trick with the ALT-Key ?
> I used the little Character Map program. From now on
> I'll just copy and paste. (Unless you prefer "oe"?)
"ö" is ok. ;-)
I have used "oe" for compatibility with 7 bit mail systems.
On modern systems "ö" should work fine.
> I think it would be best to save the voltage values
> in a machine-independent format.
A machine-independent format is a good idea.
However I do not like voltage values very much, because
they have rounding errors and produce additional overhead
compared to raw AD-values.
e.g if the gain of the RS232EEG is adjusted, so that
full range is from -200uV(AD=0) to +200uV(AD=1023) ,
one bin would be 400uV/1024 = 0.390625uV.
What number format would you choose for this situation ?
float ? Or some fixed point format ?
What if later machines have 16 bit resolution or even 20 bit ?
> This requires less
> code and therefore fewer opportunities for bugs. It also
> makes it easy to guarantee that all future versions of the program
> can read all data files made by earlier versions.
> Since we can't be sure how many digits will be required
> to express the precision of future machines, the header
> will probably need a field describing the format of
> each number.
Something like this ?:
In the header for each channel (including digital channels) is defined
how many bits (n) the channel has plus 2 floating point voltages for
AD=0 and AD=(2^n)-1.
In the data section, each channel would be stored in raw AD-values
using as much bytes as the number of bits (n) requires.
A format as described above would provide relative efficient
memory usage and could be expanded to as much bits per channel
as required. It would be even possible to have different bit numbers
and calibrations for each channel.
> I could, I suppose, bit-pack the voltages -- in other words,
> if there are only 1024 possible voltages, each number would
> occupy 10 bits in the file instead of 16. However, the file
> would still benefit from zipping (because its length could be
> reduced further by run-length encoding) so maybe it's not
> worth the trouble.
If disk space becomes an issue, it would probably be advantageous
to implement a good data-compressor/expander algorithm. (I assume
the alogrithms for lha,arc, zip etc. are available in the web )
- << Previous post in topic Next post in topic >>