Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!vsi1!icldata!altos86!dtynan From: nusip@maccs.mcmaster.ca (Mike Borza) Newsgroups: comp.unix Subject: Re: Request for Real-time HW/SW Info Message-ID: <1047@altos86.UUCP> Date: 17 Apr 89 02:43:03 GMT References: <955@altos86.UUCP> Sender: dtynan@altos86.UUCP Reply-To: uunet!maccs.dcss.mcmaster.ca!nusip (Mike Borza) Organization: McMaster U., Hamilton, Ont., Can. Lines: 72 Approved: dtynan@zorba.Tynan.COM [Moderators Note:- This newsgroup goes around the planet. I've been asked to try and ensure that i/ the content is worth it, and ii/ that it isn't too long. With this in mind, in future, would people please try and be brief. Thanks... - Der] I tried emailing this response to (whose name I've now lost), but it bounced, so I'm posting it here. This is a response to a recent request for information on real-time physiological data acquisition. I've worked on a similar project, with the exception that we had considerably tighter timing requirements (athough still not particularly tight as real-time data acquisition systems go). We were working at extracting audio evoked potentials from single trials on 4 channels at 10 kHz/channel. (Visuals were a little down the road.) We were able to do this with an 8 MHz IBM 339 AT (a machine I'd not recommend). By carefully interleaving start of conversion and a computation loop, we could collect on 4 channels at this rate with a simple artifact rejection algorithm in place. Anyway, I'd suggest that you change your approach slightly. I like your idea about sampling the screen to resolve your stimulus arrival time, but I'd suggest using an indirect method to determine the start of the stimulus. From your posting, it appears that you're going to go with a PC/AT or 386/AT type machine, either of which should suffice. I'd suggest running under MS-DOS (more about this later). From the description of your video requirements, you'll be running a VGA or enhanced EGA. Since you know (or can determine) the character (or pixel) position on the screen, you can sit in a tight loop sampling the status bit in the EGA/VGA registers which indicates the beginning of horizontal re-trace. You can compute the start of stimulus as an offset from this time using the character position and the scan rate, to within the loop time and the dot clock time. Naturally, you also have to be careful to write the character to video memory such that you know that it doesn't appear one cycle early. If necessary, your tight loop can also be collecting data during the pre-stimulus phase. I'd suggest MS-DOS rather than UNIX (with real-time extensions), and just take over the machine during your data collection sessions. This gives you easier control over the machine and removes some possible unwanted interruptions. QNX is another possibility, but I'm not sure of the interrupt latency. I did all the code development and maintenance for our system on a '286 running Microport Unix. To test the high-level code, I wrote an emulator to fake the d/a and a/d subsystems. The low-level stuff had to be debugged in situ on the MS-DOS machine. The data acquisition subsystem was a single-board unit from Scientific Solutions (a.k.a. Tecmar) for about $CDN 1000-- there are probably better ones around. We built the outboard antialiasing filters, sample and hold amps, and digital I/O isolation ourselves from off-the-shelf chips. Given your rather coarse timing requirements, you can probably make do with a PC/AT clone at 10-16 MHz, but given the price differential, I'd just get a cheap 16 or 20 MHz 386 box. The bonus is that it's a nice cross development environment for DOS if you get VP/ix or Merge for it, so it's easy to test your high level stuff, and you can use it for something else when you finish this line of research (or your funding runs out:). (You won't be able to test the low-level stuff that reads EGA reg's or anything like that.) I'm using ISC's 386/ix and like it a lot (though I no longer do any DOS work, and only started VP/ix out of curiosity a couple of times). For bang-fer-the-buck, Everex's ENIX seems to be the best value these days. I'd also suggest polling the various port states rather than writing interrupt handlers. On a slower AT box, the interrupt latency can be several microseconds, which would have completely fried our single channel 40 kHz experiments. You can test for false responses at various points and have the software restart the collection automatically in the event of "super-human" response times. Hope this helps. mike borza