How to best calculate velocity from Jolly Logic data?

A friend of mine sent me a spreadsheet (which I can share here if needed) that his Jolly Logic produced to output data. It gives all the data in 0.05 second increments, so there's a lot of it. Unfortunately the altitude has been rounded to the nearest foot, which I assume is because that's the most accurate that a barometric sensor can really do. There was also 3 dimensional acceleration but I didn't use it. To calculate velocity I converted the difference in altitude to miles, 0.05 seconds to hours, divided the two and got MPH.

Having the significant digits of the time at hundredths and the distance at 1.0 makes the velocity suspect.

So I did a second set of calcs that spread out over 10 readings, so that the calcs were over 0.5 seconds instead, which might help make the rounding of the altitude less of an issue.

As expected the velocity results are very different on the slower speeds but as the rocket gets faster the two speeds tend to be more similar.


Am I misunderstanding something about this process? Is there another, better, way to use this data to calculate velocity?

As a mathematician and an engineer, I avoid doing these calculations. In my opinion, they are highly suspect as the individual data points from these barometric altimeters are not all that accurate.

The barometer may be able to detect differences in pressure equivalent to one foot in altitude, but I doubt that your "system" is good enough to capture that level of accuracy. By system, I mean the rocket, the av bay, the static ports, etc. And the system is acted on by the wind, the humidity, etc. Lots of variables here and we only can control a few of them.

Another problem is that you are trying to determine velocity at the worst time during the flight in terms of data accuracy. The rocket is most likely at or near peak acceleration. Therefore, the air pressure is changing quickly as air is flowing out of the av bay faster than at any other time. Any obstructions that inhibit air flow will cause the greatest inaccuracies right at these readings.

To give you an idea of what I mean by the system not being accurate, look at the data during descent. Is it perfectly smooth? It should be pretty close, but the data on my plots always bounces around a bit. I looked at one of my plots for a rocket launched on an E9-6. The rocket went to 1,370 feet and took about 60 seconds to descend on a parachute. For this analysis I ignored the first 10 seconds of descent to let the rocket stabilize. The average descent rate for each 1/20th of a second sample is -1.13 feet. Therefore, I should see -1 feet between data points most of the time and a -2 feet reading occasionally. However, even under these relatively ideal conditions I have descent values ranging from +2 feet to -4 feet.
Specifically:
+2 feet was recorded 5 times
+1 feet was recorded 47 times
0 feet was recorded 208 times
-1 feet was recorded 412 times
-2 feet was recorded 256 times
-3 feet was recorded 71 times
-4 feet was recorded 17 times

In summary, the general data provided by these altimeters is useful, but trying to determine peak velocity is really just a guessing game.

You need to adjust a sim to fit the flight data and use the sim velocity values to eliminate digitizing and transonic shock effects.

The critical sim values are the weight and diameter of the rocket, and the proper motor thrust curve. Other details don't matter much.

Run the sim and look at the altitude and time to apogee. Adjust the Cd to obtain the observed apogee and check to see the time to apogee is close.

Once the sim matches the flight apoge and time to apogee values, the reported peak velocity of the rocket sim will reflect the max velocity obtained in your flight.

Bob

Great points! Thanks to both of you.

I suppose it's just neat data to look at and not really accurate to any high degree.

Now I'm wondering if the 3 dimensional acceleration could be used to plot the location, and also the velocities, more accurately than the elevation? That's got to be more accurate than the barometric readings from inside an AV bay.

You should use the accelerometer data for velocity, not barometric data (pressure tends to lag as it escapes during ascent). The velocity data is reliable up to burnout, and sometimes up to apogee. After that, the rocket has definitely pitched over too much for the accelerometer data to be useful for velocity purposes. But it's almost always good up to burnout (max velocity).

In a future version of the mobile app, you'll get "AltimeterTwo-style" max velocity, etc, flight analyses in AltimeterThree automatically.

But for now you can do calculations in Excel. Here's a spreadsheet that shows an example of how to do that.

https://www.jollylogic.com/wp-content/uploads/2015/12/FlightWithVelocityCalcs.xlsx

Thank you for sharing this!!!

It took me a few minutes to figure out that the word "gravity" in your formula was a reference to cell L15. I didn't know that you could rename a cell in Excel, so I learned two new things today. This is giving me much more believable numbers now.

Thanks again!!!

Good info John.

My club had a launch this weekend and one of the guys asked his ten year old son (+ or - 5 years as I am bad at guessing kids ages) if he wanted to use his new Estes altimeter. “Ralph” gets excited and says yes. They launch it and get no data.

I go over to my range box and pull out my Altimeter Two. Sadly, I haven't used it in months as I don't usually fly it at our low power field, but this rocket wasn't going anywhere near the trees. So I walk over to dad and say, “If you want to collect data, use this altimeter. We install it, launch the rocket and it lawn darts. I go get it, clean the mud off my Altimeter Two and start reading off the data for them. Thankfully, its a tough little critter.

Randy from eRockets is there and says, “I’ve sold hundreds of those things and maybe 4 or 5 Estes altimeters.” I reply, “That’s because the Jolly Logic stuff works.” And Randy says, “And they’re easy to use.”

Yup, another shameless plug for Mr. Beans' altimeters. You make a darn good product John! I just need to use it more.

Zeus-cat said:

Good info John.
his ten year old son (+ or - 5 years as I am bad at guessing kids ages).

Click to expand...

This cracks me up! A kindergartener and high schooler look the same to you....?!??!

John Beans said:

You should use the accelerometer data for velocity, not barometric data (pressure tends to lag as it escapes during ascent). The velocity data is reliable up to burnout, and sometimes up to apogee. After that, the rocket has definitely pitched over too much for the accelerometer data to be useful for velocity purposes. But it's almost always good up to burnout (max velocity).

In a future version of the mobile app, you'll get "AltimeterTwo-style" max velocity, etc, flight analyses in AltimeterThree automatically.

But for now you can do calculations in Excel. Here's a spreadsheet that shows an example of how to do that.

https://www.jollylogic.com/wp-content/uploads/2015/12/FlightWithVelocityCalcs.xlsx

Click to expand...

Minor suggestion. A trapezoidal integration would be more accurate. Not a big difference in this case.

View attachment Copy of FlightWithVelocityCalcs.trap.xlsx

Buckeye said:

Minor suggestion. A trapezoidal integration would be more accurate. Not a big difference in this case.

View attachment 277963

Click to expand...

Not many people know it, but AltimeterThree samples acceleration at 200 times per second, then time-averages the values and presents them at 20/s. The reason that I did that was to speed up downloads and reduce storage space, and to make graphing a little faster. By time-averaging the data, you preserve the "energy" of all of those samples and throw away much of the frequency content (which hardly anyone cares about). "Preserving energy" means that when you integrate the 20/s data you get the exact same result as if you had integrated the raw 200/s data. So when you calculate velocity by integrating (like in the spreadsheet), you get 200/s speed accuracy with 20/s data.

Good suggestion, but knowing this I would suggest NOT layering on another time-averaging technique (trapezoidal integration, which integrates the average of consecutive values) on TOP of the averaging that's automatically done, because it will just introduce some phase lag, not increase the accuracy.

Hope my explanation makes sense. I like that people think about this stuff, obscure as it is.

Obscure? I hope not. I have to use numerical integration techniques every day!