From: Dave (dfisher_at_pophost.com)
Date: 2002-03-13 20:16:12
On Tue, 12 Mar 2002 23:27:46 +0000, Jim Peters wrote:
>If you have one device sending out 256Hz samples, and another also
>sending out 256Hz, there is almost guaranteed to be drift between
>them. This means having extra samples in some chunks but not others,
>and the whole thing quickly becomes a huge mess to analyse and store.
>
>Really this chunked idea is only going to work when a single recording
>device does all the sampling -- like the ProComp, sending out one
>sample of EMG data for every 8 samples of EEG data, guaranteed.
>
>Since there is no possibility for drift to be taken account of in the
>EDF format, they must also be making this assumption.
That makes sense. I was reading the FEF document that Adreas referred to in a
previous post, and see that they make provision for both single as well as
multiple device recordings, although they state "The real time communication
issues between the devices and the data logger are not covered by this
standard." The FEF looks like an extremely comprehensive solution for diverse
needs in the medical community, but for right now EDF or some derivative for
our use looks good.
>> from the time of the last sync. Thus, all I could do in the above
>> scenario is throw an error bit the moment I realize that I am no
>> longer reading valid data, wait for the sync and resume. Is that
>> what you had in mind for situations such as this?
>
>Yes, that is what I was thinking. Just do your best, and make sure
>the user knows there was a problem (by setting the error bit at that
>point).
Ok; another question. When I first wrote the data acquisition routines for the
ProComp+, I was grabbing an entire round-robin set (which would be 24 sets of
6-byte packets). The checksum for this set is the 23rd packet, and the sync
bytes are the last (24th) packet. At this point I would send the data on -- 24
samples of EEG data and 3 samples of non-EEG data (GSR, HR, etc.). This
enabled me to guarantee that the data was correct. But then I was unsure if
sending data in "bursts" like this was the best way, so I changed it to check
each 6-byte packet according the formatting rules for that packet (i.e., what I
expect it to look like--is this a data packet, is it a control word packet for
sensor status, battery level, checksum, etc.? see the Verify() method in class
ProCompPacket) and if it checks out, send the sample data immediately. If it
does not pass the verification test, I stop reading data until I find the sync
and begin the process again. In this way I am not holding data until I can get
the footer checksum/syncs, but then again, there is the possibility of sending
corrupt data if the checksum fails, or I am suddenly not in sync with the
packet boundaries and do not realize this until I do not get the expected sync
footer when I should.
I like doing it this way because I am able to send the data out immediately,
and I have to think that it would be rare to receive a corrupt packet set. But
what do you (or others) think? Would it be better and/or indifferent to send
data out in 8 sample bursts (for EEG) and 3 sample bursts (for non-EEG) data
for this device? Is there a situation where it would matter?
Does this effect data storage using the methods we have been talking about
since we are storing "chunks" and if I suddenly realize that I am no longer
synced on correct data boundaries? Should I just discard whatever I have of
the current set, or save it even though this might mean that I only have say, 6
EEG samples (and no non-EEG samples) that I can reasonably be sure of at that
point for the current packet set?
>> What would be our minimum resolution be (if any)? Would we ever
>> have, say, < 1 second, and thus have several "chunks" per second?
>
>Yes, definitely. For ProComp, you could use 1/32 sec, which gives 8
>EEG samples and 1 of each of the other samples.
Got it. However, what if something like the above situation occurs, and I
suddenly lose the sync when I am at the beginning of a set, and only have 6 EEG
samples and now have to wait for the sync to start all over again. What do I
do with those 6 samples?
Dave.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:40 BST