homemade data acquisition

[Anonymous Monk]

I hope this is within the scope of this forum. I was wondering if anyone has had any luck with home-grown data acquisition systems and fetching/analyzing w/ perl. Namely, I was looking for some schematics for a suitable ADC chip (TI, National Semi, etc..) that have a real shot at hooking up and working via USB, RS-232 or Centronics and can be accessed w/ perl. Also, any snippits of perl code to acompany would be wonderful. I am kinda stuck between acsii acessable devices (almost too easy- but expensive) and devices that require windows and some propritary C++/Assembler drivers or analysis software. I am not trying to control a nuclear plant or maintain national security, so fault tolerance is not a major concern. Any ideas, links or suggestions would be better than where I am now! Thanks,

[dws]

I was wondering if anyone has had any luck with home-grown data acquisition systems and fetching/analyzing w/ perl. Namely, I was looking for some schematics for a suitable ADC chip (TI, National Semi, etc..) that have a real shot at hooking up and working via USB, RS-232 or Centronics and can be accessed w/ perl.

A friend whipped up something cool using a Basic Stamp board to run to some data acquisition, which he then processes and charts using Perl scripts. The Basic Stamp has an on-board processor, and speaks a serial protocol over RS-232, so it's pretty easy to drive from Perl. Some configurations have on-board wire-wrap space.

Here is another project that uses the Basic Stamp to collect data for later processing via Perl.

[cacharbe]

While I can't offer you any perl code, I can offer you three years of experience of writing software in the Data Acquisition field (The company is barely around now - HEM Data) But it was all in C/C++ and Assm.

One of the things to keep in mind is that unless you do use a serial port (I'd use Device::SerialPort or Win32::SerialPort if so) or a USB interface (I don't know of any modules, and couldn't find one when I looked), you are going to be programming at the kernel level, as you need access to low level hardware calls, anything else would be too slow, and you run the risk of undersampling, or underflow errors. This is, of course, influenced by the number of channels you are sampling, and at what rates, etc.

It isn't an easy task. I would trust those proprietary drivers before I would try and write my own (and I have had to write them), unless you really know what you're doing.

It's a daunting task, but it might be interesting to attack writing a USB interface for an acquisition system. Which ones, specifically, are you looking at?

C-.

[RhetTbull]

As cacharbe mentioned, using a serial port is definitely the easiest and most portable solution. However, it is possible to talk to other devices with perl but requires more elbow grease. I worked on a similar project where I used the serial port to collect data (I was collecting directly from a Tektronix scope with RS232 out) but needed to use the parallel port to control some devices. As a result I created a Win32::RawIO module that let me talk to the parallel port. It did require creating a kernel level device driver (yuck!) but it works well. I'm working on cleaning it up for CPAN as time permits (it's only been tested in one app and isn't very robust and the pod is, well, there is no pod...) As a bonus the module comes with peek() and poke() routines that work on physical memory address which could lead to some really interesting obfus and other dark magic :-) Of course, my module only works on Win32 and as soon as someone needs to run the app on linux or something else I'll be writing a new device driver...

The serial port is definitely the best supported and what I would probably use but there are times when it's much nicer to be able to read or write 8 bits at a time or when you don't have a spare serial port.

[cacharbe]

My comment about kernel level programming was in reference to data acquisition products by companies like Keithly metrabyte, Computer Boards Incorporated, IOTech, National Instruments, etc, who produce plug-in acquisition boards. These lead you to reading documents like this (although IOTech has a Parallel Port or PCMCIA solution module that will do on the order of 1 million samples per second aggregate, but it streams to ram, YMMV). The drivers for this one were particularly interesting.

I'd be interested to see some of the IO Work that you've done in Win32::RawIO. I was looking at a site earlier that had a large section on USB development for linux (though nothing specific to data acquisition)...The possibilities are endless.

C-.

[Anonymous Monk]

I have just surfed the back of some electronics mags and google for some. The ones that have stood out in terms of affordability are availible at <AHREF=http://www.superlogics.com and <AHREF=http://www.serialdaq.com They look to be identical units. The rs-232 unit seem nice because they can be accessed w/ ASCII commands. Though the rs-232 may be slow, it looks like the most promising. I do not know the history or reputation of these products or companies. In the spirit of my old apple ][+ days, I was even thinking of a variation of nabbing data from the "joystick" plug on the board. The apple would give an 8 bit value from 0-255 that could be read within BASIC very easily. There are some great hacks of the I2C bus (Linux drivers availible) that are in this spirit. I have thought about introducing my soldering iron to motherboard. I am really afraid what it may spawn! Some related info can be found at: <ahref=http://voxel.at/prj/ or <ahref=http://www.tk.uni.ac.at/~simon/private/i2c/main.html Really, I am just looking for a cheap and fun way to process external data. I don't really have any specific objectives.

[cacharbe]

I missed the links.

What types of data are you going to be acquiring?(Thermocouples? Accelerometers? Timing data?) How many channels? Or do you really have no idea? These things can have a great impact on what whether or not an rs-232 interface will even be worth while (it isn't very fast). My suggestion would be to figure out the test parameters, and then figure out the best interface.

Honestly though, if you are just going to be doing slow, single or double channel acquisition, rs-232 is probably your best choice.

Feel free to msg me with questions, ideas, etc, I'm more than willing to help out anyway that I can.

C-.

[Anonymous Monk]

Sorry about that. My links were stripped 8^|: http://www.superlogics.com, http://www.serialdaq.com, http://voxel.at/prj/, http://www.tk.uni.ac.at/~simon/private/i2c/main.html, Sorry they don't fire up. ahref'in it did not seem to do the trick. I probably mangled it.