Taking a shot at the G record

[bad_idea]

I could go to Texas or Phoenix before then but I'm not in that big of a hurry.

We'd love to have you down in Texas, but the air is awfully thick.

 

[Adrian A]

Adrian --

I imagine you're in decompression mode and you've got flight data to compare to your sims before you fly your G12, so no hurry, but before I forget to ask ...

Looking at your recovery pictures, your redesigned boat tail made it thru the F10 thrust phase without any damage at all.

You mentioned in Post #55 that you used a larger nosecone to make your boat tail:



Do you mind sharing the details of your boat tail when you can get to it ?

Thanks !

-- kjh

The process was pretty simple. I started with an Estes nosecone I had laying around (I don't know the model number) that had a diameter a bit larger than 29mm. I cut out a section of it where the large end was larger than the rocket and the small end was about what I wanted for the exit diameter, and then glued it onto the end of the F10 motor with some thickened epoxy (orange):



The above is a cartoon and not to scale, but just trying to show the idea.

Next, I just used a belt sander to sand down the tailcone to the right OD, and used a Dremel to clean out the inside surface and thin down the wall thickness a bit:



The tailcone is permanently attached to the motor. The tailcone on this flight did get a little distorted by the heat, but not a lot.

 

[Chuck Rogers]

I think I found the missing sim parameter in RASAero. The nozzle exit diameter input is used to simulate the elimination of the base drag where the motor plume is. The exit diameter of the motor itself is only about 0.2”. But if the motor eliminates the base drag for the whole tailcone exit area while the motor is burning (and the F10 has an 8 second burn) then the sim goes up over 14kft.

(A little late to the thread.)

Adrian:

In RASAero II the nozzle exit diameter is also used to vary thrust with altitude. (It is used for the nozzle exit area for varying thrust with altitude.) So the nozzle exit diameter must be the correct value, to match the thrust curve for the motor, to properly vary the thrust with altitude. RASAero II assumes the motor thrust curve is a sea level thrust curve, and as your launch site is above sea level, RASAero II will immediately start varying thrust with altitude right at ignition of the motor.

For a long burn motor, although a small motor (an F10), the variation of thrust with altitude could have a significant effect on the apogee altitude.


Charles E. (Chuck) Rogers
Rogers Aeroscience

 

[Chuck Rogers]

The process was pretty simple. I started with an Estes nosecone I had laying around (I don't know the model number) that had a diameter a bit larger than 29mm. I cut out a section of it where the large end was larger than the rocket and the small end was about what I wanted for the exit diameter, and then glued it onto the end of the F10 motor with some thickened epoxy (orange):

View attachment 610359

The above is a cartoon and not to scale, but just trying to show the idea.

Next, I just used a belt sander to sand down the tailcone to the right OD, and used a Dremel to clean out the inside surface and thin down the wall thickness a bit:

View attachment 610360

The tailcone is permanently attached to the motor. The tailcone on this flight did get a little distorted by the heat, but not a lot.

Adrian:

Great flight! And great flight data!

For postflight simulation comparisons, I'd start with using the base diameter of the boattail (the outside diameter of the structure attached to the motor), and use the actual nozzle exit diameter of the motor. This would be like assuming that the nozzle exit area is flush with the imaginary base area of the boattail.

Although there definitely could be some interesting flow effects going on inside the boattail.


Charles E. (Chuck) Rogers
Rogers Aeroscience

 

[Adrian A]

Attached is the RASAero model for this rocket, in case you'd like to play with it.
Below is the measured Cd using the method



I'm also attaching the data files from the flight.

 

[Chuck Rogers]

Thanks Adrian! I'll take a look at it.

Wow! An average subsonic CD of approximately 0.225. That's a really low CD.


Charles E. (Chuck) Rogers
Rogers Aeroscience

 

[Adrian A]

Thanks Adrian! I'll take a look at it.

Wow! An average subsonic CD of approximately 0.225. That's a really low CD.


Charles E. (Chuck) Rogers
Rogers Aeroscience

Yes, I was expecting something more in line with the RASAero estimate. I double-checked the calculations but another set of eyes would be nice.

 

[Buckeye]

Below is the measured Cd using the method

Impressive. What is "the method" you refer to? Care to post your Cd calculations (F = ma, I assume) for another set of eyes on that?

 

[kjhambrick]

@Adrian A --

I checked the Tripoli Records Search Tool and I am confused ...

Does the Tripoli Records Page confuse the Launch Site Altitude ( 8,800 ft MSL ) with your Apogee Altitude ( 10,136 ft AGL ) ?

Record Details: 8,800 ft - Single-Stage F - Single

Thanks and congratulations for making 'the list' again !

-- kjh

 

[Adrian A]

Impressive. What is "the method" you refer to? Care to post your Cd calculations (F = ma, I assume) for another set of eyes on that?

Here's a snip of the Matlab code I used:

top.axial_Gs = -top.raw_Gs,3)*1.012; %Tweaked to get inertial altitude to match GPS alitude

top.axial_velocity = cumsum(-1+top.axial_Gs)*32.17*.002;

%mass = 124.5 grams
dragforce = -.1245 * top.axial_Gs*9.81;
density = interp1(wyo_atm,2),wyo_atm,4),accel_alt);
vms = top.axial_velocity*.3048; %velocity in m/sec
area = pi*(1.16/2)^2 * .00064516; %area in meters squared
Cd = 2 * dragforce./density./vms.^2/area;

@Adrian A --

I checked the Tripoli Records Search Tool and I am confused ...

Does the Tripoli Records Page confuse the Launch Site Altitude ( 8,800 ft MSL ) with your Apogee Altitude ( 10,136 ft AGL ) ?

Record Details: 8,800 ft - Single-Stage F - Single

Thanks and congratulations for making 'the list' again !

-- kjh

Thanks. LOL. I think someone put the wrong number in the wrong database form entry.

Also, here is the RASAero motor file I have been using:

 

[kjhambrick]

@Adrian A --

Was the launch mass 124.5 grams ?

EDIT: never mind, I found the answer in your G Record 2023.CDXL file attached to Post #123

The Launch mass was 0.36 Lb = 163.6 grams.

Given an F10 propellant mass of 40 grams, that would make the COAST mass about 124.5 grams ...

Do you have the motor mass before and after the flight ?

Thanks !

-- kjh

top.axial_Gs = -top.raw_Gs,3)*1.012; %Tweaked to get inertial altitude to match GPS alitude

top.axial_velocity = cumsum(-1+top.axial_Gs)*32.17*.002;

%mass = 124.5 grams
dragforce = -.1245 * top.axial_Gs*9.81;
density = interp1(wyo_atm,2),wyo_atm,4),accel_alt);
vms = top.axial_velocity*.3048; %velocity in m/sec
area = pi*(1.16/2)^2 * .00064516; %area in meters squared
Cd = 2 * dragforce./density./vms.^2/area;

 

[Buckeye]

I'm also attaching the data files from the flight.

I replicated your Matlab calculations in Excel. I used the Standard Atmosphere Model for density, rather than the balloon soundings from University of Wyoming. I also just estimated the Mach Number as simply vms/343 m/s. I got a Cd curve like this. Very similar.

Not sure it makes a difference, but I would use a trapezoid rule for integrations, rather than rectangular. I think it is called "trapsum" in Matlab.

 

[Buckeye]

I'm also attaching the data files from the flight.

I noticed some discrepancies on the timestamps in the data files. On the high_rate data, Flight_Time of 0 already has an acceleration of 10 G's. I would say the correct liftoff is at t = -0.032, where the acceleration first moves off of the static value of 1.00 and begins increasing.



Also, the low_rate burnout flag is raised at flight time t = 8.24 s. However, this time doesn't jive in the high-rate file. I would say burnout in the high-rate file occurs at flight time t = 8.152 s where the acceleration changes from positive to negative.



Nonetheless, these data files have a ton of good info for post-processing! Nice!

 

[waltr]

I think the Accel data units are m/s/s which would ideally make Accel_Z = -9.81.
So -10.8 would be a -0.99 offset error.

 

[Adrian A]

I noticed some discrepancies on the timestamps in the data files. On the high_rate data, Flight_Time of 0 already has an acceleration of 10 G's. I would say the correct liftoff is at t = -0.032, where the acceleration first moves off of the static value of 1.00 and begins increasing.

View attachment 612783

The data files use the on-board algorithm, which detects liftoff when the velocity meets the threshold of 3 feet/sec if I recall correctly. However, even before liftoff detection the gyros and accelerometers work together to do the inertial navigation. The next build will include new software that delays the liftoff detection until the rocket has moved 2.5 feet in addition to the other criteria. The main reason for this change is to improve the accuracy of the measurement of the rocket rail direction, which is used in the rest of the flight as the rocket axis for the tilt angle calculation.

Also, the low_rate burnout flag is raised at flight time t = 8.24 s. However, this time doesn't jive in the high-rate file. I would say burnout in the high-rate file occurs at flight time t = 8.152 s where the acceleration changes from positive to negative.

View attachment 612785

Agreed. The burnout detection algorithm looks for a 5 ft/sec reduction in the velocity rather than just a negative acceleration, to prevent false positives from motor noise, sticky rail, etc. that could otherwise cause premature burnout detection.

Nonetheless, these data files have a ton of good info for post-processing! Nice!

 

[Adrian A]

Thanks. LOL. I think someone put the wrong number in the wrong database form entry.

This has since been corrected.

https://www.tripoli.org/content.aspx?page_id=1537&club_id=795696&item_id=497622

 

[Adrian A]

I think the Accel data units are m/s/s which would ideally make Accel_Z = -9.81.
So -10.8 would be a -0.99 offset error.

The accel data are in Gs. You can see 1 G magnitude before ignition.

 

[kjhambrick]

THANK YOU @Adrian A for sharing the raw high_rate and low_rate files !

I've been playing with them since last week so I could finally convert my old AltAcc PROGRESS and PROPULSE scripts for the latest Blue Raven file formats.

PROGRESS calculates the coast-phase drag force normalized for the calculated rocket mass, air density and mach number -vs- velocity to extract the drag -vs- velocity data, similar to the CD -vs- Velocity plots that you and @Buckeye showed above.

PROPULSE normalizes motor thrust by factoring in rho-normalized drag -vs- velocity from the output of the PROGRESS output to produce a thrust curve for the flight.

Motor Ignition -vs- Liftoff Detect is VERY difficult for the flight computer to determine in real time.

It is a lot easier when one can eyeball the data 'from the armchair' after the flight.

If you squint at Adrian's high_rate rows with your eyes crossed just right, you can ALMOST see that the ignitor probably fired around t = -0.090 sec and that the motor smouldered for 0.058 seconds until t = -0.032 sec, as @Buckeye said, when the rocket finally overcame gravity and started moving up the tower.

But I don't know how one could do any better in real time than the Blue Raven firmware did in flight without jeopardizing the most important function of the flight computer which is apogee detection with almost absolute reliability.

There will be odd exceptions to any rule that one can imagine for launch detect.

For example, see some of the high-speed videos that @Last Ox has posted where the rocket chuffed, then stopped in mid-air then bounced on the pad or took off in a random direction ... I don't know if there is any way to code around such events in the flight computer's firmware.

For example: This or even worse, This would be pretty hard to code around in a flight computer ...

And then there was my level 1 re-cert flight on a 25-year old H128 that smoldered for 10-sec, chuffed hard twice, banged down on the pad and then finally lit: Blue Raven Saves Spock's Johnson

The Blue Raven saved my rocket because it ignored the chuffs and accurately detected apogee ( thanks Adrian )

Flight profiles like these haunted me when I was coding the firmware for the AltAcc until I gave up and realized there was no way to catch them all ...

And motor cutoff is just as hard to determine because there are probably a few milliseconds at the end of the burn where drag exceeds thrust and the rocket is decelerating even though the motor is still producing thrust.

It is getting busy at work now so I haven't had time to finish PROGRESS and PRODUCE but I am getting there ...

I'll post something 'soon' -- maybe after my level 2 re-cert attempt this weekend ???

Thanks again for sharing that raw data !

-- kjh

 

[Buckeye]

The data files use the on-board algorithm, which detects liftoff when the velocity meets the threshold of 3 feet/sec if I recall correctly. However, even before liftoff detection the gyros and accelerometers work together to do the inertial navigation. The next build will include new software that delays the liftoff detection until the rocket has moved 2.5 feet in addition to the other criteria. The main reason for this change is to improve the accuracy of the measurement of the rocket rail direction, which is used in the rest of the flight as the rocket axis for the tilt angle calculation.



Agreed. The burnout detection algorithm looks for a 5 ft/sec reduction in the velocity rather than just a negative acceleration, to prevent false positives from motor noise, sticky rail, etc. that could otherwise cause premature burnout detection.

Ah, I see. Makes sense for the onboard algorithm to have different criteria (safety) than the post-processing data.

Aside: I tried to compute CD from my Raven data a couple times, but the end result was always a mess. I think I was prematurely chopping off the thrust portion from the data and integrating starting at burnout. Duh. Your little snippet of code helped me catch my error. Thanks!

 

[Adrian A]

And then there was my level 1 re-cert flight on a 25-year old H128 that smoldered for 10-sec, chuffed hard twice, banged down on the pad and then finally lit: Blue Raven Saves Spock's Johnson

The Blue Raven saved my rocket because it ignored the chuffs and accurately detected apogee ( thanks Adrian )

Flight profiles like these haunted me when I was coding the firmware for the AltAcc until I gave up and realized there was no way to catch them all ...

Exactly. It's hard to appreciate everything the altimeter needs to do on the pad until you've coded it. During pre-launch the Blue Raven does have drop detection, where if the G magnitude goes below 0.8 Gs, it will ignore subsequent accelerations for the same amount of time it was in free-fall. Then there's the need to reset the velocities and positions when it's been quiescent on the pad. And update the estimate for accelerometer offsets. And gyro offsets. And always ignore the motions you get when you're carrying it around but never ignore the motion of a real liftoff.

 

[waltr]

The accel data are in Gs. You can see 1 G magnitude before ignition.

Ok, I'll look at the data again.

Yes, what the code needs to look at and do is not that easy. I have a data logger that detects launch etc and getting this is work well is much easier than doing a full flight computer code.

 

[Chuck Rogers]

Attached is the RASAero model for this rocket, in case you'd like to play with it.
Below is the measured Cd using the method

View attachment 611761

I'm also attaching the data files from the flight.

Adrian:


Using the RASAero II .CDX1 file that you posted, and changing the Nozzle Exit Diameter to the actual value of 0.20 in for the F10 motor, thrust is properly varied with altitude, and the existing RASAero II Power-On Delta-CD Models and Boattail Models are used.


I'm assuming the "actual" altitude of the flight is 10,136 ft (the GPS data) Above Ground Level (AGL). Please correct this, if this is incorrect.


Using the Rounded Airfoil included in the .CDX1 file (the actual Airfoil that was used), and also running the file with a NACA Airfoil, I get the following results.


Actual Altitude = 10,136 ft

RASAero II Predicted Altitude - Rounded Airfoil = 8,937 ft (-11.83% Error)

RASAero II Predicted Altitude - NACA Airfoil = 11,294 ft (+11.42% Error)

RASAero II Predicted CD - Rounded Airfoil = 0.325 (Average Subsonic)

RASAero II Predicted CD - NACA Airfoil = 0.225 (Average Subsonic)


My assessment is that your rocket indeed had a very low CD. It could have been 0.225, and the prediction would be 0.225 if a NACA Airfoil had been used. Obviously, a Rounded Airfoil adds Subsonic Drag to the Drag from the NACA Airfoil. What's apparent is that the RASAero II Rounded Airfoil Subsonic Drag Model adds too much drag, and subtracts too much altitude from the prediction.


There could be some interesting things going on with the Boattail, especially Power-On, but the Power-Off Base Drag is probably correct despite the unusual Boattail arrangement. I think the current RASAero II Rounded Airfoil Subsonic Drag Model is probably too conservative. (Square Airfoil and Rounded Airfoil Subsonic Drag Models are difficult to develop.)


For planning your G flight, I'd run the rocket with a Rounded Airfoil (the actual Airfoil), and a NACA Airfoil, and your actual altitude will probably be half-way between the two altitudes.



Charles E. (Chuck) Rogers
Rogers Aeroscience

 

[Adrian A]

Thanks Chuck. The actual profile is close to biconic; I applied a thin stiffening secondary layup to the middle area of the chord, then some thickened epoxy over everything and then shaped it smooth with hand sanding with a pretty sharp leading and trailing edge, maybe 10-20 thousandths radius.

 

[Chuck Rogers]

Thanks Chuck. The actual profile is close to biconic; I applied a thin stiffening secondary layup to the middle area of the chord, then some thickened epoxy over everything and then shaped it smooth with hand sanding with a pretty sharp leading and trailing edge, maybe 10-20 thousandths radius.

Adrian:


I re-ran the rocket on RASAero II. I now get:


Actual Altitude = 10,136 ft

RASAero II Predicted Altitude - Rounded Airfoil = 8,937 ft (-11.83% Error)

RASAero II Predicted Altitude - NACA Airfoil = 11,294 ft (+11.42% Error)

RASAero II Predicted Altitude - Biconvex Airfoil, 0.02 in Leading Edge Radius = 11,368 ft (+12.15% Error)


But it's clear that your rocket did not out-fly the RASAero II flight simulation with reasonable modeling. Your apogee altitude is a solid, believable record.


Charles E. (Chuck) Rogers
Rogers Aeroscience

 

[Adrian A]

I flew Half Fast again today, with the G12 this time. 15,080 feet. However, the chute got stuck so I’m not submitting the flight for a record. No damage to the rocket, so I’ll try again in early May.

 

[kjhambrick]

I flew Half Fast again today, with the G12 this time. 15,080 feet. However, the chute got stuck so I’m not submitting the flight for a record. No damage to the rocket, so I’ll gray again in early May.

Holy cow, @Adrian A !

That's just about 50% higher than the current G - Single record ( Brian Duke - 10,093 ft ).

Looking forward to drooling all over your data

-- kjh

 

[Ron Soto]

I flew Half Fast again today, with the G12 this time. 15,080 feet. However, the chute got stuck so I’m not submitting the flight for a record. No damage to the rocket, so I’ll gray again in early May.

Wondering about your recovery efforts.. are you using gps? Or?

R

 

[Adrian A]

Here’s how it landed.

 

[tfischer]

Sorry about the chute, but a great flight Adrian!

 

[Adrian A]

Wondering about your recovery efforts.. are you using gps? Or?

R

I'm using a Featherweight GPS tracker.

The charge was sized correctly, and the shock cord broke the reefing tape and fully extended, but in an oversight, I tied the chute too close to the forward end so that it was not pulled out of the forward coupler when the shock cord went taut. This is the same configuration I had for the F record, but I think I just got lucky that the chute shook out. This will be easily remedied before the next flight, in about 2 weeks, weather permitting.

Attached are the data files from this flight