in reply to homemade data acquisition

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

Replies are listed 'Best First'.
(RhetTbull) Re: Re: homemade data acquisition
by RhetTbull (Curate) on Dec 18, 2001 at 07:35 UTC
    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.

[reply]
[d/l]
[select]
      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-.

[reply]
Re: Re: homemade data acquisition
by Anonymous Monk on Dec 18, 2001 at 05:54 UTC
    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.
[reply]
      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-.

[reply]
Re: Re: homemade data acquisition
by Anonymous Monk on Dec 18, 2001 at 06:01 UTC
    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.
[reply]

In Section Seekers of Perl Wisdom