Calculations

I was wondering if anyone has calculated cp and modeled rocket flight using a spreadsheet? I am considering building a rocket for a freshman engineering class but I will need to make a spreadsheet to do the work. I would actually design the rocket using openrocket but the spreadsheet will be where my grade comes from.

I am going to propose a project where I will build a rocket that flys 2640 feet and be graded on how close I come to that goal with points being deducted for every foot off, points for the spreadsheet and how well designed it is (how clean it looks and how easy it would be for someone else to use and interpret the results), and the the rocket itself. Altitude will be recorded using an altimeter

Ive taken cal 1, 2, and am currently taken 3, along with physics w/ cal 1.

Too much for the average student? Or just a huge pain in the butt?

There's a Barrowman spreadsheet near the bottom of this page:

https://my.execpc.com/~culp/rockets/Barrowman.html

Thanks for that. The barrowman equations don't seem to been that bad but I can't seem to find any for predicting altitude.

I did a search using the terms "rocket altitude prediction" and had numerous hits. The equations are out there and easily found.

I use EXCEL spreadsheets to perform a lot of analyses, but I usually don't worry about what they look like to anyone else (hey, they're spreadsheets). I doubt anyone would want to wade through my notes anyway. I would be happy to try to answer what questions I can-

I can tell you that when programming flight simulations, your results/accuracy are going to be highly sensitive to many of the little assumptions made in the spreadsheet and inputs. If you use "standard atmoshphere" data (and don't bother with your local barometric pressure, humidity, etc) there goes one source of error. If you don't have a good way to determine a realistic value of drag coefficient (and lots of folks tend to be way optimistic about their modeling/finishing skills) there goes a BIG usual source of error. If you do not make a thorough model of your fin aerodynamics and effectiveness, the inertia values of the rocket, stability characteristics, and the dynamic flight response to gusts and disturbances (in other words, how much energy does your rocket waste wobbling around), you can have more estimation problems.

The overall solution to all this is to analyze what you can in your spreadsheet, fly the rocket with some onboard electronics (altimeters, barometers, accelerometers, recording media), try to match up the mathematical model with the "real world," launch again, tweak the spreadsheet some more, launch again, tweak again....you get the idea. A good analytical model is going to take some work.

I didn't even think about ballistic coefficient. How would one go about estimating it? This is going to be a small diameter rocket, 29mm, and I am using 24mm motors. I've got a pack of estes E motors and I guess I could use them for the first few launches to help estimate my BC. I would use local data at the launch site for the final inputs.

"If you do not make a thorough model of your fin aerodynamics and effectiveness, the inertia values of the rocket" You lost me there, please explain a little more. I am pretty new to rocketry.

How good is your college library?

You might want to browse:

Handbook of Model Rocketry, 7th Edition

The Theoretical Prediction of the Center of Pressure

What Barrowman Left Out

Topics in Advanced Model Rocketry

To span the range from basics/historical through more complicated, and then decide how committed to the spreadsheet you can afford to be within the time you have for the project. There are a lot more references out there, I just grabbed a handful.

claytonfaulkner said:

... I am going to propose a project where I will build a rocket that flys 2640 feet and be graded on how close I come to that goal with points being deducted for every foot off, ...

Click to expand...

If I was faced with a 100 point grade scale I wouldn't want to give up 1 point per foot without some sort of cap on the deduction!

Like any other mass-produced product, your pack of E9s have tolerances ... If your ejection charge deploys the chute a bit early and your peak altimeter reports as 2620 instead of 2640, you are down to a "C" grade at best?

Or you weathercock 5 degrees off of vertical into the wind as your rocket leaves the launch rod?

If you can't avoid unlimited deductions, lobby for results based on the average of 9 flights on three separate days or some such. Better yet, propose a project along powerburner's line of thought, where grade is based on refining the model to match the experimental data. Either ought to have some appeal to your instructor.

I just checked and we have Handbook of model rocketry, 5th edition. Couldn't find that last one.

I submitted a proposal today and said I would like the points to come from 3 seperate sources. The build quality of the rocket, the spreadsheet and calculations, and then how close I come to the goal of 2640 feet. For the actual points flight I will either use a aerotech or cti reloadable motor.

The class is set up very strange. Basically we are given a bunch of projects that we can work on our own and get the points. The class is outs of 1000 points and I need to get to 970 for an A+. Even if the rocket fails I should still be able to overcome and do other projects to get the points. I will only go through with it if she will allow enough points to make it worth my effort.

I think if you are going to come anywhere close (a whole separate subject; see the comments about TARC below) you are going to have to account for everything you can.

I expect you will need to use the thrust curve data from the NAR motor pages and create/adapt their data to model the burn at increments something like 1/10th or even 1/100th of a second. Especially around the initial thrust peak, you are going to have to model the thrust carefully.

Weight of the model rocket will probably be the largest influence on accel, velocity, displacement, and all the rest. To this end, you will likely need to model the expenditure of propellant weight through the burn. You could use a simple linear model (weight v.s. time), you could assume the propellant leaves in proportion to thrust level (area under the thrust curve within each selected time interval), or some other mathematical model that makes you happy. You will also have to represent the burn of the delay charge, probably assuming that those combusted materials exit the nozzle and are not re-deposited somewhere inside the combustion chamber (OK everyone else, how does that assumption fit your experience?).

What I meant about fin aero, inertias, stability, and dynamics is that you will need to make some sort of accurate representation of your fin airfoiling, streamlining, leading edge shape (which affects how well the fin functions to provide stability), and how all this stuff plays in the dynamic response of the model rocket in flight. If you have square fin edges versus rounded leading edges, if you have precision fin alignment (as in, use a fin jig during assembly), if you have a clean forebody and smooth flow hitting the fins from upstream, all these things will affect how well they work. On top of that you would have to use some representation of "random" wind gusts that might try to upset the flight path and calculate the amount of off-axis flight that has to be corrected by the fins (where the fins operating at some increased angle of attack to generate the restoring forces will also generate some additional increment of drag).

Do you have access to an atmosphere model (altitudes, pressures, density data, temperatures, etc)? I think the ones that I have are only split out at altitude deltas of something like 500 ft (maybe 1000 ft) and you would have to plot a trend beyond your working altitude zone and interpolate for the data you need. Do you have access to meteorology instruments that you can take to the launch site and measure temps, humidity, baro pressure, etc? If your overall flight target is to some 2600 ft, variations in atmosphere can easily cause +/- 10-20-30 feet in your altitude estimates.

You will need to order a batch of motors (or RMS reloads) that hopefully come from the same production batch. This is to try to minimize the variations in motor performance that arise from batch-to-batch tweaks and foibles in production. And as hard as you try to reduce these effects, some of them will still creep in.

You are going to have to be precise in the consistency of your igniter prep, installation, and ignition power. Igniter performance is one more variable that can cause changes in motor performance. Isn't this fun?

This thing rapidly turns into a Master's thesis level of sophistication to properly account for all the effects, especially if you will be graded down one percent for every foot of altitude error. I mean, look at the TARC results and you will see that out of 100 teams, only two or three usually even get close to the target requirements, and that is with a team of people working on the project. I would be fairly amazed if you could complete this entire task and come within 50 feet closure between your estimated and actual. I don't want to say it cannot be done but it sure is a tough project for one person to take on if the grading scale is going to be so severe.

What if I was to cheat a little. Lets say I get some equations down, make assumptions and estimations where necessary, and then launch. Then compare my predicted altitude with actual altitude and add in some sort of correction factor. Would it work? Even if I am off by a few 100 feet I should still get plenty of points. I would also be getting plenty of points from the spreadsheet and the rocket itself. The class isn't based on percentages, just points earned. Lets say I did 20 projects that were 100 points a piece. If I only got 50% on each project I would still get an A+ in the class. It's a freshman class designed to get us interested in engineering and pad our gpa.

As for temp pressure and humidity, I can get it all on site and pretty accurately.

Just to get on the same page, have you studied F=ma?
Do you know what a free-body diagram is?
Have you ever seen the equation (drag) = (1/2) (rho) (v-squared) (S) (cd)
Do you know what any of those variables are?

Have you picked one motor to use for this flight?
Do you have a specific rocket design selected?
For that model rocket, have you built at least one, and do you have an actual weight of that rocket (loaded in launch condition)?

powderburner said:

Just to get on the same page, have you studied F=ma?
Do you know what a free-body diagram is?
Have you ever seen the equation (drag) = (1/2) (rho) (v-squared) (S) (cd)
Do you know what any of those variables are?

Have you picked one motor to use for this flight?
Do you have a specific rocket design selected?
For that model rocket, have you built at least one, and do you have an actual weight of that rocket (loaded in launch condition)?

Click to expand...

I know what force is

I drew so many free body diagrams in statics last semester that I could do them in my sleep.

Unless that equation is some times written another way then no, but I do recognize that it looks like an extended formula for kinetic energy.

I have not picked a motor.

I have made a drawing in Openrocket, I ordered the tube today with more parts coming after I get the approval to go ahead from the professor.

I can calculate the weight but I know empirical would be better. I can weight every thing on scales at school.

claytonfaulkner said:

What if I was to cheat a little. Lets say I get some equations down, make assumptions and estimations where necessary, and then launch. Then compare my predicted altitude with actual altitude and add in some sort of correction factor. Would it work?

Click to expand...

Maybe, but probably not all that well. If you study the list of variables powderburner has described, you'll see that some of them are outside your control, meaning you won't know if they are going to add or subtract altitude on any given flight. You would have to do multiple launches to get an average before coming up with the fudge factor. The "FF" would compensate for fixed variables (oxymoronic, I know . . .) like weight and drag (not ballistic - that's for bullets and is different) coefficient.
Having your score based on the average of multiple flights rather than a single flight would be to your benefit for the same reason. If I was the instructor, I would ask you to explain the reasons for the variations in the results.

P.S. Glad to see that you have a solid grasp on FBDs. That's one of the key things I look for in a hiring interview of a mechanical engineer.

Sorry for the messed up nomenclature, I'm sure you can figure out a few of my other hobbies. I am a civil engineering major so I haven't taken any aero classes.

As for free body diagrams, its good to know that some of this stuff might be useful for me one day.

Clayton,

I should be ready to start posting some info later tonight or tomorrow. I've been working with a Microsoft EXCEL spreadsheet, so we're gonna be sunk if you can't follow along on that.

There will be homework.

I will doubtless leave some mistakes in the middle of all these calcs, but they will be there "on purpose" as an exercise for the alert analyst....

Right now, it's dinner time & I am hungry. Tune in later-

claytonfaulkner said:

I was wondering if anyone has calculated cp and modeled rocket flight using a spreadsheet?

Click to expand...

Actually, many people have done this. I haven't seen too many publish the gory details, but since this question seems to come up often I thought it could be worth plowing through. Maybe if we collaborate on a spreadsheet example we could all build on it or add modifications.

claytonfaulkner said:

Or just a huge pain in the butt?

Click to expand...

You're going to have to decide that for yourself at the other end of this--

The example I am showing is a performance check I wanted to do for a design I was thinking about. I wanted to see how a 7-motor cluster would work, and if this whole project looked do-able. The calculations are basically the same thing you are going to need for your project.

As to calculating center of pressure, there are a couple approaches that are within reach of the average guy:

1) You can use the cardboard cutout method--you literally make a cardboard cutout of the profile of the rocket and balance it to find the longitudinal center of area, which is a conservative estimate of the location of the center of pressure. Some folks don't seem to like it, I don't know why, maybe because it reminds them of cutting out paper dolls and looks too silly? This approach works fairly well, but probably tends to give results that are more conservative (that is, your rocket may be over-stable). It has a few tricks if your rocket has a complex shape (like tube fins) but for the average 3-fins-&-a-nosecone, it works OK.

2) Barrowman stability equations--and yes, you CAN do it yourself, it does not require a master's degree to run the math. They are published in several sources, and are available free on the web at
https://my.execpc.com/~culp/rockets/Barrowman.html
I point out that specific website because it has a good, simple illustration and a list of input parameters. I refer to this web page in my example below. This analysis demonstrates the basic stability effects of the pertinent rocket parts (nose cone shape & location, fin size/number/span & location, etc). It is fine to use preprogrammed C.P. calculations but I think it would do anyone good to run through the Barrowman calcs a few times with paper & pencil & calculator to get a better feel for the design features that drive the stability characteristics.

3) Web spreadsheets and simulations--there are bunches of 'em. Assuming they are programmed correctly, they should work just fine for you. Most are based on the same Barrowman equations that you can run yourself, but it is OK to use someone's handy stability calculator too.

4) Peek at someone's rocksim file (this is actually CHEATING!!) to get an indication of where they think the C.P. is located. Your rocket had better be a pretty close copy (or an exact copy) before this works, though, and you are still trusting that someone else's work was done correctly.

5) Get a degree in Aerospace Engineering and apply your coursework from the Stability & Control classes. Way more effort than most folks are willing to invest. Way more effort than a model rocket is worth anyway.

Next, you will need to know the center of gravity of your rocket. For almost all designs, this will actually be a "moving target" because the ejection of propellant from the nozzle will make for a constantly-changing balance point. From a practical standpoint, this is a fairly negligible effect (or just about completely negligible) for most model rockets and even many mid-power birds. You have to get into some really substantial motor sizes (where propellant weight is a significant percent of total launch weight) before you usually have to get concerned with C.G. travel.

You can get a working C.G. from several different approaches:

1) Build the rocket, prep it for launch (motor, wadding, recovery system, electronics, batteries, and all other components in place), hold it level and balance it on a fulcrum. This pretty much gives a final, indisputable location for the C.G. On the other hand, if your built design ends up having a C.G. location that indicates an unstable condition, you sort of have to scrap the whole thing and start over. Unless...

2) Build the rocket, prep it for launch, hold it level, balance it on a fulcrum, find an initial C.G. location, and then add ballast to the nose or tail to adjust the C.G. to where you need it. If you only need to add a small amount of ballast weight this may not be such a bad approach. If you need to add gobs of ballast (what aero engineers term an "inelegant" solution) your rocket could well end up unusable (too much weight for the motor to lift).

3) Calculate the weight and balance of your design before you build it. The calculations are not difficult (see: https://www.rocketryforumarchive.com/showthread.php?t=3379). You can also use simulation software such as rocksim to perform this estimation, assuming your design uses standard parts already programmed into their library.

Next: What do you do with C.P. and C.G.?

from what i understand of it. is that CP moves both with angle of attack, and velocity.
for this, i use the max velocity i expect from a rocket with a 5degreee AOA, and use that to mark my location for 'farthest aft CP'.

This was brought to my attention by RASAERO. plots utility.

if you read that manual they will show you where they get thier stability equations from, which is a Military guide to design of freefall aerodynamicly stablized rockets.

I’ll say this part right up front, in case you want to skip the rest of this particular post: The values (locations) of center of pressure and center of gravity DO NOT ENTER DIRECTLY INTO THE ROCKET PERFORMANCE CALCULATIONS. The importance of C.P. and C.G. have more to do with how well (straight and steady) the rocket flies and are only reflected as secondary influences through the values of coefficient of drag.

OK, now I better explain that. I am assuming that you are designing a rocket to safely and reliably deliver performance as close to optimum as you can get, otherwise why would we be bothering to analyze the thing. I cannot see any sense in deliberately designing a rocket with marginal stability that has a wobbly, twisty, or corkscrewy flight path. (Maybe as a novelty or oddball item, but BE CAREFUL and be sure to test-fly the thing to death by yourself before you bring it to a group launch.) So assuming that the rocket flies straight (or very nearly so), it would not spend any significant portion of its flight in a yawed or non-optimum condition. The rocket would spend the entire time at small yaw angles of one or two degrees (or zero) and the drag increments for yawed flight would be negligible.

Big assumption? Maybe. But a rocket design with a small stability margin (where small is bad) can be easily remedied by adding a bit of aft fin area, or shifting existing fins aft, or shifting some of the internal components forward, or adding nose ballast (a small amount). There is little or no reason, especially if you are starting from a “clean sheet of paper,” to have a conventional rocket design with poor stability characteristics. To screw that up, you almost have to be trying on purpose.

So does this make a convenient excuse for me to ignore further discussion of C.P. and C.G.? Probably, but let’s look at them anyway.

The center of pressure needs to be located behind the center of gravity by a distance that is large enough to make the rocket aerodynamically stable. For a conventional three-fin-and-a-nosecone (3FNC) design, with a conventional constant-diameter body tube, we often “normalize” these distances (turn them into a dimensionless measurement that applies generally to all designs) by dividing that distance by the body tube diameter. So a BT60-based design with a C.G. that is 3.1 inches ahead of the C.P. would be said to have a stability margin of 1.9, or (3.1)/(1.64). The rule-of-thumb for conventional rocket designs is to go for a stability margin of around 1.5 to 2.0.

This does NOT mean that a design with a margin of 1.4 or 2.3 will be unstable or unsafe, but you would still generally prefer to get back into that nominal range (the 1.5 to 2.0 thing). With the flexibility of designing a new model rocket there is little reason not to be able to tweak the fin area (or something) to achieve this.

A smaller stability margin means that the rocket design will tend to correct slowly from a yaw offset back to a straight-ahead line of flight. A near-zero stability margin theoretically means that a rocket deflected to some yaw offset angle would remain there for the rest of the flight and not ever “correct” back to straight-ahead flight.

A larger stability margin could be an OK thing if winds at the launch site are still. However, rocket designs with excessive stability margins have a demonstrated tendency to turn more strongly into any available crosswinds. Extra stability margin plus strong crosswinds equals more weathercocking. This not only reduces peak altitude but can quickly turn the rocket toward horizontal flight, and coasting during the motor delay burn will likely be downhill. Under these conditions, ejection can easily occur at unsafely low altitudes….or after the rocket has already landed/impacted.

Having said all that, let me toss in some complicating considerations. Stability margin is not the complete story, especially for designs that are short and fat (as in the Estes Fat Boy and Big Daddy), or for designs that are long and skinny (as in the Estes Mean Machine). Rocket designs with low or high “fineness ratios” (ratio of length to body diameter) tend to follow slightly different rules when it comes to stability margin. A short/fat design can often have a stability margin that seems to be too small, but the base drag from the bluff aft end creates its own kind of stabilizing influence. A long/skinny design will usually have (relatively) high pitch/yaw inertias and will respond more slowly to side gusts than shorter rockets do, and once they begin pitch/yaw rotation (in response to the wind gusts) they tend to continue it longer and respond more slowly to the corrective actions of the fins if designed with the same stability margin, so some are designed with greater margins. If you want to read more on stability adjustments, check out:
Simulating Short Wide Rockets https://www.apogeerockets.com/education/downloads/Newsletter162.pdf
What Barrowman Left Out https://www.if.sc.usp.br/~projetosulfos/artigos/sentinel39-galejs.pdf
Advanced Topics in Model Rocketry https://dspace.mit.edu/bitstream/ha...d=427DA99EA64ECE8DEBE40A972E196050?sequence=2

Because I am a huge fan of simple (in other words, I am lazy) we are going to assume our conventional 3FNC model rocket is built with fins on straight, reasonably airfoiled, with an exterior surface that is finished smoothly, and with a motor mount (and thrust axis) that is properly aligned with the overall rocket. I am going to assume for flight performance analysis that it flies straight or has negligible yaw at any point in the flight. But what if it did wobble a little?

In terms of our flight performance simulation, it would be possible to account for the drag increment due to yaw by making a small mark-up to the assumed drag coefficient (something like +2%? +4%?) and re-running the simulation until estimated performance results seem to match up with actual observed/measured. Or, instead of marking up the drag coefficient for the entire flight, you could alternately go to the portion of the flight where “wobble” was observed in the flight path and add an increment to the drag coefficient for only that portion.

Bottom line: If your rocket has a reasonable C.P.-C.G. relationship and flies mostly straight and smoothly then there will be relatively little drag, speed, or altitude impact due to the location of C.P. or C.G. on your rocket design. (Wait until you see the simulation spreadsheet and what rocket weight does to the results!)

This subject is discussed in considerable detail in a series of articles in the old Model Rocketry magazine. These technical papers can be found free at
https://www.ninfinger.org/rockets/ModelRocketry/ModelRocketry.html
Fundamentals of Dynamic Stability https://www.ninfinger.org/rockets/ModelRocketry/Model_Rocketry_v01n01_10-68.pdf
Fundamentals of Dynamic Stability https://www.ninfinger.org/rockets/ModelRocketry/Model_Rocketry_v01n02_11-68.pdf
Fundamentals of Dynamic Stability https://www.ninfinger.org/rockets/ModelRocketry/Model_Rocketry_v01n03_01-69.pdf
Fundamentals of Dynamic Stability https://www.ninfinger.org/rockets/ModelRocketry/Model_Rocketry_v01n04_02-69.pdf
Fundamentals of Dynamic Stability https://www.ninfinger.org/rockets/ModelRocketry/Model_Rocketry_v01n05_03-69.pdf
Fundamentals of Dynamic Stability Corrections https://www.ninfinger.org/rockets/ModelRocketry/Model_Rocketry_v01n06_04-69.pdf

You may also want to read some of the info posted by Apogee:
Over-Stable Rockets https://www.apogeerockets.com/education/downloads/Newsletter05.pdf
Why Do Rockets Go Unstable? https://www.apogeerockets.com/education/downloads/Newsletter42.pdf
Fin Thickness Effect on C.P. https://www.apogeerockets.com/education/downloads/newsletter79.pdf
C.P. Changes for Upscale Rockets https://www.apogeerockets.com/education/downloads/Newsletter80.pdf
Stability of Short Squat Rockets https://www.apogeerockets.com/education/downloads/Newsletter86.pdf
What Is Static Margin https://www.apogeerockets.com/education/downloads/newsletter133.pdf
Simulating Short Wide Rockets https://www.apogeerockets.com/education/downloads/Newsletter154.pdf
Issues #192 – 198

ClayD said:

Doesn't C.P. move?

Click to expand...

Yes, you are correct, it does indeed move. You mentioned some of the largest influences on the position of the C.P. and there are others. If you have a very large rocket (5-10 feet and up), or a very fast rocket (transonic-supersonic & beyond), or a rocket with a very complicated configuration, the shift in C.P. can begin to become significant. However, I am going to keep this whole thing simple and only going to address a basic model rocket, subsonic flight, three-fins-and-a-nosecone conventional design. For this case, C.P. movement is pretty close to zero for all practical purposes.

You raise another influence on C.P. shift and that is the yaw angle of the rocket. While the center of pressure does shift somewhat as a function of yaw (or sideslip, or angle-of-attack, or lateral gust component velocity, or whatever term you want to use) I am again going to try to keep things simple and assume that our model rocket experiences only small yaw angles of one or two degrees maximum. Yeah, that’s cheating. If you want to investigate the effects of larger yaw angles it can get pretty complicated pretty fast.

At any significant yaw angle, where one (or more) of the fins is offset to some non-zero angle-of-attack, that fin acts as a wing or lifting surface until the rocket returns to straight-ahead flight. The aerodynamic lift force generated by the fin acts primarily sideways on the rocket, to pivot the rocket (which rotates about its own C.G.) back toward zero AoA. Because the fin is functioning as a wing, a subsonic rocket works best with rounded fin leading edge shapes and fin aft surfaces that taper down to a zero (or at least, thin) trailing edge. (Think of a stretched-out teardrop shape.) Such a fin shape (with a smooth surface finish) will preserve smooth airflow across a greater portion of the fin’s chord and will result in larger aerodynamic forces being generated for a given fin size. If you have left your fin leading edges square, a fin at any significant AoA will begin generating some lift (google “flat plate” airfoils) but also all sorts of interesting airflow separation zones, turbulence, local aerodynamic stall, and increased drag. Fins with square leading edges can become slightly more efficient (aerodynamically) as the leading edge sweepback angle increases but this effect doesn’t kick in until you get to LE sweep angles of 60-70-80 degrees.

If your rocket is a supersonic design (not as in “barely gets there for a second or so, according to rocksim” but as in GETS there 200 ft over the pad and remains supersonic until 6000 ft….which is not going to be your average model rocket) the fin airfoil optimization changes to sharp leading edges and trailing edges. The stretched subsonic teardrop shape needs to look like a stretched supersonic diamond airfoil section. If you simply bevel a little of the leading edge and leave the bulk of the fin at a constant thickness across the chord, the fin will have a significant drag penalty. You guys building hi-power designs have to judge for yourselves whether the extra work to build complex (and expensive) fin airfoils is worth lower drag and a little better performance. For me, once the thing is 1000 feet over my head, I sure can’t tell by watching it how fast it is going, so who really cares? (build the easy fin shape!)

Finally, if there were any significant shift in the rocket’s overall C.P. then you would still need to design for “sufficient” stability margin at the worst-case C.P. position. You should create a design that is stable and safe at any reasonable yaw angles and doesn’t (knowingly) have any “surprise” characteristics.

Said all that to say this: Your fin airfoil shape will have as much affect on fin and rocket aerodynamics as anything else. If you are concerned about optimizing your rocket’s performance for that last teeny bit of C.P. shift and stability margin, then a far more logical previous step would be to craft some nice airfoil shapes into your fins….which I hardly ever see anyone do on the posted build threads. (Not picking on you, ClayD, that rocket in your TRF signature looks like a very nice build!)

And for conventional 3FNC model rockets, the C.P. really doesn’t move very much for small yaw angles; I just call it “fixed” in one place.

I don’t have detailed design data on your rocket so it is kinda difficult to analyze it. The model rocket design that I am using for this example is one of my own, featuring a BT60 airframe tube with a cluster of seven 13mm Estes T motors. (Yes, it does fit, at least theoretically, but only by a hair.) Three holes will be for -3T upper stage motors with an ejection charge to deploy the recovery system, and four will be for -0T booster motors that vent out the sides. I went to the NAR motor testing pages to find the detailed characteristics of the upper stage motor, including a slightly heavier weight. I did this on purpose as a small degree of conservatism in my calculations.

The NAR data looks like this: (I show the NAR data here only to save you the trouble of clicking over to their website to view it.)

View attachment 01_motor data 1.xlsx

The same data plotted looks like this:

View attachment 02_motor data 2.xlsx

This test stand data has relatively wide time intervals between thrust measurements, and the intervals are also inconsistent. These measurements may work just fine to identify motor characteristics but they do not work too smoothly with a spreadsheet analysis. We are going to want to see a more detailed time history to detect certain events a bit more closely. My spreadsheet model will also be using a “trapezoidal” approximation of motor parameters in each time interval, and a shorter time step will improve the modeling accuracy. Plus, I just feel like doing it that way. When you write a spreadsheet you can do it your way.

My first step was to regenerate this same time-thrust curve at a higher level of fidelity. I don’t view this as trying to change the data or misrepresent it in any way, just trying to interpolate the existing numbers to fill in thrust data at new time intervals. I chose 1/100th of a second for a time increment because things happen fast during the motor burn and I would like to look over this series of flight events. Specifically, I would like to see when first movement occurs, when the rocket clears the launch rod tip, the altitude where peak thrust occurs, and several other key events. I have found from similar studies in the past that using this time interval for a model rocket simulation gives fairly detailed modeling results and (IMHO) is worth the effort to re-construct the engine time-thrust data. So, my version (hopefully equivalent to the NAR data) looks like:

View attachment 03_motor data 3.xlsx

If the two thrust curves are plotted together, a close match can be seen. The solid red line represents the original NAR data and the dashed black line represents my own model.

View attachment 04_motor data 4.xlsx

To improve the accuracy of the performance calculation it would be good to subtract the weight of propellant burned and expelled for each time-wise step of the motor burn. Almost any model at all would be better than ignoring the weight change; such burn models could include all propellant weight subtracted from the total rocket weight at ignition, at the end of the propellant burn, or linearly during the burn. But shouldn’t there be, you say, a better way?

The actual consumption of propellant inside a blackpowder motor is a complex phenomenon that even chemistry experts have difficulty explaining. There is no one, simple chemical reaction, but rather a whole range of partial reactions with many intermediate products going out the nozzle. Further, this mix of mess is pretty much constantly changing during the propellant burn as combustion chamber size changes from just about nothing (with very little “dwell” time for chemicals to react) all the way up to nearly empty, and as chamber pressures start at zero and reach a peak value at maximum thrust and then fall off to lower pressures during the sustaining propellant burn. Blackpowder burn rate varies with pressure, temperature, day of the week, and the daily horoscope (not really, of course, but blackpowder chemistry and physics are as much black magic as they are science). In short, there is not a “simple” way to make an accurate model of the rate of propellant weight expenditure.

By no means do I present my propellant weight loss model as best, accurate, or even “good.” I am just using engineering judgment to propose that propellant weight is ejected roughly in proportion to the impulse delivered in each time increment. If you can think of a better way to do this (quickly, consistently, and with some probable connection to the actual weight changes) then let’s hear about it. For now, I am going ahead with the following:

My burn model uses the motor impulse from each time increment (impulse being [thrust] multiplied by [time], so the incremental impulse is [average thrust during the time interval] multiplied by [length of the time increment]). I then calculate what percent that “impulse increment” is of the total motor impulse, and use that percent to carve off how much propellant weight gets burned and ejected during that same interval. Maybe this is more trouble than it is worth for an Estes 13mm motor (or even for seven of them) but it an approach that would scale up to any other size motor. My burn model is shown on this page of the spreadsheet:

View attachment 05_prpllnt burn model.xlsx

The rocket that I am going to use for this example weighed 5.1 ounces, or 144.6 grams. (At least, my boilerplate version with a different MMT weighed that much and I am using that for a starting point.) Data from the NAR motor website shows that the A10-3T motor weighs 8.5 grams and I will go ahead and use that heavier version of the motor in case I ever want to load all seven MMTs with upper-stage motors. Seven of these motors then weigh 59.5 grams. The total rocket, ready for launch, weighs 204.1 grams (or 0.204 kg).

The frontal area or cross-section area of my design includes a BT60-sized body and four fins made from 1/8th-thick material with an exposed half-span of 2.15 inches for each fin. That makes a frontal area of 2.1 in2 for the body and 1.1 in2 for the fins, a total of 3.2 in2 for the complete rocket. (You can add something for the launch lug if you want to get more accurate.) We are going to be running our spreadsheet calcs with metric units, so converting this geometry we get a total of 20.5 cm2 (0.00205 m2). If you are an engineering student you are going to hear “remember to check your units” several thousand times before you graduate. Check your units.


Other comments

Notice that I am using data from the NAR website in preference to data from Estes. Normally I would consider data coming directly from a manufacturer as being more “authoritatively” accurate. Except…Estes sometimes seems to kinda “inflate” their product information to make some items look a little more impressive, probably to pump up sales. (Like an A10 motor that actually only has an average thrust of 2-3 Newtons, and should properly be labeled an A3, but A10 sounds more powerful, so there you go--)

And I should have said this at the very first—I apologize if my writing style goes “below” anyone, or is too tedious, but I would rather over-explain something and let a few of you get a little bored than skip over something that is obvious to me and unknown to someone else. My experience has been that most folks are too embarrassed to speak up and ask questions, right at the times when they most need to go ahead and ask. So sorry if I overdo it, but if I underdo it and you have qstns about this spreadsheet stuff PLEASE DON”T BE BASHFUL.

I did not lay this out to look pretty because that will be a subjective thing where everyone will have a different opinion or preference. I think the most important part of making a spreadsheet “look” good (to anyone else) is to make it easy to follow through the calculations. Even there, you have a judgment call on how many detailed calcs to show, wrestling between wanting not to “lose” anyone by skipping details but also wanting not to junk-up the page with too much detail.

I put the elapsed time on the left, where it stands out visually, and can be used as a reference to quickly find a spot in the flight and then scan across the line to pick up other data.

I put the main parameters into the next several columns to highlight them a bit.

I put the lesser parameters and auxiliary calculations into columns off to the right so the numerical values are still quickly available, but these numbers are kinda “off to the side” and can be ignored if you so choose.

How did I come up with these columns and labels? I guess you could call it cheating, because I have built these spreadsheets before and I already know what sort of numbers I want to see on the page. And knowing me and knowing that in two days I will have forgotten some assumption, or why I did some calculation in some weird way, I leave plenty of notes for myself and intermediate calculations to make it easy to pick up the analysis again in the future and make changes or additions. Plus, I have had to work enough times with other people’s spreadsheets to know that a condensed, brief style of spreadsheet might make for a tidy display on the screen, but having a nest of 479 calculations packed into one cell is a nightmare to try to follow.

That’s about it for the strategy to this layout. I don’t know if it looks “nice” or “pretty” (wrong kinds of questions to pose to an engineer), I am just trying for clarity and reasonably complete documentation. If you don’t like it, go design your own.

With the timeline shown for the motor burn (initial portion of the flight) and preliminary data inputs, the spreadsheet looks like:

View attachment 06_sprdsht_start.xlsx

I picked a value for drag coefficient based on past personal experience for the type of rocket I am designing and the features and external surface complexity that it will have. If you have an extremely “clean” design and really polish the surfaces smooth, eliminate launch lugs and buttons, and really shape the fin airfoils “right,” you could easily have a drag coefficient that is much lower. Drag coefficient is a highly complex subject which I am not going to dive into right now….but which several of you are probably going to ask about anyway.

When we get this spreadsheet more fully completed you will be able to drop in alternate values of cd and see the speed and altitude results. Note that I set up the spreadsheet to copy the value of cd all the way down the page, from the value put into the cell on the top line, to make it easy to experiment with alternate values. To those of you who are not EXCEL users, do not be intimidated into thinking that every single cell in the column had to be separately programmed; once you set a generic calculation in one cell you can easily copy-n-paste it hundreds of lines down the page.

The values of atmospheric density definitely vary (depending on temperature, altitude, others) but for a model rocket that only ascends a few hundred feet I selected a fixed value. (Remember to convert these values to the same units of measurement as used in the rest of the spreadsheet.) This is the “standard day” air density at sea level, and needs to be tweaked to the specific altitude of my local launch field and the weather conditions on launch day. If I was analyzing a rocket that traversed several thousand feet of altitude it would probably be worthwhile to pull out the standard atmosphere model, pull out the data points near and across my “working” altitudes, and curve-fit a trend line (a straight line often works fine unless you must cover a very wide altitude range, but EXCEL also has tools to generate logarithmic and polynomial curve fits to data). You can then use your own trend line to estimate the atmospheric conditions in more detail. I need to dig up an example atmosphere model and get it posted in here, I promise I'll get one in the next couple days.

View attachment 07_add_some_more_data.xlsx

I copied all that detail motor burn data (the time-thrust model at 1/100th-second intervals, from above) into the spreadsheet over on the right-hand side. This data is for a single motor.

Over to the left, I created a spreadsheet column for all seven motors. Again, it is not necessary to program every cell separately; once a generic calculation is set in one cell it can be copy-n-pasted all the way down the column. Some assumptions that automatically come along with this thrust model are

1) This representation is for all motors firing. If your rocket design is close to critical levels of safe flight with one motor that fails to ignite (not enough speed, not enough altitude, etc) you may need to perform an extra analysis with reduced thrust and with un-ignited motor weight carried throughout the flight. The dead motor problem is generally worse with smaller clusters, worst case being two- or three-motor clusters.
2) This representation is for all motors igniting and burning simultaneously. Theoretically, if these motors had maximum thrust peaks that were substantially shorter, and ignited at staggered points in the flight timeline, an individual motor firing out of synchronization might not be enough to accelerate the rocket significantly, and if they ALL fired at different times then the rocket might actually not go anywhere, just sit on the pad and make smoke. You should consider the performance impact of early, late, and failed ignition, and make an honest assessment of your cluster ignition skills before you make a big assumption like this one.
3) This motor model is for multiple motors of the same type, and time-thrust curve. If you have some other cluster combination you will have to create different models of each separate motor type and then combine the thrusts at each time increment to produce a composite model of the cluster thrust performance.

View attachment 08_add_motor_data_step_03.xlsx

Next comes my estimate of expended propellant weight, and data for rocket total weight throughout the thrust period. I put the propellant weight loss model for a single motor over on the right-hand side, just to have it on the same sheet, but show the other calculations for total rocket weight over toward the left-hand side.

Column G has the expended propellant weight (actually mass, not weight) model for all seven motors, which is simply the value for a single motor (found on the same line, over to the right) multiplied by seven. Column H continues the mass calculation by subtracting the expended propellant mass (on each line) from the total rocket launch mass (from above, on Line 10) to determine the rocket mass during that time increment (still on the same line and time-mark). Column I is a simple decimal point move, to convert mass from grams to kilograms. Column J is where the mass is combined with the metric gravitational constant (from above, on Line 14) to produce the rocket weight.

All these mass/weight calculations could have been programmed together into a single column but since this whole discussion is to demonstrate how a spreadsheet might be constructed I felt that it would be good to illustrate the difference between mass and weight. And in the next step, we’re going to need both, so we might as well preserve the data.

View attachment 09_add_weight_data_step_04.xlsx

This is a part of the calculation where physics and engineering folks get fussy about definitions. Acceleration is NOT motion or speed or velocity, it is the rate of change of speed or velocity, per unit of time. Acceleration of an object is directly proportional to its mass and to the forces acting on the object. The equation is a simple one: (Force) = (mass) x (accel). If you do much work at all with physics or engineering you will learn this one for sure. (Some men murmur the names of women in their sleep. Engineers mumble “F = (m) (a)&#8221

This is the point in the analysis where a free-body diagram must be used to summarize the forces acting on the object, which is our rocket. In this diagram we identify all the things that are pulling on the rocket, including motor thrust, weight of the rocket due to Earth’s gravity, and aerodynamic drag. You could account for other forces (like buoyancy, or the weight of the rocket due to Jupiter’s gravity) but these effects will be far smaller in magnitude and can safely be ignored. Did I mention earlier that I am a big fan of simple?

(Bonus points for anyone who correctly constructs a free-body diagram of a rocket in vertical flight and posts it on this thread)

The free-body diagram is a graphic means of summarizing these effects, leading to a calculation in equation form. Assuming the rocket’s orientation is vertical, and all motion is vertical, and we have no crosswinds, then total thrust is acting vertically upward, weight is acting vertically downward, and total aerodynamic drag is acting rearward (vertically downward). We can write an equation describing the total of these forces as:

Net Force = (ThrustT) – (Weight) – (DragT)

where the upward direction is positive. If we can identify what these three forces are at any point in time during the flight then we can use this equation to estimate the total or net force. We also know, at all those time increments, the mass of the rocket, and we can turn around the “F = m a” equation to find acceleration:

a = F / m

Units of all this stuff: accel is expressed in meters / (second-squared)
mass is expressed in kilograms
Force is expressed in Newtons, or (kilogram-meters) / (second-squared)

By using this free-body diagram I am basically analyzing a simple condition of purely vertical flight. If you want to make things more complicated, have at it. If the rocket is launched at some small angle A away from vertical, it is possible to model the vertical components of the resulting flight (horizontal components will result in some sideways “drift” across the launch field, which may or may not be of concern).

For the case where the flight path is deflected at A degrees away from vertical, the vertical component of the motor thrust that is lifting the rocket vertically is (ThrustV) = (ThrustT) x (cosine A)

The vertical component of the weight acting on the rocket is…..Weight = Weight (duh). The trick here is that the orientation of gravity remains vertical regardless of where the rocket is pointed or where it is moving.

The vertical component of the drag acting on the rocket is (DragV) = (DragT) x (cosine A)

For small angles away from vertical (small values of A) the cosine will be very close to 1.0 and the effects of a non-vertical flight path will be negligible. The flight path would have to be eight degrees away from vertical before the value of cosine(8) reaches 0.99 and the vertical components would even be one percent smaller. The flight path would have to be 11 degrees away from vertical before the value of cosine(11) approaches 0.98 and the difference would be two percent smaller. These deflections away from vertical are fairly large, and certainly possible if you launch on a windy day, but they are certainly not desirable if you are striving for altitude. I do not include these effects in the following spreadsheet. I would have to be convinced first that all the assumptions and caveats and approximations that I already made in the rest of the spreadsheet still give me an answer that is better than 99 percent accurate before I start worrying about a little lateral motion (IF it is only a little). If you need to model the effects of non-vertical flight paths on vertical motion, you will probably need someone to video your rocket’s trajectory (from well off to the side, to get a good view of any pitch-over) and make appropriate adjustments to the model at the approximate altitudes (or elapsed time points) in the flight.

(Double-bonus points for anyone who correctly constructs a free-body diagram of a rocket ascending on a path that is “A” degrees away from vertical, and posts it on this thread)

A small simplifying assumption I am going to make is that there is no force resulting from the rocket sliding up the launch rod (or rail), that this part of the launch is frictionless and does not affect the calculation. In the real world this assumption is not too far off the mark, because the lugs should be properly aligned and the rod should be straight and the motor thrust line should be acting straight up through the center of the rocket and there should be minimal drag caused by the launch rod. If this is not the case, go back and fix something.

I am also going to assume that stupid stuff like electrical launch leads do not snag on the rocket or fins and that the igniter burns cleanly and the leads fall away freely. I think an event such as these would qualify for a “do-over” that even your instructor would have to agree with.

How does all this fit into the spreadsheet? Open the sheet below, go to Column L, pick out a line (from 26 on) and click on a spreadsheet cell. You should see an equation appear in the header window near the top, showing that

Accel (in Col L) = [ motor thrust (in Col D) – aero drag (in Col F) – weight (in Col J) ] divided by mass (in Col I)

The values of aerodynamic drag have not yet been estimated but the equation form can be seen to parallel the same equation F = (m) (a) as I showed you earlier. As we complete more of the spreadsheet and estimate aero drag, the sheet (as already programmed) will adjust itself for the added information automatically.

Note that the value of accel at time = 0.0 (before the motor ignites and generates any thrust, and before the rocket is moving and generates any aero drag) reflects the same value as the gravitational constant. Also notice how quickly and how greatly the values of accel change through the first 0.2 seconds of the motor burn, confirming our earlier suspicion that we would need very short time increments for our model to accurately account for the rapid thrust peak of this motor.

View attachment 10_acceleration_step_05.xlsx