From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-13 23:48:03
Dave wrote:
> When I first wrote the data acquisition
> routines for the ProComp+, I was grabbing an entire round-robin set ...
>
> 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?
I like the idea of sending out the data as soon as possible to other
parts of the program. However, it could be coded so that the serial
receiving code both sends out individual pieces of data ASAP, and also
builds up the current data record in a buffer to write to the file.
That way, at the end of the 24-packet set, if the CRC or sync isn't
correct, then error flags can be set for the whole data record before
it is written out to disk.
The error signal would just have to be delivered late to the other
parts of the program itself (mostly this would just be a user-display
thing anyway, because we've not been talking about handling this
automatically -- we're just making sure that the user knows there has
been a problem).
> 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?
I think pad the rest with zeros, set all the error bits from the point
you lost sync with the data, save it out and then go looking for a new
sync. If the ProComp doesn't have a frame counter (a frame being 24
packets in this case), then you're not going to know how many frames
you lost, but if you did, you could have inserted a load of data
records full of zeros with the error bits all set to make up the gap.
I hope I am not making this too complicated. This is just the way I
would do it to make things reliable according to my way of thinking.
Really, if we lose sync, this is a serious problem. We are just
trying to pick up the pieces and carry on as best we can, and as far
as my thinking goes, there is no real need to do much more than make
sure that everything up to that point was recorded okay, the error is
flagged, and everything from here on will be recorded okay too.
> 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?
Zero the rest of them in the data record, set error flags on anything
that is in doubt, and save it out. That is what I think anyway.
Actually, if the ProComp works in 24-packet chunks, it might be better
to use data records of 3/32 seconds.
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