Data Acquisition System

[Banacek]

Would any teams be interested in buying a data logger system if we could produce one at reasonable cost? We have the resources and expertise to take a crack building a multi channel data aquisition system and a handful of useful sensors for it (a la Claude Rouelle and his seminars). But, as is generally the case with electronics, making them in bulk saves a ton of costs on PCBs, etc. hence, I figure I might offer our development to other teams.

The tenative design has 12 8-bit analog channels, 2 digital 8-bit channels and 8 on/off (i.e. 1-bit, for things like switch states and failure recording) channels. We might be able to pack more analog channels in there at the expense of the other channels, but I see it becoming a hassle above 16 total channels. I haven't really done the math on speed, but 10-20 samples per sec should be easily doable with recording time for more than an hour. We would also provide software for transfering the data to some MS Excel readable format.

Sensors that we could package with the system include multi axis accelerometers, displacement sensors, temperature, Hall sensors (RPM, wheel spin, anything else that goes around in circles), strain guages, pressure sensors... I've never been to Claude's seminar so I'm not realy sure what else might be useful, hence this post.

My main question are:
- What are you willing to pay for it? (barebones, minimal sensors for $100?)
- What features would you like to see?
(Better software? Onboard high gain amplifiers? more channels?)
- What sensors would you like to have? (anyone been to Claude Rouelle's seminar?)

My main concern is keeping cost down, things like high pressure sensors, high end accelerometers, etc. are all fairly expensive so I'd rather supply just the cheaper sensors. For testing our own car, we're instrumenting everything that can be measured and a few things that can't, but it's gonna cost us.

Anyways, let me know what you think. If I get a positive response, I might have something ready for cars testing for Detroit '04.

Banacek

[Banacek]

Would any teams be interested in buying a data logger system if we could produce one at reasonable cost? We have the resources and expertise to take a crack building a multi channel data aquisition system and a handful of useful sensors for it (a la Claude Rouelle and his seminars). But, as is generally the case with electronics, making them in bulk saves a ton of costs on PCBs, etc. hence, I figure I might offer our development to other teams.

The tenative design has 12 8-bit analog channels, 2 digital 8-bit channels and 8 on/off (i.e. 1-bit, for things like switch states and failure recording) channels. We might be able to pack more analog channels in there at the expense of the other channels, but I see it becoming a hassle above 16 total channels. I haven't really done the math on speed, but 10-20 samples per sec should be easily doable with recording time for more than an hour. We would also provide software for transfering the data to some MS Excel readable format.

Sensors that we could package with the system include multi axis accelerometers, displacement sensors, temperature, Hall sensors (RPM, wheel spin, anything else that goes around in circles), strain guages, pressure sensors... I've never been to Claude's seminar so I'm not realy sure what else might be useful, hence this post.

My main question are:
- What are you willing to pay for it? (barebones, minimal sensors for $100?)
- What features would you like to see?
(Better software? Onboard high gain amplifiers? more channels?)
- What sensors would you like to have? (anyone been to Claude Rouelle's seminar?)

My main concern is keeping cost down, things like high pressure sensors, high end accelerometers, etc. are all fairly expensive so I'd rather supply just the cheaper sensors. For testing our own car, we're instrumenting everything that can be measured and a few things that can't, but it's gonna cost us.

Anyways, let me know what you think. If I get a positive response, I might have something ready for cars testing for Detroit '04.

Banacek

[BStoney]

sounds interesting...More info would be great

What about a steering pot? Just my two cents.

University of Cincinnati
bjstoney13@yahoo.com

[woollymoof]

20 samples a second may not be enough for some situations, esp shock displacement.

[Bob Wright]

to late, we've just been sucked into MoTeC's evil empire

Bob Wright
Monash University
Australia
http://www-personal.monash.edu.au/~fsae

[Sam]

I think we used a sampling rate of 100Hz for suspension data aquisition

Sam Graham
Engine Group Leader 2003
UQ Racing

[Amos]

Hey im just starting to learn about data acquisition and what not.... cant afford a trip to see Roulle as yet. Has anyone got any suggestions as to where to start????
Thanks in advance.

If it aint broke, still fix it!.... you'll do a better job.

[Banacek]

Start off by considering what you hope to accomplish with it. Do you want to measure suspension? Do you want to measure acceleration forces in the body?

Claude gave away a good listing of his "top 8 sensors" in Detroit. I can't remember it off the top of my head, perhaps someone else has that handy.

Any or all of the following are relatively easy to measure:
- Suspension displacement. Use a linear pot, LVDT or capacitative disp. sensor.
- Accelerations. Claude stressed the use of multiple accelerometers, front and back, to measure body oscillations. Left and right would also be useful. Otherwise you could also map the track with one (by integration), but you would have to compensate for body roll as they will also measure static acceleration (i.e. gravity). On the same note, you could also get 0-60 times, etc. this way. There's a commercial product that does something like this, g-tech or something like that.
- RPM. It's easy to measure as you can get it off any number of things already attached to your engine.
- Gear. You can measure directly from gear change inputs or derrive it from the RPM before and after the transmission.
- Wheel spin. Compare differences in wheel velocities, especially front vs. back. This is also used for traction control.
- Strain guages. This is a bit complicated, but properly designed, you can use these to measure forces on the chasis.
- Throttle position and manifold pressure. There's a good chance you already have sensors for this going into your EMC. Record it.
- Engine noises. Compare engine noises to things like the spark plug firing signals. Lets you know if your engine is firing properly. Nte that this requries a fast acquisition rate and isn't all that useful out on the track. Might be nice to have on a dyno though.
- Brake. Measure position at the pedal.
- Tire pressure. Relatively useless, but an interesting project if you want to experiment with short range radio (and designing a transmitter that's robust enough to fit on a moving tire). I've never tried, but I suppose you could get tire forces (i.e. under cornering) this way.

Recording on the car is one thing, radio telemetry can be fun too (a couple of teams had it in detroit). Two way telemetry, that's the way to go after that, but I have yet to find a good application for FSAE.

There are a bunch of commercial systems available. Motec has it built into some of there EMCs I believe (if not, they at least offer it as a separate device). For radio telemetry, there are some off the shelf systems, I don't know names. It can also be done with an OEM radio modem. You need to know a bit about data communications and RF if you want to roll your own.

As a general note, beware with analog sensors as the engine produces a lot of EMI. If possible, convert to digital at the instrument ADCs are cheap. If not, try to amplify at the instrument, then send the signal off to your recorder. Filter at both ends. Try to use a band pass where ever possible to isolate frequencies of interest. If not, at least LPF everything before converting it to digital and recording. From digital to the screen, use a good reconstruction filter to save yourself unnecessary oversampling. Keep the Nyquist rate in mind.

From a digital systems point of view, if you do roll your own, make sure you put enough memory on it. 20Hz sampling for an hour is 72,000 samples; from 8 instruments with 8 bit samples is 576,000 bytes, more than your microcontroller probably has available to it without some thought extra work.

As for sampling rate, 100Hz seems high even for suspension. Assuming good pre-filtering and other signal conditioning, and a good reconstruction filter, I can't see why you couldn't measure everything you need with a much lower rate (30Hz or so, keeping Mr. Nyquist in mind). It's also important to focus on what you are trying to measure. Rather than getting every little displacement and oversampling heavily, is it enough to get your spring rates and maximum displacements?

Bancek
"There's an old Polish saying..."

[Gareth]

According to Claude we should be sampling linear pots and strain gauges at 100-500Hz.

Note: At 27m/s (100km/hr) sampling at 100 Hz is .27m between data points. A lot can happen in that distance. Simple calc's prove simple points. ;-)

The book that Claude gives out at his seminars gives recommended smapling rates for various sensors. I don't have it with me now, but perhaps I'll post them later...

[MikeWaggoner at UW]

There's someone that's done this called SmartKart. http://fn2.freenet.edmonton.ab.ca/~grantb/diy/
This may help, all his info seems to be public domain. Good luck.

UW FSAE
The views of Mike Waggoner are not necessarily the views of the UW FSAE team.

[Banacek]

While I agree that 100-500Hz may be what's needed to capture every little disturbance, I think it's an issue of getting the imortant information vs. getting all the information.

Typically, the most important part of suspension information is verifying what happens in a turn. Assuming a turn at happens in something like 0.5s, having 10, or even less data points across that turn gets you most of the relevant parameters relating to min and max displacements, rates, info to derrive roll, etc. (Assuming good filtering and reconstruction)

I can't see there being much in the 100Hz range that's adjustable for most teams. Keep in mind that Claude's info comes from pro racing teams with piles of engineers and perfectly tuned suspension, for them 100 or even 500Hz matters.

At most, you might be able to detect loose connections and vibrations. But you can do that at a much lower sampling rate with a high pass filter and some kind of averaging.

Admitedly, it all comes down to how lazy you are and how willing you are to put more memory on your unit. Even with memory being as cheap as it is, personally I'm too lazy to put more of it on my board. Besides, I'm using this as practice in designing compact systems, so I'm taking the minimalist approach.

To each his own I suppose.

As for that data acquisition system in the above link, note that it can be done much cheaper with different components, especially if you're willing to solder surface mount components (also saves time drilling the board if you roll your own).

Banacek

[Charlie]

100 TO 500 mHz matters for exactly what was said above. Have you been to Rouelle's seminar? He stresses using memory for what you have to not just because.

-Charlie Ping
Auburn University FSAE (http://eng.auburn.edu/organizations/SAE/AUFSAE)
5th Overall Detroit 2003
? Overall Aussie 2003. http://fsae.com/groupee_common/emoticons/icon_smile.gif

[Mick_P]

Charlie is right - Claude highlighted the fact that you have to be careful not to utilise memory recording data at a higher sample rate that is not needed. K.I.S.S rules apply i reckon. http://fsae.com/groupee_common/emoticons/icon_smile.gif

Mick Partridge
Swinburne University of Technology