Quantcast

Interpret my data :) RRC3 + BRB900

The Rocketry Forum

Help Support The Rocketry Forum:

mlrtime99

Well-Known Member
Joined
Sep 28, 2013
Messages
54
Reaction score
4
Location
Scottsdale, AZ
So my RRC3 seems to be a bit enthusiastic with max velocity - View attachment 121716k675.rff

And I was hoping to get something a little more precise with my GPS BRB900 - View attachment 121716k675.kml but as expected there's GPS blackout from launch until near apogee. I threw the data into excel and found the largest delta and divided by time and end up with 2367m/12s or 197.25m/s but 12 seconds is and awfully large timespan to average data across. The 1132ft/s from the RRC3 just seems too high and the calculated 647ft/s too "average".

Anyone see any other way of getting more accurate data from these two sources?
 

markkoelsch

Well-Known Member
Joined
Mar 18, 2009
Messages
4,364
Reaction score
148
The gps is not really very useful here.

You likely need to use some data smoothing with the baro data.
 

SpaceManMat

Space Nut
Joined
Dec 20, 2013
Messages
666
Reaction score
48
RRC3 is a baro only unit so it is not a terribly good source for velocity. If this is important to you then I suggest you choose an altimeter with an accelerometer. GPS isn't going to help either.

There are 2 methods I would use to get estimates:
1. If you have built an accurate simulation model and it reasonably matches your altitude then the max velocity of the simulation will be close to the real thing.
2. Do some heavy filtering of the baro data to come up with more realistic velocity data.
 

Larry Curcio

Well-Known Member
Joined
Mar 5, 2009
Messages
538
Reaction score
0
Looked at the altimeter data. Put it through a Savitzky-Golay filter. That filter fits polynomials to a moving window of points. It then differentiates the polynomial to evaluate the derivative at the middle point of the window. It then shifts the window one point and does the same. SG gave essentially what the RR3 software got. (1107 ft/sec to be precise)

Looked at the temperature data. They describe the altimeter bay, and not the outside. Despite the ambiguity there, it's clear that temperature correction isn't going to lower the velocity.

Numerically differentiated data (altimeter data or otherwise) are inherently noisy. (Hence the filter.) Also, you get aerodynamic effects at the port under high speed. The rendered max velocity is very close to mach 1, and the trans-sonic region is the worst place to try to interpret barometric velocity data.

GPS altitude data have problems as well.

This may be about as good as it gets.
 

jderimig

Sponsor
TRF Sponsor
Joined
Jan 23, 2009
Messages
3,301
Reaction score
727
You can sim your flight in OR carefully entering the diameter and weight of the rocket. Adjust the Cd so that the sim matches your RRC recorded peak altitude. Get the peak speed from your sim and compare to your data.
 

markkoelsch

Well-Known Member
Joined
Mar 18, 2009
Messages
4,364
Reaction score
148
You can sim your flight in OR carefully entering the diameter and weight of the rocket. Adjust the Cd so that the sim matches your RRC recorded peak altitude. Get the peak speed from your sim and compare to your data.
Throw in launch rid angle, wind speed, and temperature.
 

mlrtime99

Well-Known Member
Joined
Sep 28, 2013
Messages
54
Reaction score
4
Location
Scottsdale, AZ
Thanks, guys. Definitely going to tweak my sim today as altitude was significantly higher than expected. I'll keep tweaking Cd until altitudes match and see what it thinks for velocity. Agreed an accelerometer is the next step to more accurate data.
 

SpaceManMat

Space Nut
Joined
Dec 20, 2013
Messages
666
Reaction score
48
Looked at the altimeter data. Put it through a Savitzky-Golay filter. That filter fits polynomials to a moving window of points. It then differentiates the polynomial to evaluate the derivative at the middle point of the window. It then shifts the window one point and does the same. SG gave essentially what the RR3 software got. (1107 ft/sec to be precise)

Looked at the temperature data. They describe the altimeter bay, and not the outside. Despite the ambiguity there, it's clear that temperature correction isn't going to lower the velocity.

Numerically differentiated data (altimeter data or otherwise) are inherently noisy. (Hence the filter.) Also, you get aerodynamic effects at the port under high speed. The rendered max velocity is very close to mach 1, and the trans-sonic region is the worst place to try to interpret barometric velocity data.

GPS altitude data have problems as well.

This may be about as good as it gets.
Interested to see your works here, do you have a spreadsheet you can share with us Larry?
 

Buckeye

Well-Known Member
TRF Supporter
Joined
Sep 6, 2009
Messages
2,624
Reaction score
475
Thanks, guys. Definitely going to tweak my sim today as altitude was significantly higher than expected. I'll keep tweaking Cd until altitudes match and see what it thinks for velocity. Agreed an accelerometer is the next step to more accurate data.
This plot show the beauty of numerical integration from accelerometer data. The red curve is noisy accel data from a Featherweight Raven. The blue is the integrated velocity data. The method is self-healing, unlike differentiating baro data which gets worse.

No extra smoothing or filtering is needed on the Raven data. I can nearly duplicate the velocity curve with a simple rectangle or trapezoid rule as is.

accel.vel.JPG


accel.vel.2.jpg
 
Last edited:

Buckeye

Well-Known Member
TRF Supporter
Joined
Sep 6, 2009
Messages
2,624
Reaction score
475
Yes, I think so. Use the attachments menu. Paper clip icon.
 
Top