From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-03 04:32:42
> Hi John,
>
> I usually stay out of the software discussion (hands full anyway),
> but for the moment (gosh, is it really 4.30am?) I'm sort of idle, so
> here's my take:
It's 2:11pm here........Ain't the Internet marvellous.
I welcome suggestions/views from anyone!
It's easier to design something in now then try and FIX it later!
(hands full anyway)
- Tell me about it I start tutoring a new subject tomorrow at Uni.
- I've got a project to finish that is part of a lecture on Thursday
- and my Tax is over due. :-(
> Before defining any data format (which, I don't think we ever
> should), we must decide on what to store. Right now we only know we
> want to save a series of samples in a number of channels, but that's
> about it. To that can we add lots of sideband data: threshold
> settings, filter parameters, screen colors, user name, whatever...
I was talking about RAW/pre-processed data!
But yes I agree defining formats for settings is very restrictive!
> Since the information is quite diverse, and undefined, I suggest
> storing everything except the samples in a database. A database is
> much more abstract, flexible and easier to handle in general than
> defining which byte goes where.
Database or maybe XML. Either would be good for setting but XML is more
flexible!
We MAY end up with each module storing it's own permanent-protocol (Existing
from one run to the next) settings and the Main class just doing the rounds
when it comes to saving a protocol.
On top of this would be the permanent setting (eg serial
port/USB/speed/rate/etc) that each module would store between protocols!
This way you could set up several protocols with different settings and not
have to reprogram the Hardware modules each time!
> The samples (and perhaps any other time-dependant data) on the other
> hand, can be stored in a very simple file format, where data from
> different "channels" are interleaved.
Yes I agree. I'd like to see what the other programs store their data as
first though.
Make it compatible (Or have a converter) and it makes life a whole lot
easier to share data.
Could be as simple as
[Date][Time] - Sample started
[Length] - MAYBE - would make it easy to fast forward to end or anywhere in
between.
[Number of Channels]
[Channel 1 type] - EEG/EMG/ECG/GSR/ETC
. . .
. . .
[Channel n type] - EEG/EMG/ECG/GSR/ETC
[Chan 1 Byte 1]
[Chan 2 Byte 1]
[ . . . ]
[ . . . ]
[Chan n Byte 1]
. . . . .
. . . . .
[Chan 1 Byte n]
[Chan 2 Byte n]
[ . . . ]
[ . . . ]
[Chan n Byte n]
Any suggestions on weather this would be good/bad/indifferent???????????
> The reason for splitting up the data is performance. A database is
> not very good at handling streams.
> (Does anyone have another opinion here?)
I agree and Databases have a whole heap of overhead and cleanup when the
DBase gets a little age on it.
> Naturally, there must be import/export filters for other data
> formats, but we should never have to operate directly (in real time)
> on them.
Nope only the raw data is real time either input or output.
> > Should we write multiple channels to the one file?
> > or 1 channel 1 file?
>
> Writing one file (containing the samples) is definitely easier on the
> hard drive and would simplify network-communication.
My view too I was waiting to hear from others to see if I was thinking the
right way. :-)
>
> Regards,
> Andreas
Thanks Andreas for the feedback
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST