From: Sar Saloth (sarsaloth_at_yahoo.com)
Date: 2002-03-13 16:42:42
At 10:01 AM 2002-03-13 +0000, you wrote:
>Sar Saloth wrote:
> > Exactly, but one that might loosely look like XML. Can you think of
> > a good name? BXML? (bastardized or binary?)
>
>I don't know ;-) Call it an "XML-like" encoding, perhaps?
agreed.
> > On a practical level - YES! - for the control and status I would
> > definitely only handle the ?XML? on a streamed basis (I want this to
> > be very embedded friendly).
>
>Okay, I think we're clear now. I did look at XML a long while back,
>because in principle it is really really simple as a format. However,
>to do it properly, according to the standard, there are loads of
>little complications (and the standard itself seems to have been
>written for aliens). For this reason, to handle 'official' XML, I
>think it is better to use someone else's library.
>
>But if you're using your own XML-like encoding, then you can do what
>you like, and make it really efficient.
good.
> > Yes, I am agreeing. I was trying to elaborate on a case I saw where
> > some interface programmers (without telling anyone) had devised a
> > scheme to drop the occasional sample to handle drift on two
> > unsynchronized machines that were operating at the same nominal
> > rate.
>
>Oh no!! Terrible idea!
Real-life stupidity.
> > I am sorry that is just a bunch of hot air for this group, but it
> > has stuck in my craw since I wasn't able to explain the problem to
> > anyone.
>
>You are making perfect sense to me.
>
>
> > >Did you see my suggestion that we store a separate error channel of
> > >1 bit per sample to keep error flags ? This wouldn't be
> > >per-channel, though.
> >
> > I haven't quite gotten my head around the implications of that. It
> > certainly would be space-efficient, and we could just label it as
> > another channel with a special label so that it wouldn't break
> > current EDF readers. Very few disadvantages to such a scheme.
>
>That's interesting -- I hadn't thought of that. You could actually
>also retro-fit floating-point data streams onto EDF in the same way.
>Traditional EDF software would just see a channel full of weird noise,
>whereas your software could recognise the label and take pairs of
>2-byte integers as 32-bit floats.
I like it! And if we made those channels first in the record, would we
maintain 4-byte word alignment?
>The way I see an error channel working is to make the error channel
>run at the same rate as the fastest of the other channels, and store
>one bit per sample. If the bit is set, then something went wrong at
>that point. It is just a way to keep on going if there are problems
>-- e.g. you nudge the serial cable in the middle of an important
>session, it comes up with red markers on your recording display, but
>you can still carry on.
>
>When it comes to analysis (e.g. with something like BWView), you have
>the red markers from the error channel to remind you of where the
>problem was, so you know that there may be analysis problems around
>that point.
>
>Good idea, bad idea ? I think good, but then I don't have any real
>live EEG experience to judge it by.
Looks like a good idea to me. Real EEG must have the ability to mark data
as bad. The only thing that confuses me is that you say it should be as
fast as the fastest data stream but then just be 1 bit per
sample. Wouldn't that allow us a minimum data rate of fastest sample rate
/ 16? Or would that make the software too complicated?
> > In fact, this relates to something I see as a big shortcoming of
> > EDF. I don't think it is reasonable that the data not have some
> > method of self consistency check to mitigate the possibility of data
> > corruption. A CRC is an excellent example of this. In 1992 when
> > EDF was created, such things weren't considered as important but I
> > think nowadays with standards for data processing medical
> > information, such things are highly recommended. This could be
> > another special channel like the "loss of synch" or "data bad" flags
> > or something like that. If it is indeed implemented like this,
> > there should be the option of using either CRC or something
> > computationally simple like bit wise XOR or something like that.
>
>You mean put a CRC check on every data chunk, or something like that ?
>I'm not sure about the need for this on files that are kept on the
>hard drive. After all, lots of huge critical files exist on a
>computer without CRC checks (e.g. executable binaries, and so on).
>
>Usually CRC checks are done on files that are transported over an
>unreliable medium, but the files are often left without internal
>checks themselves. If you were going to use EDF for transport over a
>serial cable, perhaps there is a need, though. As you say, you could
>retro-fit it by having another channel with one sample per chunk to
>store your CRC. Alternatively, you could put the checks into your
>XML-like wrapper.
I agree completely on the practical requirement for CRC except for one
thing. When going through the FDA (and I would be surprised if the
European requirements were very different) you have to state what you did
to ensure the validity of data at ALL points in the process, which for me
means that I would add some sort of CRC or checksum as soon as the samples
came from the A/D and let that go along with the data all the way to the
disk file if possible. While it is easy to argue between us that such a
thing isn't very important here since we aren't monitoring breathing or
heart rate to ensure someone's survival, trying to argue that with the FDA
is probably a dumb idea. It is better to just do as they say. If it
wasn't for those other Canadian bastards that radiated a few people to
death by software errors and then lied about it so that more people got
burnt, we might not have these problems. As it is, there are software
validity requirements for ANYTHING related to a medical product.
Since it could be an extra data channel that wouldn't break any current EDF
software, I will put it into anything that I do.
Is a chunk the same as a record in EDF?( I haven't programmed anything but
assembler for the last 15 years. I can't get my head around compilers or
anything that needs CHECK BOXES or anything else that doesn't show up in a
source listing.)
_________________________________________________________
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