From: sleeper75se (sleeper75se_at_yahoo.se)
Date: 2002-02-06 07:57:55
--- In buildcheapeeg_at_yahoogroups.com, "Jim Meissner" <jpmeissner_at_mindspring.com> wrote:
> Dear Andreas:
>
> Thank you for your clear reply. What you say makes sense. I do
> not like the answer. Too bad about windows!
Yep, I don't like it much either. Using the serial port has its own
set of problems as well. A 115kbps data rate requires an interrupt
every 1.38ms (for every 16 bytes), but this article claims this is
downright stupid (although possible), so I'm beginning to think "Real
time-Linux" or "serial->USB converter with big buffer" or "soundcard
solution using a digital input" or even "lower sample rate":
http://www.codeproject.com/system/simpletime.asp
> Would this method work with my old Boland C++ DOS version?
Most likely. You may need to write a little bit of inline assembler-
code for disabling the interrupts.
>
> I like the idea of being able to look at any channel at any time.
> The two EEG channels need to be sampled at a 128 Hz rate. The EKG
> could be much slower. And the temperature and skin resistance data
> could be every second or every minute.
>
> If you do this with an external microprocessor transmitting through
> the RS232, you now have to provide channel information or have a
> set order that has to be decoded. Seems more complicated to me.
It is a bit more complicated, with a microcontroller and so on, but
more robust, I think.
Synchronization (the complex bit, I assume?) is simplified a great
deal if one uses a synchronization bit rather than a byte. This bit
would be present in all bytes transferred. You set it = 1 for the
first byte in a frame, and clear it for all the other bytes.
Synchronization then becomes a matter of waiting for a byte with that
bit set rather than trying to compare with the previous frames to
find the sync-byte.
> Under windows do you have an interrupt driven comm port so that
> you do not loose data while spooling to the hard drive?
Yes, the serial port driver is interrupt driven, however its default
priority is below just about every other device in the system,
including the hard drive and keyboard. The situation is the same for
DOS I'm afraid, but there is less going on there so it is less of a
problem. So for high (like 115200bps) speeds, you always get data
loss if you don't use flow control.
Increasing the priority of the interrupt to the highest level solves
the problem, at least that is what I've read.
In Windows, this is done by creating a registry key and Linux users
have a utility called Irqtune.
I have not tested this myself yet, but will when the hardware is done.
Anyway, for low speeds (9600bps), you probably don't have to worry at
all.
Regards,
Andreas
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:38 BST