Greetings from Left Field. Sorry to be irrelevant but... Back in 2009, I found formulas that give very nice speed estimates from combined accelerometer and altimeter data. These are documented here: http://www.rocketryplanet.com/images/pdf/Barometric-Adjustment-of-Inertial-Flight-Data.pdf (One version is in the main body of the text; the other is in Appendix D, the WGA approximation. The WGA is the simpler of the two, and it’s a very good approximation.) I call these estimates Barometrically-Adjusted Speed Estimates, or BASE estimates. Whereas BASE estimates are robust, estimates of trajectory sines have been problematic. I had two ways of estimating those with barometric data and inertial data combined, and both involved numerical differentiation of barometric data. The most straightforward formula was simply SineTheta = VY/BASE Where SineTheta is the sine of the trajectory angle, VY is the vertical velocity (from numerically-differentiated barometric data), and BASE is the barometrically-adjusted speed estimate at the same point. Numerical differentiation is a mathematical problem constructed in Hell, and it’s not worth more than a bit part in prime time. Between that and aerodynamic effects at the static port, trajectory sines were mostly pretty ratty. (To be clear, they could be better if everyone collected barometric data more carefully. Some were very good, but one cannot rely on good barometric data.) The software for the differentiating protocols was too big to imbed in onboard instrumentation, and associated apogee-detection algorithms were not materially different from purely barometric algorithms. Numerical differentiation also demanded that the barometric data be decimated effectively discarding information. What is needed is a formula for sine that: 1) Doesn’t involve numerical differentiation; 2) Relies more heavily on the inertial data than on the barometric data, while using both; 3) Can be used in a new apogee-detection algorithm; and 4) Can use all the data I… think I may have one of those. From the formula just given, VY = BASE*SineTheta But also, VY = VYLast + R*DeltaT*SineTheta g*DeltaT Where VYLast is VY at the previous sampling point, R is the accelerometer reading, DetatT is the sampling interval, and g is gravitational acceleration. Setting the formulas equal to each other and solving for trajectory angle sine, SineTheta = [VYLast g*DeltaT]/[Base R*DeltaT] So the algorithm is 1) Do Inertial Analysis on the Launch Rod 2) VYLast = Inertial VY from Launch Rod 3) SineTheta = [VYLast g*DeltaT]/[Base R*DeltaT] 4) VY = Base*SineTheta 5) VYLast = VY 6) Goto 3 Note that the only use of barometric data, here, is in the computation of the BASE values. The denominator of the sine formula has a potential low-speed singularity, and it will normally be negative in the first data point, because of the influence of gravity. It’s therefore best to start at some VYLast other than zero, and that’s why one must use launch rod speed to prime everything. Here’s the algorithm: RodSpeed = RodSpeedLast +R*DeltaT g*Sin(LaunchAngle)*DeltaT Length = LengthLast + RodSpeed*DeltatT Stop at launch rod length or something short of it, if you don’t know the exact value. Since one knows the rod angle at least approximately, this formula is much more reliable than inertial free-flight formulas. It’s wholly empirical, in fact. These sine curves correspond well to the old barometrically-adjusted curves and to off-vertical ballistic inertial analysis curves. They are prettier than the old barometrically adjusted curves and only slightly less smooth than the ballistic analysis curves (because of stair stepping in the barometric data.) The apogee-detect algorithm is to deploy when the sign of the sine turns negative. Although mach speeds can cause barometric anomalies: 1) They will likely not cause the sine to flip sign (Gotta verify this); and 2) The WGA is a barometric point-wise correction. Cumulative errors from past barometric anomalies do not pertain. In fact, I have data sets that show that supersonic flights do not all have huge anomalies. (This contradicts a statement I made in the paper, BTW. While I’m at it, turns out a method I rejected in the paper, The Brute Force Method, is objectively wrong.) But... one cannot rely on this. At any rate, I expect to supply an Excel VBA program in a few days. The attached graphs are from the program as it stands. Empirical sine is from the method above. Ballistic sine is from off-vertical analysis of pure inertial data under the assumption of a ballistic trajectory. A launch angle was backtracked in the ballistic method to fit the data no such accommodation was made for the present analysis method. The integrated altitude is integrated from the VY above. The barometric graph is from temperature-corrected barometric data. Altitudes are in feet. BASE values used were from the WGA approximation. Regards, -LarryC

Larry, I have had to be absent from forum activities recently due to work, but I caught a few minutes and saw this post. I'm MIA for at least another week, but I am interested in reading more on the method. I have recent data from a mach 0.8 flight in Raven format if that would be of interest. Take it easy. I hope life is going well for you. Sandy.

Sorry it took so long, but I just downloaded the data tonight. Onboard video is on youtube at the ROCC channel at: http://www.youtube.com/watch?v=DmSb5c9rQDM Hope the data/video is helpful. Sandy. View attachment freedom launch sept 2011 loc iv 4988.FIPa

Thanks, Sandy. From the video, it looks like a nice straight (and high!) flight. Good job! As it happens, I'm updating WGX to work with Raven data. Although there are complications of different sampling intervals for inertial and barometric data, some things are easier. For example, since the Raven accelerometer is not self-calibrating, the first reading tells you the launch angle. The first ASL baro reading gives you the elevation. On cool-to-temperate days, the thermometer gives you the temperature. (On hot days, the Ebay temperature is not representative.) Worked out a number of little typos in version 1.1 Next addition is to have Cd and thrust curves - then a Java conversion. Thanks for the data! -Larry

I am interested in following your efforts with Excel VBA. I am a senior Excel VBA developer. I have a master's degree in Astronautics. Ex Aerospace Engineer. My blog Alfred-Excel-Vachris details my interest in creating software for analyzing tabular functions. I would love to get my hands on some flight data. Best Regards Alfred Vachris

play nice children. Alfred, you might want to start a new thread on your interests. Many altimeters are under-instrumented for measuring flight angle, but some may have the desired data. Working it out from a single accelerometer is definitely a challenging problem. br/ Tony

Just a heads up Larry's last post to this thread was 2011 and he hasn't been on TRF in the last 10 months, with the exception of the last few posts all are 8 years or so old. Its definitely interesting to follow some projects though.