R-DAS electronic altimeter/accelerometer

If no one here has a suggestion try searching the archives and/or asking you question on the Topica R-das forum.

The manual is "somewhat unhelpful" because you are going outside the bounds of what is expected.

Increasing the sensitivity would require that you do one of two things:

1) Replace sensor with a sensor with reduced range. 2) Add gain between sensor and the ADC.

Option 1 is basically a non-option because there are no suitable sensors. The ADXL105 is close, except it is not pin for pin comptaible with the ADXL150.

Option 2 is not a good idea because it requires cutting traces on the circuit board and adding extra components. Opamps, resistors and such.

Assuming that your launches are compatible with the RDAS launch detect (or just use the breakwire option), why not add an external sensor board that meets your requirements?

ADXL150 accelerometer with opamp and low pass filter set to whatever you want. A pressure sensor (a huge number of options here), again with an opamp for gain and offset plus a low pass filter.

The details are left as an exercise for the student. :-)

Or, if that is too much effort, it is possible to post-process the RDAS data and achieve higher resolutions. This is a result of the random noise present in the data from both sensors. A suitable program is available here:

jsk wrote: > Does anyone have experience with R-DAS on-board computers? We have a > student rocket project and are using an R-DAS Compact unit for data > acquisition. Since we are going only to low altitudes and using low > accelerations we would like to increase the sensitivity of both the > altimeter and accelerometer, but find the manual somewhat unhelpful > (yes we did RTFM). >

Bounds? What bounds?

David is right.

The resolution of the R-DAS ADC is only 10 bits... couple that with the noise of the sensors (without any pre- or post processing) and the resolution is what it is... any higher degree of resolution is 'outside' the bounds of what this computer was designed to provide.

One could design and build an add-on board using the I2c buss to feed the info to the EEPROM for storage... but one would have to include all of the sensors AND a higher resolution ADC along with the I2c comm.

Even if one were to use a 12 or 16 bit ADC... one would still need filtering to rid ones self of noise.

Read Davids pages... the guy has done his homework.

Impressive.

So my amusing missive aside, one could, say order a quad resolution RDAS from the vendor at whatever commercial cost they might charge?

Jerry

Thanks. Can you explain why the altimeter has an offset (default) of

143.6mBar, and why it should be user adjustable? Can't f> The manual is "somewhat unhelpful" because you are going outside the

jsk wrote: > Thanks. Can you explain why the altimeter has an offset (default) of > 143.6mBar, and why it should be user adjustable? Can't find anything in > the manual about this. >

I will start with the second question first: why?

The relationship between pressure and altitude is very non-linear. The equation is not easy to reproduce in plain ASCII so I will not do that here. If your curiosity overwhelms you, look for the standard atmosphere model on the net.

The sensor outputs a voltage that is linearly proportional to the pressure it sees. The ADC converts this voltage into a number. The smallest difference in the resulting number is referred to as an ADC "count".

Because of the non-linear relationship between pressure and altitude, a one count difference at low altitude does not represent the same altitude difference as one count at a high altitude.

The peak altitude is reported by subtracting the ground level altitude from the apogee altitude. Or:

apogee = f(p1) - f(p2)

Where f() is the function that converts pressure (p1 and p2) into altitude.

Now assume that the sensor has an error that results in an offset in the reported pressure. Then we get:

Apogee = f(p1+offset) - f(p2+offset)

If f() were linear then f(p1+offset) would be the same as f(p1) + f(offset) and the offset would cancel out of the equation. But f() is decidedly not linear so the offset doesn't cancel.

OK, enough of that.

The pressure sensor used in the RDAS is a "calibrated" unit from Motorola. If you look at the data sheet for this part, you will see that Motorola puts a definite number on the sensitivity of the part but not on the offset. Looking further into the data sheet it appears to me that their is some part to part variability in the sensor offset. Thus in order to get the best results you need to somehow figure out what the offset is for your particular sensor.

This isn't terribly hard to do.

First, determine your local barometric pressure. What you want is the actual air pressure and what is usually reported is corrected for your altitude. So you will need to adjust the reported pressure using the standard atmosphere model to get the actual pressure at your location.

Find out what the RDAS is reporting. First, capture some data and then export the raw data to a text file. You want to average together a few hundred samples of the pressure data to get a good number. Or just eyeball it through the random noise.

Convert this number to millvolts (5,000mV/1024 counts)

Now, since the sensor output is linear (actually it isn't quite linear, but it is close enough) we plug our numbers into the good old equation for a line: y = mx + b

y is your local pressure m is the sensor sensitivity (kPa/mV or some such. Be sure your units match!) x is the sensor output in millivolts b is the offset that we are looking for

Solve for b and enter that as the offset in the RDAS GUI.

Easy!

Now the good news is that if your maximum altitude is pretty low (a few thousand feet), the error due to offset errors is pretty small. This is because the slope of f() will not change very much between ground level and apogee.

It is those flights that hit 20,000 feet that get hammered by offset errors. :-)

Note: If you dig up the Motorola data sheet, be carefull about using the sensitivity number. This number is valid for a sensor excitation voltage of 5.1 volts and the RDAS runs at 5 volts.

Sure, if money is no object and you trust the vendor specs. and the validity of barometric pressure being a true measure of altitude. ;)

But I currently don't believe that any commercial product is available for accurate altitude reporting (and thus apogee detection)... I mean, what if you are launching in a valley, and the altitude is above the mountains forming the valley? BIG change in baro readings!

Most computers use a 'look-up' table... equating pressure to altitude. We've the technology to measure altitude AGL to millimeters... but the implementation into model rocketry either hasn't been tried or is a bear to implement.

Have you thought about GPS? GPSFlight has a sweet little system and is fairly accurate to within a few meters (if ya get one that is WAAS enabled). About $600 for the whole system.

All of that aside... if you use the R-DAS or any (current) baro sensor for altitude detection, you'll need to pre-process the baro readings... which means adding hardware or modifying the R-DAS firmware.

Mark