Thrustcurve Open Thread

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
All --

Studying up to fly some rockets and playing with OpenRocket on an old Glass Rocket I've got about ready to fly with the Blue Raven.

Anyhow, I am curious about what happened to the Total Impulse of the 'classic' AT G40W ?

Back in 1997 / 1998 the Motor produced about 112 N-sec Total Impulse.

The latest data at thrustcurve.org lists it at 97 N-sec.

Is the new Online Data correct ?

Thanks !

-- kjh

These are three Rho-V^2 normalized thust curves ( and the Averages ) that I've reduced from AltAcc Accelerometer Data in 1997 / 1998:

Code:
$ cat ./altacc/prodata/pack/dat/g40-sum

#    Time      g40-1     g40-2     g40-3    Average
#   (secs)    Newton    Newton    Newton     Thrust
# ========  ========  ========  ========   ========
    0.0000      0.00      0.00      0.00       0.00
    0.0625     62.67     12.04     53.58      42.76
    0.1250     53.58     36.17     59.06      49.60
    0.1875     62.35     66.11     50.52      59.66
    0.2500     56.27     61.90     53.19      57.12
    0.3125     56.13     62.79     50.28      56.40
    0.3750     56.00     60.30     52.94      56.41
    0.4375     58.92     62.47     50.04      57.14
    0.5000     54.82     61.28     49.92      55.34
    0.5625     52.66     59.20     49.81      53.89
    0.6250     55.56     62.00     49.69      55.75
    0.6875     54.42     55.96     49.57      53.32
    0.7500     50.88     58.76     52.19      53.94
    0.8125     54.15     58.62     49.33      54.03
    0.8750     52.13     58.47     49.21      53.27
    0.9375     52.00     55.41     49.10      52.17
    1.0000     49.00     55.28     48.98      51.09
    1.0625     48.89     55.15     48.86      50.97
    1.1250     48.77     52.12     48.12      49.67
    1.1875     48.66     52.00     48.01      49.56
    1.2500     48.54     49.01     44.51      47.35
    1.3125     48.43     48.97     45.78      47.73
    1.3750     48.32     48.86     43.00      46.73
    1.4375     45.37     44.43     42.90      44.23
    1.5000     48.15     42.94     40.63      43.91
    1.5625     42.35     42.85     37.34      40.85
    1.6250     45.11     39.92     42.62      42.55
    1.6875     42.20     39.84     39.87      40.64
    1.7500     42.11     36.94     37.14      38.73
    1.8125     39.22     34.04     37.07      36.78
    1.8750     39.14     33.98     34.36      35.83
    1.9375     33.49     31.10     34.29      32.96
    2.0000     33.44     31.05     31.60      32.03
    2.0625     30.60     28.19     31.54      30.11
    2.1250     30.55     28.15     28.87      29.19
    2.1875     27.74     25.31     26.20      26.42
    2.2500     24.93     25.27     26.17      25.46
    2.3125     22.14     22.44     23.52      22.70
    2.3750     19.35     22.42     23.49      21.75
    2.4375     16.57     19.60     20.86      19.01
    2.5000     13.80     16.78     18.23      16.27
    2.5625      8.29     16.77     15.61      13.56
    2.6250      8.28     13.96     13.00      11.75
    2.6875      5.52     13.95     10.40       9.96
    2.7500      5.52      8.37     10.39       8.09
    2.8125      2.76      8.37      7.79       6.31
    2.8750      2.76      5.58      5.19       4.51
    2.9375      2.76      2.79      2.60       2.72
    3.0000      2.75      2.79      2.59       2.71
    3.0625      2.75      0.00      0.00       0.92
    3.1250      0.00      0.00      0.00       0.00
# ========  ========  ========  ========   ========
# I Total:    113.18    114.42    108.75     112.11 (N-Sec)
#   I Avg:     36.22     37.36     35.51      35.88 (N)
#     ISP:    151.86    162.06    154.02     155.90 (sec)

# M Launch:     946.0     953.0     892.0        n/a (grams)
# M Motor:      120.0     118.0     116.0      118.0 (grams)
# M Propel:      76.0      72.0      72.0       73.3 (grams)

I looked at the data on ThrustCurve. The G40w was retested in 2006 and those more recent numbers are correct. Here’s the data sheet for the re-certification from the NAR:
https://www.thrustcurve.org/motors/cert/61ec3d6aa1cd0a000491cf10/G40.pdf
 
All --

Studying up to fly some rockets and playing with OpenRocket on an old Glass Rocket I've got about ready to fly with the Blue Raven.

Anyhow, I am curious about what happened to the Total Impulse of the 'classic' AT G40W ?

Back in 1997 / 1998 the Motor produced about 112 N-sec Total Impulse.

The latest data at thrustcurve.org lists it at 97 N-sec.

Is the new Online Data correct ?
I try to keep the site up-to-date with the certification docs. Of course, if the motor changes without being recertified, I'll miss things.
If I have a doc for the motor, you'll see a "View certification docs" link on the motor page.

As far as the thrust data files, Tim VanMilligan got the data from AeroTech in 2005. (You can see it in the comments on the RASP file.)
 
I try to keep the site up-to-date with the certification docs. Of course, if the motor changes without being recertified, I'll miss things.
If I have a doc for the motor, you'll see a "View certification docs" link on the motor page.

As far as the thrust data files, Tim VanMilligan got the data from AeroTech in 2005. (You can see it in the comments on the RASP file.)
Thanks John.

That makes perfect sense.

And thanks for what you do and have done for all these years !

-- kjh( :) all the names from way back when make me feel all nostalgic :) )
 
OK, I went through the last couple of pages and collected feature requests, see the to-do list. I apologize if I missed a suggestion; feel free to raise it again.

One feature request that comes up a lot is the ability to compare motors. This is already supported, but is kind of hard to find. Once you've viewed a couple of motors, there is a "Compare" link on the right side. Also, when you search, you can compare directly from the results page.

View attachment 578096

The most powerful computer in the world is a two ton rock but the user interface sucks.
 
OK, I went through the last couple of pages and collected feature requests, see the to-do list. I apologize if I missed a suggestion; feel free to raise it again.

One feature request that comes up a lot is the ability to compare motors. This is already supported, but is kind of hard to find. Once you've viewed a couple of motors, there is a "Compare" link on the right side. Also, when you search, you can compare directly from the results page.

View attachment 578096
Thanks John.

Very nice feature.

I love the graphs :)

-- kjh
 
Two related issues regarding the manufacturer field that I discovered in the last couple of days. I noticed these while looking in the OpenRocket motor selector, which is of course just based on data taken directly from thrustcurve.org.

Estes vs. Estes Industries, Inc.

1710515656925.png

Notice those 5 motors that appear under "Estes Industries, Inc.": they are duplicates of motors that appear under "Estes." I believe this is because there are multiple thrustcurves for those motors on thrustcurve.org, and there is one file that has manufacturer listed as "Estes Industries, Inc." I haven't looked deeply enough yet to know if the curves are otherwise different, or what exactly. Maybe there are just extra files that can be deleted, I don't know.

AeroTech vs. Quest

18mm Q-jets are listed under manufacturer "Quest", while 24mm Q-jets are listed under "AeroTech", despite the fact that all are sold as "Quest". This makes it a little confusing while searching. It would be super-fantastic if Q-jets were all listed under manufacturer "Quest", because they're qualitatively different from other Aerotech motors and it's helpful to be able to distinguish them while looking them up.
 
How does OpenRocket
which is of course just based on data taken directly from thrustcurve.org.

How does OpenRocket get the data from Thrustcurve.org? Is it a direct feed via an API or are the RSE or ENG files downloaded somewhere local?

All the ENG and RSE files on Thrustcurve have always contained discrepancies in manufacture nomenclature. Aerotech is often listed as "Aerotech", but can also be "AT":
From the Aerotech.rse file:
Entry for the I229 uses "AT" - <engine mfg="AT" code="I229T"
Entry for the K455 uses "Aerotech" - <engine mfg="Aerotech" code="K455NW"
Entry for the O6000 is "Unknown" - <engine mfg="Unknown" code="O6000W"

Estes can be "Estes Industries, Inc." or "Estes"

CTI can be "Cesaroni Technology Inc." or "CTI"

etc.

For Rocksim, I long ago started maintaining my own engine files. I went through and did a find/replace to ensure all the mfg codes were the same. I also filtered out and corrected all the unknown entries. It is a bit of a pain and, when new motors come out, I have to add motors manually, but, it keeps my motor files clean, nomenclature standardized and errant entries from causing issues.

Not sure how the underlying database in Thrustcurve is setup, but it would be great to clean it up at some point. John has stated in the past that he is reluctant to mess with the data because he wants to ensure he doesn't change any of the manufacturer's motor specs, but it would seem to be okay to do a normalization of mfg nomenclature and get rid of "unknown" entries, to the extent possible.
 
Last edited:
How does OpenRocket get the data from Thrustcurve.org? Is it a direct feed via an API or are the RSE or ENG files downloaded somewhere local?
Sorry I don’t know the mechanics of it. @SiboVG or @JoePfeiffer could answer that.

There are apparently some heuristics within OR to normalize the manufacturer names. We could (and probably should) handle the Estes issue, but there are no hints on the Q-jets to allow us to properly identify them.
 
How does OpenRocket


How does OpenRocket get the data from Thrustcurve.org? Is it a direct feed via an API or are the RSE or ENG files downloaded somewhere local?
We pull the data from thrustcurve.org when we're preparing a release using the API documented at https://www.thrustcurve.org/info/api.html

It's then put in the .jar file along with everything else.

All the ENG and RSE files on Thrustcurve have always contained discrepancies in manufacture nomenclature. Aerotech is often listed as "Aerotech", but can also be "AT":
From the Aerotech.rse file:
Entry for the I229 uses "AT" - <engine mfg="AT" code="I229T"
Entry for the K455 uses "Aerotech" - <engine mfg="Aerotech" code="K455NW"
Entry for the O6000 is "Unknown" - <engine mfg="Unknown" code="O6000W"

Estes can be "Estes Industries, Inc." or "Estes"

CTI can be "Cesaroni Technology Inc." or "CTI"

etc.
OR has a Manufacturer class in https://github.com/openrocket/openr...src/net/sf/openrocket/motor/Manufacturer.java that tries to straighten some of this mess out; having someone take that on to update it for the current situation would be very helpful.
For Rocksim, I long ago started maintaining my own engine files. I went through and did a find/replace to ensure all the mfg codes were the same. I also filtered out and corrected all the unknown entries. It is a bit of a pain and, when new motors come out, I have to add motors manually, but, it keeps my motor files clean, nomenclature standardized and errant entries from causing issues.
You can also put your own files in a directory specified in the preferences. However, this will just add to the built-in database; we don't provide a way to disable that.
Not sure how the underlying database in Thrustcurve is setup, but it would be great to clean it up at some point. John has stated in the past that he is reluctant to mess with the data because he wants to ensure he doesn't change any of the manufacturer's motor specs, but it would seem to be okay to do a normalization of mfg nomenclature and get rid of "unknown" entries, to the extent possible.
 
Not sure how the underlying database in Thrustcurve is setup, but it would be great to clean it up at some point. John has stated in the past that he is reluctant to mess with the data because he wants to ensure he doesn't change any of the manufacturer's motor specs, but it would seem to be okay to do a normalization of mfg nomenclature and get rid of "unknown" entries, to the extent possible.
The motor pages in ThrustCurve.org are produced from a database, so there is never any confusion about manufacturers. The user-created files have a variety of ways of identifying manufacturers. Originally there was a 1-letter code, but that broke down quickly.

If you look at a manufacturer entry, it has a list of the aliases that are matched to identify a manufacturer. For example, AeroTech's list is: "AT,A,AEROT,ISP,AeroTech/Apogee".
https://www.thrustcurve.org/manufacturers/AeroTech/details.html

There are no "unknown" manufacturers; each data file (DB entry) is associated with a motor (DB entry) which in turn is associated with a manufacturer (DB entry). When the API is used, these associations are identified by unique database keys. The API also delivers metadata which contains the standard name and these aliases.
 
The motor pages in ThrustCurve.org are produced from a database, so there is never any confusion about manufacturers. The user-created files have a variety of ways of identifying manufacturers. Originally there was a 1-letter code, but that broke down quickly.
When someone submits a file with a name that doesn't match any of the aliases for any manufacturer, what happens? Do you work with them to resolve it and change the name to one of the known aliases, or what?
If you look at a manufacturer entry, it has a list of the aliases that are matched to identify a manufacturer. For example, AeroTech's list is: "AT,A,AEROT,ISP,AeroTech/Apogee".
https://www.thrustcurve.org/manufacturers/AeroTech/details.html
There are no "unknown" manufacturers; each data file (DB entry) is associated with a motor (DB entry) which in turn is associated with a manufacturer (DB entry). When the API is used, these associations are identified by unique database keys. The API also delivers metadata which contains the standard name and these aliases.
Wow, somehow I'd completely missed this. That would sure be better than our hard-coded sets of aliases....

But I'm a little confused. I assume when we get one of the motors from thrustcurve, it comes associated with either its manufacturer's full name (like Estes Industries) or abbreviation (like Estes). How do we end up with different sets of motors in our selector when the user selects Estes vs. Estes Industries? Or is the answer as simple as "we've got a bug"?
 
For Rocksim, I long ago started maintaining my own engine files. I went through and did a find/replace to ensure all the mfg codes were the same. I also filtered out and corrected all the unknown entries. It is a bit of a pain and, when new motors come out, I have to add motors manually, but, it keeps my motor files clean, nomenclature standardized and errant entries from causing issues.
I do the same...
 
When someone submits a file with a name that doesn't match any of the aliases for any manufacturer, what happens? Do you work with them to resolve it and change the name to one of the known aliases, or what?
Motor files are submitted on a motor page, so we know the motor (and manufacturer).
Wow, somehow I'd completely missed this. That would sure be better than our hard-coded sets of aliases....
Looks like I'm wrong and it only returns the official name and abbreviation. I could fix that...
But I'm a little confused. I assume when we get one of the motors from thrustcurve, it comes associated with either its manufacturer's full name (like Estes Industries) or abbreviation (like Estes). How do we end up with different sets of motors in our selector when the user selects Estes vs. Estes Industries? Or is the answer as simple as "we've got a bug"?
The API takes a list of motor ID to get data files for. This means that you would have already found the motor using search or something and thus have the exact manufacturer info.

Note that flow was originally designed for programatic search and download. I can add stuff if a different flow would be more useful.

I suspect right now, the simulators are using the API to download the data files, then ignoring the metadata that got them to those files. That's understandable because users can also add individual files to the database itself. Maybe the best we can do is create a unified set of manufacturers and aliases that we all share.
 
Motor files are submitted on a motor page, so we know the motor (and manufacturer).

Looks like I'm wrong and it only returns the official name and abbreviation. I could fix that...

The API takes a list of motor ID to get data files for. This means that you would have already found the motor using search or something and thus have the exact manufacturer info.

Note that flow was originally designed for programatic search and download. I can add stuff if a different flow would be more useful.

I suspect right now, the simulators are using the API to download the data files, then ignoring the metadata that got them to those files. That's understandable because users can also add individual files to the database itself. Maybe the best we can do is create a unified set of manufacturers and aliases that we all share.
Sounds like the answer is we need to figure out how a single manufacturer can end up with two entries in our filter (like Estes vs. Estes Industries).

Though it also sounds like we probably shouldn't worry about what's wrong with what we're doing now; we should just switch to grabbing your motor list and use that to populate our filters (to do that, we'd need you to give us the whole set of aliases for the motor). When a user adds a motor we see if its manufacturer is recognized and associate it with that manufacturer if it is; if it isn't we just add whatever they entered as the manufacturer to our filter.
 
Sounds like the answer is we need to figure out how a single manufacturer can end up with two entries in our filter (like Estes vs. Estes Industries).

Though it also sounds like we probably shouldn't worry about what's wrong with what we're doing now; we should just switch to grabbing your motor list and use that to populate our filters (to do that, we'd need you to give us the whole set of aliases for the motor). When a user adds a motor we see if its manufacturer is recognized and associate it with that manufacturer if it is; if it isn't we just add whatever they entered as the manufacturer to our filter.
It's not clear to me that would solve the Quest/Aerotech issue for Q-jets, though.
 
It's not clear to me that would solve the Quest/Aerotech issue for Q-jets, though.
I believe the branding is “Q-Jet by AeroTech” now and “Quest by AeroTech” is reserved for the low-power kit and equipment line. I think going with AeroTech for the Q-Jet motor line and Quest for any legacy motors should be fine.
 
I believe the branding is “Q-Jet by AeroTech” now and “Quest by AeroTech” is reserved for the low-power kit and equipment line. I think going with AeroTech for the Q-Jet motor line and Quest for any legacy motors should be fine.
The problem is the *most* of the Q-jets (not the legacy Quest motors) are listed under Quest, and only a few are listed under Aerotech.

In my opinion it would be *helpful* for the Q-jets to be distinguishable, somehow, from the other Aerotech motors. But in any case they should all be listed the same.
 
ThrustCurve.org also has an "alternate manufacturer" for cases where a motor was resold under a different branch. For example AeroTech motors sold by Apogee. So there's not even a single manufacturer for some motors.

The state of the manufacturers is kind of a mess because of changes over the years and rebrandings, even aside from the inconsistent references in the data files.

Also consider Kosdon, KBA, Animal, CTI; Is the manufacturer really important or do fliers just care that it "uses snap-ring cases"? Maybe we should take a step back and rethink the motor selection process. I've long advocated a browser type approach instead of having the flier pick specific motors. Hence the "motor browser" and "motor guide" features on ThrustCurve.org.
 
ThrustCurve.org also has an "alternate manufacturer" for cases where a motor was resold under a different branch. For example AeroTech motors sold by Apogee. So there's not even a single manufacturer for some motors.

The state of the manufacturers is kind of a mess because of changes over the years and rebrandings, even aside from the inconsistent references in the data files.

Also consider Kosdon, KBA, Animal, CTI; Is the manufacturer really important or do fliers just care that it "uses snap-ring cases"? Maybe we should take a step back and rethink the motor selection process. I've long advocated a browser type approach instead of having the flier pick specific motors. Hence the "motor browser" and "motor guide" features on ThrustCurve.org.
Depends on what you are doing. If you are exploring, sure.

If you doing specific sims with specific motors, not so much.

I'd also wonder how many people are really searching for more than Estes, Aerotech,and CTI.

But having a consistent set of best fit manufacturers would be good. I tossed some updated code for openrocket that's pulls from thurstcurve because of some of it (and some of it was old Java code in OR).
 
Depends on what you are doing. If you are exploring, sure.

If you doing specific sims with specific motors, not so much.
If you're doing a "specific sim with a specific motor", why should the manufacturer be an impediment? Maybe the best would be to enter the motor name and then if there are multiple manufacturers you would see their names.

I guess what I'm really suggesting is that having to enter (or sort by) manufacturers seems to be clumsy and maybe a search-like interface is better.
 
What would a "search-like interface" be that's not what's already there? Fixing the manufacturer name issue would make the existing search easier to use, but other than that I don't see what's missing.
 
What would a "search-like interface" be that's not what's already there? Fixing the manufacturer name issue would make the existing search easier to use, but other than that I don't see what's missing.
You could enter the motor date code, and make sure the correct motor data is loaded for that particular motor.
 
What would a "search-like interface" be that's not what's already there? Fixing the manufacturer name issue would make the existing search easier to use, but other than that I don't see what's missing.
Let's go back to the beginning. Why is the variation in manufacturers a problem? I suspect it's because it's the primary sort and the main interface for picking motors is scrolling a list.

Note that I'm not against standardizing the manufacturer names in Rocksim and/or OpenRocket. I'm just suggesting that there might be an option to improve the user interface as well.

If I misunderstood the problem, maybe someone can explain it more explicitly...
 
Let's go back to the beginning. Why is the variation in manufacturers a problem? I suspect it's because it's the primary sort and the main interface for picking motors is scrolling a list.

Note that I'm not against standardizing the manufacturer names in Rocksim and/or OpenRocket. I'm just suggesting that there might be an option to improve the user interface as well.

If I misunderstood the problem, maybe someone can explain it more explicitly...
Hmm. For me it’s more about *filtering* than sorting (in OR, mostly).

In my opinion, Q-jets are qualitatively different from other motors (either Aerotech or otherwise) and I often want to be able to explicitly include or exclude them. When some are listed as Quest and some as Aerotech it becomes hard or impossible to do that. There is no metadata that helps me identify Q-jets.

Now, if they were just another Aerotech product line, then I don’t even know what I’d suggest. But since they are sold as Quest, and other Q-jets *are* listed as Quest, it’s a frustrating inconsistency that breaks my ability to filter them
 
In a more general sense, I too see it as a filtering field, not a sorting field. Since I can already use manufacture as a filter, if the manufacturer names were made consistent then I would have nothing else to ask for (on this topic).
 
Back
Top