From: Sar Saloth (sarsaloth_at_yahoo.com)
Date: 2002-03-14 03:51:19
><snip>
>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).
Doesn't sound like a problem to me, especially since in EDF (for disk
format at least) the bad data marker would be written last if you put it
last in the list.
> > 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.
It doesn't sound complicated, but it may not be worth that much
effort. Another story - I did a survey of commercial sleep systems and
many of them did not even have the capability to join together two records
back into one study in case for any reason the collection shut down part
way through an 8 hour study. And it was a very rare system that would
automatically reboot and restart data collection if there was a failure
during collection. Considering that there is more than US$600 at stake for
losing a study, these people really haven't put much effort. And there you
are worrying about slight corruptions from loss of synch. Well, its not
much effort, but you are way ahead of the commercial sleep
systems. Personally I would think that just marking data bad and going on
is OK.
>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.
as long as you pick up synch again and that you don't corrupt the disk file
things should be OK.
<snip>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:40 BST