The hardware design is very straightforward:
My goal for this project was to build a simple altimeter that records only the peak altitude and reports it using a buzzer.
For this project, I selected the following devices:
The hardware design is very straightforward:
An earlier version (lost in late 2005 due to foolishly not taping the nosecone on the rocket it flew in) had a low-pass filter (R-C network) as described in the Motorola data sheet.
The late 2006 version of this included a 100uF capacitor across the 5V to provide a little bit of power to ride out shocks that cause the battery to momentarily push the spring in the battery holder and open (it would have been better to put this on the 12v side, but space was more convenient where there were 5v wires).
I made a single-sided printed circuit board using Techniks' PnP Blue
laster toner transfer.
With this product, the PCB pattern is printed on a blue film with a laser
printer then ironed on the copper-clad PCB and etched in Feric Chloride.
This device was destroyed in November, 2006 when the ejection charge on an Aerotech G64 didn't burn and the rocket carrying it came in ballistic. I never took a picture of it before its demise.
Most of this project is the software to process the data and report the results.
The analog output from the MPX4101A is somewhat noisy. When observing data at a sampling rate of about 100-200hz, I see about 2 bits worth of variation in the samples, with the sensor sitting stationary. Thus, some filtering has to be done in software. A simple average of multiple values will serve as a low-pass filter. I did this on a previous project (see YAFC - Yet Another Flight Computer). This didn't work very well, so I continue looking for a better solution.
I found a paper about signal processing for altimeters by David Schultz for R&D at NARAM 2002. (he has several project reports here). I decided to use the recursive filter he describes. I duplicated the 200hz sampling frequency, and increased the number of fraction bits. So far, it seems good enough.
For most of what the altimeter needs to do (detecting launch and apogee), operating on the pressure sensor values is fine. I've hard-coded values for how large of a pressure change is required to detect launch (I tried for about 150') and how far down the rocket has to come to determine that apogee has past. I picked these values conservatively to avoid having sensor noise cause a false trigger.
After apogee is detected, three values are recorded in the NVRAM: The values for the ground and apogee pressure and the time from launch to apogee. Upon power up, the saved values are used to calculate the altitude of the last flight and are reported.
It's more fun when the altimeter will report the altitude right after the flight. To do that, the voltage has to be converted to pressure then to altitude.
Vout = Vs * (0.01059 * P - 0.152)Where P is the pressure in kilopascals
Altitude = (10^(log(P/P_0)/5.2558797)-1)/-6.8755856*10^-6.where P is the pressure in kilopascals and P_0 is sea level pressure.
The exponentiation and logarithm are a bit much for an 8-Bit microprocessor with 4KB of program memory. Instead, I decided to build a look-up table in program memory. I use a perl program to generate a table, which is included in the source code. A full table for a 10-bit A/D converter would take 2kb of space, and I only have 4kb total. I decided to make a table of every 8th value and linearly extrapolate between those values. The extrapolation doesn't cause more than about a foot of deviation from exact, which isn't bad considering that where I fly (about 1000' above sea level) the A/D converter's steps are about 25'.
If I wanted a really precise altitude, I'd report the ground and apogee levels in kilopascals and calculate it on a more capable computer after the flight, taking in to account the local barometric pressure and temperature.
On power-up, the altimeter gives a long I am alive beep, then reports the last saved altitude. The report was first done as a count the beeps like many other altimeters, but I got tired of counting and switched to slow morse code.
After the flight, the new altitude is calculated and repored continuously until the power is removed.
Greater resolution can be gotten by using Oversampling and Decimation. This might be done underneath the existing signal processing algorithm. Of course, better resolution for the analog signal will require either a larger table or coarser table entries, or a combination of both. I figure that for one channel input the microcontroler can easily handle a 3200hz sampling rate for 4X sampling, permitting two more bits of resolution.
An altitude formula that takes temperature into account, accompanied by a temperature sensor (the tiny45 includes an on-chip temperature sensor).
The MPX4101 is obsolete, as is similar parts (MPX4115). Switching to a current production part, such as the MPXAZ6115A would be a good move. The newer parts are also available in smaller packages. Even the surface mount small outline version of this part is, in my opinion, hand-solderable by a hobbyest, with pins on 1.25mm spacing.