As with the airband receiver, being an electronic engineer and pilot provided an excuse for wanting to make something useful for aviators. I wanted to get hold of an accelerometer and pressure sensor and construct some circuitry to measure their output and then take it up in an aircraft.
Not many aircraft are equipped with G-meters, mainly only those used for sport aviation and aerobatics, however most light aircraft are only stressed for -2.5 to +3.8G. For the average non-seasoned flyer pulling 2Gs in a turn can feel quite intense, however for someone who flies regularly the sensation is a lot less noticeable, so I was interested to see what sort of G-forces I was actually encountering during an average flight. It was however not my intention to try aerobatic manoeuvres in an aircraft type that wasn't approved for aerobatics, my reason for wanting to implement a G-meter was really for interest sake.
Portable (battery powered) digital flight computer with G-meter, altimeter, density altimeter, temperature, clock and stop watch functions and possibly logging functions.
The flight computer is a relatively straight forward digital hardware design. I decided to use a Freescale 68HC908GR8 processor for the job. I obtained a Freescale MPX4115A Pressure sensor and a 12-bit ADC to read the pressure sensor. For the G-meter I used a Freescale MMA1220D accelerometer and fed the accelerometer signal directly into one of the ADC inputs of the GR8. I used a Dallas Semiconductor DS1629 I2C real time clock and digital thermometer for time keeping and temperature readings. I split the grounds for the digital section and analogue section so as to get the cleanest signals from the two sensors. Since this project is battery powered and most of the devices run off 5V I decided to use a switching regulator for the supply and I selected devices that were either low power or could go into power down modes. There is nothing particularly special about the hardware design of this project, the cleverness however is in the software and processing algorithms.
Being an analog signal the pressure sensor output signal has electronic noise on it and the manufacturers recommendation is to add an analogue RC filter to the output to reduce some of this noise. The filtered signal has a noise voltage in the order of a few millivolts. Using a 12-bit ADC with a full scale input of 5V gives a single bit level around 1.2mV. Thus there is no advantage in using a higher resolution ADC to read from the pressure sensor. I did however take advantage of some digital signal processing techniques to improve the resolution of the acquired signal. By rapidly reading 16 samples from the sensor and then summing the samples I was effectively able to increase the resolution of my reading to 16 bits (each time you double the number of samples acquired of a signal with noise on it, you effectively add an extra bit of resolution). When I had the hardware working and was busy on the driver code for the sensor, I was able to verify with multiple reads from the sensor that only the LSB of the resulting 16-bit number was actually changing for each new sample set acquired. This confirmed that I was obtaining 16 bit resolution.
The equation for altitude as a function of atmospheric pressure is as follows:
Where p0 is the pressure at some reference level (sea level), p is the pressure at the elevation of interest, R is the universal gas constant, T is the air temperature, M is the molecular mass of air and g is the gravitational constant.
This equation obviously requires the evaluation of a natural logarithm. When I choose the processor I assumed that 8k program memory would be more than enough, after all when writing the software for my airband receiver I managed to fit all of its functionality into the 1k code space of the PIC16C84. At least with the 68HC908GR series, there is a possible upgrade path to a larger device (GR16) that is pin and functionally compatible with the GR8. However it turned out that any use of the standard C floating point libraries would be totally out of the question – as soon as I tried to compile in the libraries the code size exceeded 8k bytes. I therefore had to look for another method to evaluate the natural logarithm using integer arithmetic. After a bit of scratching around on the 'net I found this Taylor series expansion for the natural logarithm (http://mathforum.org/library/drmath/view/55563.html):
I also needed a way to represent fractional numbers with integers. For this I opted to use a signed long type (32-bit) and defined the decimal point in the middle of the bits (bits 0 – 15 are the fractional part). I wrote an optimised function using a for loop to evaluate the natural logarithm and it turned out that after only 10 iterations around the loop the residual error in the calculation was less than 10-3. In real terms what this translates to is at an altitude of 5000ft the uncertainty in the calculation result corresponds to 5ft - assuming there are no other errors in the measurement. Consider getting into a hot air balloon at sea level and then rising straight up to 5000ft, having a pressure altimeter with you that can report your altitude at 5000ft with an accuracy of 5ft would be quite impressive. In reality there are other much bigger sources of error, one of which is the temperature sensor. The temperature sensor I used has a specified accuracy of 0.5° C from 0° to 50° C. So an uncertainty of 0.5° C at 15° C (~288Kelvin) gives an uncertainty of approximately 1 part in 600. What's more the altitude calculation is also based on the dry air model for air and for moist air the molecular mass differs (The constant M in the altitude equation above). In reality the overall limiting factor for accuracy comes in correctly setting the reference level pressure, otherwise known as QNH by pilots. Most meteorology offices only report the pressure level in whole millibars. A change of 1 millibar in QNH corresponds to approximately 25 feet change in altitude, so one can only set an altimeter to within 25ft.
Density altitude is a concept that only really has any relevance for pilots. Density altitude is defined as the equivalent altitude in the standard atmosphere at which the air density is the same as the air density at the location of interest. What this means in simple terms is if the air density at a location of interest is lower than what it should be in the standard atmosphere then we are effectively at a higher altitude in the standard atmosphere. The reason this is relevant for pilots is the lift generated by an aircraft wing and performance of the engine and propeller is dependent on air density. If the air density is lower then the wings need to be travelling faster to achieve the same lift, but at the same time the power delivered by the engine and propeller will be less. For an aircraft taking off, this means a longer take-off run and lower rate of climb. Air density is strongly affected by temperature. The airfield I used to fly from in South Africa had an elevation of 2425 ft and in summer the air temperature could reach over 35° C. This would translate to a density altitude of 6000ft or more and so an aircraft would perform as if it were flying at 6000ft, struggling somewhat. Hence one would have to be quite mindful of how much weight the aircraft was carrying. Having an instrument that can give one a density altitude readout in these circumstances is very handy.
The implementation of the density altitude calculation is similar to the altitude calculation but rather more complicated. The equation for density altitude is shown below:
Here T0 and P0 come from the standard atmosphere- being 15° C and 1013.25 millibars respectively, p is the pressure at the elevation of interest, R is the universal gas constant, T is the air temperature, M is the molecular mass of air, g the gravitational constant and K is a constant that represents the adiabatic lapse rate of the standard atmosphere. In the standard atmosphere the temperature at sea level is taken to be 15° C and it drops linearly to about -56° C at an altitude of 11000 metres, using this information K can be calculated. A full description and derivation of the Density Altitude equation can be found here. Acknowledgements go to Richard Shelquist for his comprehensive treatment of the subject.
Clearly at first glance this equation seems pretty difficult to implement in a microprocessor without the use of floating point libraries and maths functions. However if one takes the logarithm of both sides of the equation, then the exponentiation reduces to a simple multiplication. So with some cunning tricks I was able to re-use my log function and then using the Taylor series expansion for ex I arrived at the answer. As with the altitude function I verified that the residual error from the Taylor series approximation was negligible. My density altitude implementation is 29 lines of C code and that includes lines of comments and blank lines.
The accelerometer I used has a full range scale from -8 to +8 G's and I was only interested in a resolution readout of 0.1 G. This is a range of 160 values. Therefore the 8-bit ADC of the microprocessor was quite adequate to use with this sensor. I had to implement some simple digital filtering because the accelerometer reacts to instantaneous accelerations giving wildly varying readings in turbulent conditions whereas I'm more interested is seeing sustained G-forces which last a few seconds or more. A mechanical G-meter with a needle in an aircraft has the inertia of the internal components to act as a damping mechanism so I needed an equivalent electronic filter. The measurement interval is set to 4 times a second, so the use of a relatively short FIR filter was sufficient.
The other functions to read and display temperature, time and stop watch were relatively straight forward to implement. The measurements are displayed on a 4 ½ digit LCD display and there are 3 function buttons to select the mode and set things like QNH, time and view Min/Max readings from the G-meter function. I implemented the altimeter and density altitude displays with the lowest digit rounded to the nearest 5ft as this digit tends to change rather rapidly on each reading and its value is neither particularly significant or accurate. My overall code size for this entire project is around 4.8k bytes.
To maintain the lowest possible power consumption I control the supply to the sensors with a P-channel MOSFET so that they are only powered up when they are needed. After power up there is a short warm up time for the sensors before they will deliver accurate results. The data acquisition period is about 20mS and then they are powered down again whilst the processor gets busy with calculating the result. I'm also making use of the auto wake-up timer feature of the HC08 processors to minimize power consumption in the processor. The timer wakes up the device 4 times a second to perform readings, computations and update the display. It then returns to sleep mode. This way I am able to keep the average power consumption for the entire circuit during operational mode extremely low. In reality one of the largest consumers of power during operational mode are the LEDs to the left of the display. I used LEDs to indicate which mode the computer is in since the LCD display is a generic display and doesn't have additional text to indicate mode of operation. On the whole the overall battery life of the unit is quite acceptable.
With the unit sitting stationary on a desktop the altitude reading (rounded to the nearest 5ft) remains constant or toggles between two values. This indicates that the uncertainty or noise on the reading is better than 5ft. If I place the unit on the floor I get one reading, then hold it at shoulder height, the reading will increase by 5ft and then hold it up above my head it shows another 5ft. This demonstrates the sensitivity of the instrument. If the unit is in doors and there is a wind blowing outside and a window is open, the altitude reading is seen to vary – showing that it is quite sensitive to the slight variations in pressure in the room.
Since the pressure sensor has a residual error on it, the unit requires calibration. To calibrate the computer I took it to my local airfield that had a met office, obtained the QNH reading from the met office and knowing the airfield elevation, was able to work out the calibration offset which I then put into the unit.
The G-meter's performance is as expected. If the unit stands upright on a level surface it shows 1.0 G, if turned upside down it shows -1.0G, if lying on its back it shows 0.0G. When I took the unit for its first test flight it was obvious that even in turbulence the G reading jumps around a lot. I therefore implemented a digital filter to smooth out the readings. The filter has a time constant of around 2 seconds, so it doesn't respond to instantaneous G forces, but instead gives a more consistent reading for sustained forces.
In flight testing the altimeter and density altitude functions, it became apparent that the temperature measurement had a marked affect on the reading reported by the sensor. This means that if the temperature in the cockpit is different from the outside air temperature (OAT), then the altitude reading will differ from the reading of the aircraft altimeter in the instrument panel. The reason is that my altimeter calculation includes temperature in it – this is the correct way to calculate altitude, however aircraft altimeters do not have temperature compensation built into them. Aircraft altimeters are based on a standard mechanical aneroid barometer design and as such are designed to work with the standard atmosphere, thus they actually have an error in their readings when the temperature differs from that of the standard atmosphere. At one airfield I flew from which was only about 8ft above sea level, on a hot day, when setting the altimeter with the QNH given by the Tower the aircraft altimeter would actually give a negative reading. The E6B (whiz wheel) flight computer provides a method for calculating the true altitude of the aircraft based on the calibrated altimeter reading and the outside air temperature for this very reason.
"Flight" testing the Flight Computer. Note the Flight Computer reads 10780ft while the aircraft Altimeter reads 10450ft. The descrepancy is due to the internal cockpit temperature being around 10 degrees Celcius while the Outside Air Temperature (OAT) was around 0 degrees. If one corrects the altitude reading using 0 degrees Celcius with the altitude formula above the Flight Computer would have read 10399ft - closer to the Aircraft Altimeter (which has an error on it anyway).
Same flight as photo above... there we were, 10450ft on the clock, enjoying the view of snow on the uKlahlamba Drakensberg mountains in South Africa after a snow fall in August 2004 (yours truly at the helm)
To overcome the temperature issue with my flight computer I decided to implement an additional altitude calculation function that uses the standard atmosphere model for temperature and then made it possible to select either the true altitude or standard atmosphere altitude calculation modes for display. The standard atmosphere reading shows much better agreement with an aircraft altimeter but as mentioned above is prone to errors if the air temperature differs from the standard atmosphere.
The temperature issue also affects the density altitude reading – this makes sense, that is what density altitude is all about. I've determined that if the unit is taken from warm surroundings to cooler surroundings or vice versa, it can take up to half an hour for the temperature inside the unit and thus the reading from the temperature sensor to settle to that of the new surroundings. This has implications if one flies to an away airfield, then leaves the unit in the aircraft with the aircraft parked in the sun. When one returns to the aircraft hoping to make a quick check on the current density altitude the unit will be grossly over reading. The unit will have to be moved into a shaded place outside the aircraft and given time for the temperature inside it to return to ambient. In the time it will take for the temperature reading to stabilise one may as well just use the E6B whiz wheel to check density altitude. This is however really just a matter of being sensible about where one leaves the unit and no limitation of the flight computer itself. On the whole the density altitude function of the flight computer is quite an eye opener. If one looks at density altitude from time to time it is interesting to see how much it can change at a fixed location dependant on weather conditions.
The flight computer is designed into a 130 x 68 x 43 mm plastic box and weighs 200 grams (with batteries) which makes it very portable.
I use two AA NiMH rechargeable batteries in the unit and in standby mode the battery charge lasts for around 3 months. In operational mode the battery life is in excess of 24 hours.
March 2003 – 2004
Some additional changes to software done later