From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-13 10:01:12
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?
> 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.
> 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!
> 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.
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.
> 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.
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