Cesaroni has again come out with some new motors which will be available for
the first time in the US at LDRS (as I understand it). Since they are so
new I don't know if anyone has created any .eng files for them and thought,
maybe, I'd take a stab at doing so.
Looking at the motor information and thrust curve posted on the CAR web site
one question immediately comes to mind: What time interval is minimally
required for a representative .eng file for computer simulation software
(specifically RockSim)? The K660 thrust curve has .4 second intervals on
the graph and it seems it would be relatively easy to interpolate the pounds
of thrust from this graph. Would four tenths of a second time intervals
produce an accurate enough .eng file?
The samples don't need to be evenly spaced (unlike is common
in digital signal processing). Instead, you are limited to 16 or 32
total sample points. I think 16 for wRASP, 32 for Rocksim, IIRC.
Otherwise the file formats are the same.
Anyway, the key is to pick out 16 points which best fit the curve.
It's frustrating doing it by hand. I've wondered how the NAR
does it. They seem to be the only testing agency providing the
data in this form.
Anyway, I've tried to think up a computer algorithm which might be
used to massage the huge firing files down to the desired 16/32
data points. In signal processing, we have things like decimation-
in-time filters, but they'll change the shape of the curve since they're
locked into fixed sampling intervals. A more sophisticated scheme
would be needed to pick out all the key peaks and valleys and then
fill in from there, but establishing the criteria for what is "key" is
totally arbitrary, and prone to generating too many sample points.
Here's an idea: Maybe we can ask S&T if they would provide
a service of taking TMT and CAR files and generating
wRASP files for us :)
Seriously, even then, I wonder how good the data is. If all you have
is one firing file for a motor, you can't help but wonder how "typical"
it is for that motor type. You'd really like to have at least three
files averaged together. Ideally, three files, one each from three
different production batches.
I've done it using graphical techniques, reading the measurements off
a ruler, then scaling them in a spreadsheet, but there's lots of ways
this is error prone.
OTOH, you wonder if that's really any worse than not having multiple
If there was a way to view the firing file data in a graphical form,
then pick out key points (using the computer), that'd be great. But if
you try to open a file like that in Excel, the graph blows up. You
would need a special graphing tool better suited to the task.
Ya know, tho, Rocksim's engine editor could be morphed into such
a tool. If it could read the firing file, then allow the user to select
the key sample points, then show the comparative data (impulse, avg
thrust) for the two sets of points (ie, set and sub-set), the user
would be able to get a feel for the error. The tool could even calculate
the mean-squared-error to assist the user in placing the points.
I have an excel spreadsheet that I use posted here:
The instructions are very poor but if you can figure it out it works great.
I just capture the screen, paste it into Paint and use the cross hair (and
numbers in the lower corner) and convert to real points.
; No tab characters.
; No blank lines. (Note, blank lines at the end of the file
; are a common problem
; ";" character in column 1 denotes a comment line.
; At least one comment line that is otherwise blank must
; separate each motor type.
; No particular column spacing is required.
; Space delimiter between fields.
; Simple decimal numeric format; leading/trailing zeros are
; don't care.
; Scientific notation is not supported.
; No comment lines may intrude between any data lines of a
; motor type. Comments lines may appear before or after
; a motor's data set.
; Each motor listing consists of a header line, followed by a
; number of time/thrust data lines. The maximum number
; of time/thrust points is not specified and will be limited
; by the particular simulation program using the file.
;EACH INDIVUDUAL MOTOR:====================================
; Header Line:
; Size (mm) Delays Weight (Kg)
; Type Dia x Len (sec) Fuel Total Mfg/Notes
; Time/Thrust lines:
; Timepoint (sec) Thrust Level (Nt)
; Header Line Format Notes:
; The type, Delays, and Mfg/Notes fields are any ASCII text with no
; embedded spaces. Other fields are numeric ASCII only.
; ALSO: Plugged motors use a delay of 37 as a space filler (and plug code).
; NOTE: heaviest motor of each type is used for basic mass.
; The Diameter and Length fields must be an integers! A decimal point
; is not allowed. (A decimal point in the Diameter field will
; cause a load error; a decimal point in the Length field will
; allow the file to load, but the data will be parsed incorrectly.)
; This is probably only particular to wRasp, I doubt that other
; sim programs would have this limitation. The other numeric
; fields are real numbers.
; Time/Thrust Format Notes:
; No zero thrust level may appear before burnout.
; Time/thrust points must be in chronological order.
; If a timepoint of zero appears, the corresponding thrust level
; must be greater than zero (this is typical of data derived
; from ALT4 motor files).
; If the first timepoint is greater than zero, a thrust level of
; zero is assumed at time zero.
; DOS RASP89 and wRASP up to v1.6 are limited to 32 time/thrust pairs per
; wRASP v1.61, v2.0 and v2.1BW are limited to 64 time/thrust pairs per motor.
; wRASP v2.1 is not limited per motor, but has a maximum of 16384 time/thrust
; pairs for the entire motor database.
(__ (__ (_____ (______ TM
(__ (__ (__ (__ (__ (__
(__ (__ (__ (__ (__
(__ (__ (__ (________ V1.64
(__ (__ (__ (__
(_____ (____ (__ (__ Freeware CP/CG Calculator
(____ (______ (__ (c)1996 Gary A. Crowell Sr.
Thanks, Doug - I think. ;)
Take a look at R. Dh8's response and the spreadsheet of his. It seems to do
just what you're talking about - allowing points to be grabbed off the
thrust curves profile so readily available. It is simple, yet effective - I
Thanks again, Robert. By using your spreadsheet and technique I just
created a very believable simulation with one of the new Cesaroni Pro54
For all of you computer sim users try this very clever technique. I think
Robert has come up with the first easy method to create .eng files from a
Pete "the corn hatin', .eng file maker from analog data, RockSim user" Lilja
and opened it in M'soft
Paint. I then got the x & y coordinates for zero and max thrust (on the
chart-watch out for the pounds/newtons conversion trap - RockSim
requires Newtons in the Engine Editor program) as well as the coords. for
zero and maximum time as displayed in the lower right corner of the Paint
window (it looks like the: 77, 94). The starting/ending coordinates are
entered into the spreadsheet in the top two boxes of Robert's spreadsheet
which he provides on his web page. To fill in the thrust profile I used the
crosshair cursor to grab points and their coordinates and then entered those
in the same way into the lower boxes. The spread sheet gives the
appropriate time and thrust points to enter into the 'Thrust Data Info"
window of the Engine Editor. You then have to run the Engine Data Compiler
program and also 'reload the engine data' in RockSim itself.
I used 20 points that I grabbed from the thrust profile that seemed
appropriate based on nothing other than guesswork and what I thought would
approximate the displayed curve. While I cannot guarantee that it is an
accurate .eng file the resultant sim I ran from the newly created Pro54 K660
compares appropriately well to the K550 sim and that .eng file came from
Apogee in v. 6.0 of RockSim. The K550 sim closely approximates what my
recording G-wiz altimeter displays so my confidence level is rather high in
using Robert's clever technique.
It is late and I'm not sure I've explained this as well as I could. Any
other questions - please feel free to ask.
I hadn't realized you could read the
coordinates off the screen in Paint.
This method is about halfway between
the drafting method and what I deem
ideal. You're able to use the computer
to read off coordinates, but you're
still prone to introducing errors.
If you're careful, they'll be small,
and shouldn't have any significant
effect on the sim results.
One difference is the (still ethereal)
method I described lets you highlight
a point on the curve, so you get the
coordinates of that point, and not
of the cursor. It's a subtle difference,
I know, but, hey, it's a computer, it
ought to be able to do that, right
Anyway, the other key is that the
computer will automatically read
the datapoint without you needing
to manually transfer it.
I've used Robert's flow much as
you described starting with a
graphics file, but, in on case,
the file had been printed, copied
and scanned too much.
The image had key-stoned (due to the
imperfections of the Xerox process)
and as a result, the axes were no
longer at 90 degrees. Here, you have
to do some guesstimation.
The ultimate goal is to automate
the process. You may find this
ironic, but there was alao a pdf
file next to the jpeg on the CAR
site. I can open that pdf in
Illustrator, and see the dots which
make up the curve. Theoretically,
all those dots are defined by
numbers which should be somehow
extractable from the pdf - no need
to do any eyeballing for numbers,
they're already there, if we can
figure out how to read them.
Anyway, thanks for the followup.
You're question got me wondering about what "typical" is in regard to these
published thrust profiles.
Since I've been using the data from the CAR web site I poked around a bit
and looked at their Motor Testing Manual available here in PDF form:
minimally requires three motors for initial certification testing and these
thrust profiles are then overlaid with the one most representative of the
three chosen as "typical" (see p. 21 of the manual). Of course I don't know
just how this particular profile is chosen (eyeball, arithmetically or what)
but it is, hopefully, more representative than a single firing. I'll have
to leave to others more well versed in sampling if this is a truly
acceptable method. I'd further guess that they are not from different
production batches - especially on brand new motors. However this testing
procedure is done it seems to have worked for a number of years.
With only three motors tested, your best procedure would be to model
each motor tested, and run your simulation three times with each motor
data set. Then look at the mean resulting performance, and worst case
(I can't access your post, so I'm replying via Alan's.)
The certification testing has been debated here before. While I don't
think it's sufficient for it to come up with a truly robust model, I
understand and support it for certification purposes. I recognize the
need to make the testing less demanding for the sake of expediency.
But the test is non-trivial, and therefore, I think, ensures reasonable
quality. Without getting into a bunch of math I'm really, really rusty
at, I see it this way: If the manufacturer can submit 3 motors which
all meet the specs, then he likely has his stuff together.
Remember, motor testing is destructive testing, so he can't test 3
motors on his test equipment, then resubmit them. He must instead
submit other motors, and must be confident that his processes are
yielding with enough consistency that these motors will be so close to
the others as to be indistinguishable.
So, I think cert testing is good for validating the product.
But for coming up with sim models, I think we need to average over
several batches. Ideally, they won't vary widely from batch to
batch, but in the real world, I think they can vary enough, for
example, to make you wish you'd chosen a different delay for
a given situation.
Or maybe the center moves, and the typical production motors
all average 8% less impulse. Again, here's where using thrust
curves from many batches over a long time will help keep the
model more realistic.
All that said, now that you've got me thinking about it this much :)
as long as the motor's sim model is only reasonably close, it
should be OK. There are so many other variables, and lady
luck, too, that getting the motor file too close is overkill. It's
like paying for high precision resistors and then mixing them in with
your 5% parts. The rest of the rocket (sim) model (and environment)
isn't accurate enough to justify getting the motor model that close.
Thinking I just did an Emily Latella....
Actually, I have already rendered most of the new motors for .eng
files. It's been a very busy weekend or I would have had it done by
now. I'll be posting the completed .eng files on my website hopefully
by Wednesday. I'm including the Pro75 motors this time as well, which
will mean that the only one missing is the Pro150 (but I'll get that
one done soon). You can see the already existing data in the downloads
Before, I'm asked again - No, I don't have the 62.5g Pro38 data. If
anyone out there has this, please send it along and I'll include it on
the web site.
CAR #S665, L3
Visit Cole Fired Rockets at:
If the writers of Rocsim would allow you to import a BMP and display it
behind the engin editor it would be simple.
You put it in the background , move and scale it to fit the axis then plot
the points over the graph.