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!"

QNX

[sql*kitten]

You can download a RTOS, QNX [qnx.com], free for non-commercial use I believe. If you are used to Linux, it will be easy to program [qnx.com] since it supports similar APIs. Linux isn't actually POSIX, tho'.

Don't use sigma-delta A/D and D/A convertes.

[geirt]

Many A/D and D/A converters use sigma-delta converters (Look for words like: "one bit converter" or "bit stream", they are variants of this technology). Most sound cards use these sigma-delta converters, so do many A/D and D/A cards for PC, especially those with high dynamic range (many bits ...). These converters have excellent linearity, low distortion, and are inexpensive, but they have a significant time delay, so you might have more than 1 ms delay in the A/D converter alone. No real time OS can work around that.

Be sure that you select A/D and D/A converters with "sub ms" time delay.

What about DSPs?

[linuxator]

What about digityal signal processors? It would be lot faster...

Code Composer Studio

[Mechanik]

Disclaimer: I work for Texas Instruments.

I don't know how familiar you are with Code Composer Studio [ti.com], but it sounds pretty much like what you're looking for. It is TI's debugger for their Digital Signal Processors. You can either run your DSP software on real DSP silicon, or you can run it on a simulator that runs on the host computer. If you needed to capture data or pipe it to another program, you could then stream out blocks of memory to a file. Of course, this all requires you to be able to write DSP code :-)

There is also a free 30 day evaluation copy [ti.com] that you can order. Simulator only, but otherwise fully functional. If you can do all of your work in 30 days, this might be all you need :-)

There is special pricing for universities. They get the software are very reduced rates.

The software listed on the website is for the PC, and runs on Windows. It is not really advertised to the mass market, but there is a version for Solaris as well. If you wanted to get a hold of that, you might be able to, but you'd have to do a lot of pestering. That product is Code Composer Studio for Solaris 1.1

It is not out of the realm of possibility for Linux or HP-UX versions of the software to be released as well, if it is perceived that there is enough interest. If you want it, start pestering people :-)

Mechanik

1ms may not be possible

[clark625]

"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.

Using Matlab

[tony_gardner]

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.

Realtime? sure thing. Cheap? no way.

[rhk]

I use National Instruments E series MIO cards using rtlinux to sample a single channel at 400Khz, and process the data realtime on a dual PII-450.

It's not cheap (the board itself is at least $1000 US), but it does support 16 analog inputs and 2 analog outputs. They have other boards that could support the additional outputs you need.

Using rtlinux is pretty easy. I use comedi to control the cards. Freshmeat knows where to find these things.

Don't need real-time hardware

[MagmaiKH]

1ms is the way-way-way upper end of what could be considered realtime. You don't need an RTOS to do this - a USER mode application in Windows can respond that about that fast. The only problem is that it's not garuanteed like it is with RTOSes. Don't go surfing the web or defragment the harddrive and you'll be ok. (yes the default sleep time ranges from 10-16 milliseconds or so, you can change that with a call to timeBeginPeriod and set it to 1ms) National Instruments is the company you want to contact to work out the details of what you require. IOmega is another alternative if NI doesn't have a product that meets your needs (if NI has it, but it from them - even if it's more money!) NI [ni.com] They make a product called LabView which could work well for you.