From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-12 13:46:25
John Morrison wrote:
> > Perhaps having an error channel which stores just one bit per sample
> > would do the job -- each bit is 0: no errors, 1: sync or other error.
> Our format should take account for this.
> BUT what will happen in filters when they hit this ???
My idea is that if you detect errors when converting a file, you do
the best you can, and if data has been lost, you insert zeros and set
the error bits. This would work better with a protocol like Joerg's,
where there is a cycling number in the packet header, because that way
you know how many packets you lost.
The filters would process the 'made-up' values, i.e. the zeros you
inserted. However, you would know that there was a problem, because
the error flags would be shown on the display. In BWView, I'm showing
these as red lines on the signal display. The red line means "Watch
Out! -- the analysis might go weird around this point".
This is better than inserting the zeros and not telling anyone, and
also better than just cutting the file at that point.
Well, that's what I'm thinking anyway.
> > ... we have files in pairs -- the session description, and the
> > session binary data.
> Not a bad idea that is what BioGraph does and it seams like that
> best way to handle things. :-)
It would be nicer in a single file, but I really don't know how to
make that work when the descriptive stuff might need to be edited
later on.
> In the beginning we can just define a directory structure to store the data.
> Maybe session directories???
> That way it is a simple matter to find the files you want!
Perhaps use a date/time for the filename with extensions of ".inf" and
".dat" (or some other suitable extensions).
> One thing I'd like to see is a method of adding MARKS to the file
> (annotation I think it's called).
> That way the "experimenter" could mark the file (press a button) during a
> session to mark when events happen then come back later to those spots and
> add comments (In an external file tied to those points!).
I was thinking that all the descriptive stuff like this could go into
the other file, as it is much easier to extend the format of that. In
the other file (in XML, or whatever) you would store a list of
time-points and descriptive information. This would also allow marks
to be added later on, for example during analysis. It might be
possible to have a program that lets you work through the data and add
notes at various points ("Big delta here", or whatever). Also, you
might want to write up a session after it was complete, with other
detailed observations you made.
> And another thing -
> Add a byte per channel to define the type of data recorded
> i.e. 1 = eeg, 2 = ECG, etc
> That way a simple programs will know what is in each channel without
> reading anything else.
I was also seeing this as something for the other file -- since there
are many possibilities, and probably also lots of extra information
you might want to store (like electrode placement, electrode type,
channel filters, whatever).
> Just about to press the send button and had a thought.
> I'd like to see the following info in the global header. It could be stored
> externally BUT then if the external file gets separated we loose the
> information.
> Date/time - recording was done
> Name - Of subject or some code to ref back to!
> - This way you could collect several subjects and easily work out who's
> file is who's
> Comment - Just for a quick not about session eg "Entering REM sleep"
> With this info and no other files you have all that you need to know about
> any file to make use of the file!
Again, I was seeing that as stuff for the other file. As I mentioned,
you don't want this kind of variable information in the binary file
headers because you can't edit it there without rewriting the entire
binary file.
Maybe we could put some kind of identifying key in there (like a
date/time code) so that you know which XML/whatever file it belongs to
if it ever got renamed, but I wouldn't suggest much more than that.
However, we can discuss this.
I could imagine a "basic BWView" that just understands the binary
format, and allows viewing much as it does at present, and later on
having an "extended BWView" that picks up lots of stuff from the other
file, and allows marks to be set and stored back to the file, subject
information to be viewed and edited, and so on. (Developing something
like this seems a little beyond my own capabilities, though, given my
lack of experience with GUI-coding and XML processing).
To make this work well, I really think that almost all the descriptive
stuff needs to go in the other file. That way you would never need to
modify the binary file after it had been recorded -- all the mark
points and so on would be written back to the other file.
The only thing I'm wondering about including in the binary file now is
some kind of identifying code (like a date/time stamp), and maybe
adding A->D convertor range information to the channel, as is done in
EDF.
Jim
-- Jim Peters (_)/=\~/_(_) jim_at_uazu.net (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:40 BST