Re: [buildcheapeeg] Re: File Formats

From: Dave (dfisher_at_pophost.com)
Date: 2002-03-04 02:01:49


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.



This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST