I learned alot from David Schultz and his NAR Research and Development report
entitled
" Barometric Apogee Detection Using the Kalman filter" A copy can be
found on his web page at:
http://home.earthlink.net/~david.schultz/
It discusses more than just the Kalman filter.
I used his idea for Recursive filtering and implemented it in the PIC code.
I will continue research into use of the Kalman filter in Roctronics.
I had previously been doing some least-squares fit research and it may find better applications in the Descent rate calculator since there is a definate line to fit there in the descent rate.
Details
I first tested out the algorithm in Excel so I could see what the effects of rounding would have on the data. I also wanted to see what values I could use for good fit to the data.
Here is a screen shot of a portion of the Pressure curve. See how it smoothed
that bit jitter!
Here is a graph of the acceleration curve. Now we know why systems would
reset when used in a hybrid rocket.(psst, this was data from a hybrid) But look
how well it smoothed the data.
PIC implementation
To implement it in the PIC there were a couple factors I had to take into
account. The first one was that the PIC was only an 8bit microcontroller. And
even though you can use larger numbers due to the carry bit of the status
register it would be better to try and limit it to 16 bits, this is what I did.
The ADC used in the Roctronics system is a 12 bit ADC. This allows higher
resolution so that we dont have to add much more resolution to it. As a matter
of fact this ADC gives a resolution of about 7feet per digit of its output. Now
this does sound pretty huge but keep in mind that many commercial units out
there use 8 bit ADC and some of the top of the line units use 10bits. Well this
gives them a slight disadvantage and they would require more filtering to make
them more usefull. And just for reference if it is using an 8bit ADC it can only
resolve about 112 feet, and a 10bit ADC can resolve about 28 feet.
After
running these filters the data that is calculated has a resolution of 1/2 foot.
And as you can see from the graphs, this is quite stable indeed.
So from running the tests with Excel I found that I could have a vast
increase in usable data if I just added 4bits to the data. This would bring the
data value from 12bits to 16bits, perfect. These added 4bits allow for better
resolution since if you dont have the extra room you can loose important data with
rounding when you are doing the math. I also found that a weight value of 16 or
1/16 or .0625 worked well with the data I supplied to the calculations. This
also works out will since I have to Multiply the data by 16 to get the added
4bits then divide by the weight value, in this case its 16. This would result in
ADC*16/16=result. Well if you passed the 6th grade you might be asking yourself
why would you multiply by 16 only to divide by 16, well this is just the way the
formula is written. And since I lucked into such good numbers I can skip that
step entirely and just use ADC=result. This shortens the code and makes life
better. I need a hug.
Oh, so anyway here is a listing of the code I used in
the Barometric only altimeter I made.
//Divide by 16(a weight of 1/16=.065)
ESTALT=FilteredPressure >> 4;
//Read Pressure value
getADCvalue( 1 ); //Read CH1 and store in AD
FilteredPressure = FilteredPressure+(AD - ESTALT);
As you can see there is very little to this code. The only thing I have to remember is that I am now working with 16bit values. When I store them to EEPROM I trim them back down to 12 bit because 12bit is plenty for storage and I want to use the upper 4bits for indicators of what events have occured.
If you have any comments let me know.
