Data Acquisition: Hardware and Software

[steveg]

Red, after much searching, the line inputs on the soundblaster
are 1V max, or 1000mV so 200mv should be no
problem at all.
The drain on the batteries would be pretty small, use them
for a while and then throw them into your revi.Or find a
12VDC regulated wallwart. remember the object is to keep
this within a hobby budget (Imagine Steve rolling around
on the floor laughing, after saying budget and hobby in the same sentence),
however $700 for a sensor, no matter how nice is a bit much.

As for as counting balls out the end of the barrel, a spare viewloader optical sensor pair might work.
Even easier would be the above program(for the time scale)
the computer,soundcard,and mic, that you allready have.

That still would not answer how fast the hammer and cocking
cylinder operates that, being the original idea of this thread.

[steveg]

I guess that, at this point, what is needed is for some kind
soul with the real thing, NI labview, high speed pressure sensor, etc,
to compare the results with soundblaster,audacity,and honeywell 24pc
or other affordable sensor to see if anything useful or usable comes
out. We're playing with pbmarkers here not running oil refineries

[bjjb99]

Response times, supersampling, and testing

Redkey

I'm not sure exactly what is meant by "usable" frequency response. At first I had figured it would simply be the reciprocal of the full scale response time, but now I'm not so sure... there may be an additional conversion factor in there (square root of two, a pi, or something equivalent). I'll check around with some instrumentation guys I know; if they can add anything I'll post it here.

I agree about being able to collect a whole mess of datapoints with a fast data collection system (supersampling), and yet have most of those datapoints contribute little to the overall information content of the data when using a slow pressure transducer. There is a computationally intensive (and error prone) way out... if the response curve of the pressure transducer is well-characterized and normalized, you can deconvolve that response function from your supersampled data and remove, to some degree, the slowness of your sensor. If done improperly, you end up with results that are far more useless than the original inputs. :)

steveg

All this talk about testing has got my geek urges going. I'm going to start looking around at work for some of the data collection equipment required to develop a test system. As stated previously in one of the Deep Blue threads ("Things to ponder with how much pressure you need", I think), a decent digital oscilloscope may well do the trick with appropriate calibration. I doubt I'll find pressure transducers lying around, but if I can borrow a decent 'scope, I can at least test the cheaper transducer options out of my own pocket.

This will be one of those open-ended projects... no idea as to schedule, feasibility, etc.

BJJB

[nerobro]

We here are working on the same level ;-) Between my buddy and I we have the ambition, an o-scope, a buttload of comptuer hardware.. and enough spare cash to get a few transdoucers.. As for gates and reed switches.. the local ratshack can handle that.

one of these days this thread will come out of the depths of the archives when we all get the hardware togother.

[Redkey]

I too have all the stuff to do this and several other interesting projects... it's just a matter of free time.

I think the biggest issue will be finding all the PB gear to test. I cannot justify spending all the money to go out and buy one of every regulator just to test the differences in recharge rates.

If people start performing their own testing any results should be throughly documented along with the test method and equipment used.