From: Jim Meissner (jpmeissner_at_mindspring.com)
Date: 2002-03-04 13:46:57
Dear Andreas:
I worked quite hard to preserve the raw data including using a machine codeassembly language Bios driven interrupt service routine. If my programmerdid not trust DOS he certainly would not trust Windows. Working with a 386 processor was quite a challenge to get everything done in time. Just because we now have these super fast processors, I do not think you are out ofthe woods. For example, the new BwView program that Jim Peters wrote is much to slow to be used in real time even running on a 300 Mhz Pentium. Dave tells me that he cannot use the FFT waterfall display supplied with his EEG machine because it is way too slow. I am not a software guru, but I doknow when something works and when it is too slow. I remember that writing to the screen took so long that I had to write in the background and thenswitch active pages. I would guess this is still a problem (now a days) while watching Jim Peters program's slow screen updates.
and Dave:
The format I adopted was based on the HAL-4. I think the Brain Master usesa similar system. I transmit one sync byte and 4 data bytes. As it now stands, the sync byte could be only one of three states. The 0 means no marker, the 1 is marker #1, the 2 is marker #2, and 3 is marker #1 and #2. Inactual practice I have never used the markers.
So therefore if the sync byte is 0 this means this is "EEG" data, a 1 means"temperature", a 2 means "GSR", etc, up to "X" types.
A simple case statement would load the data into the proper bins.
The sync byte detect code would say if "sync byte" > X then this is not a sync byte.
The possible problem is that if X becomes too large, then other bytes mightalso contain that value and cause an occasional ambiguity and take a little longer to resync.
If you preserve the raw data, you can easily replay the file through the same system and analyze the session. ( My preference )
Sharing data with others and other programs is another "project" that can be tackled "much" later once you have a system that actually works. We are not there yet. Writing a translator program to make the raw data availablein various formats should be a piece of cake for a programmer type.
Juergen P. (Jim) Meissner
Check out my Website at www.MeissnerResearch.com
Read about the benefits of the Brain State Synchronizer sounds for improving your life and health.
----- Original Message -----
From: Dave
To: buildcheapeeg_at_yahoogroups.com
Sent: Sunday, March 03, 2002 9:01 PM
Subject: Re: [buildcheapeeg] Re: File Formats
On Sun, 3 Mar 2002 13:01:34 -0500, Jim Meissner wrote:
>> Writing one file (containing the samples) is definitely easier on the
>> hard drive and would simplify network-communication.
>
>If you have a remote A/D converter and microprocessor (such
>as you are planning to do) and sending serial data to the RS232
>port, then it is much easier just to stream the data to the hard
>drive as it comes in. This should be an interrupt driven routine.
>THAT IS NUMBER ONE PRIORITY.
When you say this, do you mean storing the raw, untranslated data as it comes
from the biofeedback device? I think it is important to be able to capture
this raw output (prehaps something which can be turned on and off at the user's
discretion), and even have it be able to be used to simulate a live session
(retrieving input from the stored file instead of the RS-232 port). But since
we will be supporting multiple devices, I think it would be better to also have
a common storage format for our use. Playback, analysis, etc., would be easier
to manage as our program would not have to translate several different stream
formats, or funnel these streams through their interpretive objects just to get
at the channel data.
>Other channel data such as temperature, GSR, heart rate,
>etc can be identified by the sync byte header information.
>This data can be sent at any rate such as 1 per second
>and still be extracted properly from the data stream.
Could you give an example of the sync header you have in mind? For example, if
I receive 32 samples of EEG data, and then 1 sample of GSR data, another 32
samples of EEG data, 1 more GSR sample, etc., how would a sync byte/header be
used to properly navigate the file for forward/rewind playback?
Dave.
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
buildcheapeeg-unsubscribe_at_egroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST