Slashdot Mirror
Realtime Signal Processing for Unix?
Christoph Zrenner asks: "I'm a UK medical student with a serious research interest in "how to interface neurons with computers". We do a major project in our third year and I'm interfacing an eel spinal cord (8 analog inputs, 12 analog outputs) to simulate the eel's movements on a computer. The processing needs to happen in real-time (1ms delay) so that the cord can get feedback from the computer. Having spent two days foraging through the Internet I still haven't come up with a decent solution - does anyone have any experience with this kind of thing? I was hoping to use the Matlab/Linux combination but only found an (expensive!) Realtime Windows Target Toolkit for Matlab!"
"Real time" is always a misleading term--at least it is for me. A full 1ms delay through the system really doesn't sound like a lot but you're times are going to get killed through those A/D convertors. Right now, just for sampling, I use a Lineartech LTC1296DCN. It's got 8 input lines, and gives me 12-bit precision (+- one half bit). These little guys are great. You can get over 1500 samples per second out of them--but that's if you're only looking at one input. If you start checking input 1, then 2, etc I don't think your throughput goes down much but you're only getting about 1/8th the samples per second. So now each input is being checked 185 times a second, or 5.33ms between samples.
Now, you can get an A/D that is dedicated to each input and you'll see 12-bit precision in about 0.5 to 0.7ms for each sample. That doesn't give you a lot of time for processing and then getting a reasonable output. Of course, 8-bit precision may be all you need in your application--I can't say for sure, though only 256 voltage levels on the input means roughly (unless you're really good) 256 semi-discrete outputs. An eel may not notice that the signals are not "continuous", but when we try this with humans you can bet it'll be very noticeable. Don't get me wrong--I am not saying that this is impossible, but your design critereon do make this a tough challenge in general.
If this were my project, I would forget about the term "real time" for right now. Worry about that once you actually have a system that has some real delay and you can optimize or work around some of the problems you want to deal with. Fact is, a delay of 10ms _may_ be okay. If that's the case, you'll have plenty of time for A/D, some processing, and D/A. I think a previous poster mentioned something about using a DSP--that's probably a good idea. Using a single PIC or multiple PICs may be possible as well. If you attempt to control via the computer, you'll likely end up with huge problems in communications being too slow for proper control. That's likely to screw with the eel really badly.
We've got a bunch of undergrads working right now on a way to flash PICs once with a program that knows how to talk to the computer. Then, when the PIC is reset, it will request an "operating system" if you like from the RS-232 interface. The computer sends the PIC's program and things happily run along, with the PIC checking for updates to it's program every so often. It can even do I/O through the same port if so desired. This would allow for the program to be "modified" as the program is running--something that might be very desireable in your situation. Of course, the RS-232 bus may be a bit too slow for your application; but it could be made to work with other busses as well.
Long, cute, or funny Sigs are just another form of over compensation, used by geeks, nerdz, etc.
Note that with the matlab package you link to, that the processing does not take place in the matlab just-in-time-compiling environment. The matlab generates c code which you then have to compile. This is because bare matlab is (Generally speaking)too slow for real time operations.
The cheap option is then to write your own. The AD/DA cards you're using will probably have drivers and control libraries for the language of your choice. You won't get the fancy graphs, but if you set the thread priority high, it should work.
If the encoding time of the DA card is a problem, you should seriously consider doing at least part of your feedback in analog (Please don't flame me!). Simple analog computation: add, subtract, multiply, integrate, differentiate, timeshift etc is perfectly reasonable to do even at frequencies greater than 1MHz, and for considerably lower costs than a laboratory quality AD/DA card. You can always use a combination of analog and digital.