New Motors Certified, April 2024 (Aerotech)

[Alan Whitmore]

My second message describes the Aerotech new motors certified on March 30 and April 14, 2024.

The Aerotech M2700W-PS is the first reload kit designed for the new 75/10240 hardware, which is more than 48.5” long with the forward and aft closures. The total impulse is 10,322 N.s with an average thrust of 2717 N. The burn time is 3.799 seconds. The interesting fact about this motor is that the total impulse, 10,322 N.s, places it just barely in the N range, but Aerotech has called it an M. This makes it directly comparable to the Aerotech M1939W, which fits the 98/10240 hardware, which is also, according to the NAR/TRA/CAR combined motor list, an N. Nothing in NFPA 1125 prohibits this classification, and no TRA or NAR level 3 flyer will be influenced in any way. Both are full M’s or baby N’s, and your performance might be in either range on any given day. For example, TMT tested 2 of these motors and one produced 9969.7 N.s, while the other produced 10,637 N.s.

The second certification was the Aerotech L2775ST-PS reload kit for the 75/3840 hardware. The propellant is the very fast Super Thunder, giving a burn time of 1.135 seconds! The total impulse is 3150 N.s and the average thrust is 2774 N.

Finally, on April 14 TMT finished up the certification process for the new Q-jet by Aerotech B14-T 18mm motor. This single-use motor produces a total impulse of 4.975 N.s with an average thrust of 12.995 N. The burn time is 0.383 seconds.

 

[JohnCoker]

FYI, for ThrustCurve.org I put the Q-jet motor under the "Quest" manufacturer with AeroTech as the "related mfr". Thus it should be findable under either (or of course just by searching for "B14").

 

[FredA]

Quite the "burp" on the M-2700 burn #1.......surprising.

 

[kjhambrick]

@JohnCoker --

I've never submitted a motor to ThrustCurves.org ...

I see no thrust curve has been submitted yet for the Quest by Aerotech B14T.

Attached is a preliminary B14T.eng that I extracted from Alan's post.

Here is a gnuplot of the data:

Total Impulse is pretty close to cert, Avg Thrust is a little different because the actual burntime is a little longer than certified but the total time more-or-less matches the plot ...

-- kjh

EDIT: p.s. Aside from not being completely satisfied with the thrust curve between 0.22 sec and 0.34 sec, another reason I have not submitted the .eng file is I am unsure what the Manufacturer Code should be on the header line ( I used the old-timey 'A' Code ) ...

 

[JohnCoker]

Nice work, @kjhambrick. Use "Q" for the manufacturer (old style) or spell it out as "Quest".

 

[kjhambrick]

Thanks John, I'll submit it with the Q Mfg Code

-- kjh

EDIT: done

 

[Alan15578]

@JohnCoker --

I've never submitted a motor to ThrustCurves.org ...

I see no thrust curve has been submitted yet for the Quest by Aerotech B14T.

Attached is a preliminary B14T.eng that I extracted from Alan's post.

Here is a gnuplot of the data:
View attachment 641685
Total Impulse is pretty close to cert, Avg Thrust is a little different because the actual burntime is a little longer than certified but the total time more-or-less matches the plot ...

-- kjh

EDIT: p.s. Aside from not being completely satisfied with the thrust curve between 0.22 sec and 0.34 sec, another reason I have not submitted the .eng file is I am unsure what the Manufacturer Code should be on the header line ( I used the old-timey 'A' Code ) ...

Whitmore's B14 data shows Burns 13-16. So what happened with Burns 1-12? Anomalous, too ugly to show?

 

[Art Upton]

Whitmore's B14 data shows Burns 13-16. So what happened with Burns 1-12? Anomalous, too ugly to show?

That has never been discussed for decades that I am aware of...

 

[kjhambrick]

Attached is the L2775ST.eng file and a plot.


I'll paste the data into thrustcurve.org next.

-- kjh

EDIT: All done: ThrustCurve,org > AeroTech L2775ST-PS

 

[MClark]

When I did TMT the burn numbers were for the day.
Example
First motor, 1, 2, 3
Second motor, 4, 5, 6

 

[kjhambrick]

Here is an M2700W thrust curve:

I tried to match it to Alan's Average Total Impulse ( 10.322 Ns ) using an average of the two test samples.

Submitted to ThrustCorve.org > M2700W

-- kjh

 

[DaHabes]

Nice work, @kjhambrick. Use "Q" for the manufacturer (old style) or spell it out as "Quest".

Rocksim 11 now updates the motor file from Thrustcurve. Using different manufacturer names for the same manufacturuer (Q vs. Quest) now matters. It would be helpful to have a standard name per manufacturer going forward and it would be REALLY nice to remediate existing entries as needed to conform, otherwise it will make the motor search in Rocksim wonky (not to mention there are duplicate entries in Thrustcurve which results in duplicate entries in Rocksim - ugh).

 

[JohnCoker]

Rocksim 11 now updates the motor file from Thrustcurve.

This feature has been there for a while, but perhaps it was more manual in the past.

Using different manufacturer names for the same manufacturuer (Q vs. Quest) now matters. It would be helpful to have a standard name per manufacturer going forward and it would be REALLY nice to remediate existing entries as needed to conform, otherwise it will make the motor search in Rocksim wonky

I think a variety of names is inevitable in files created by hand and many from the past. What ThrustCurve does is have a set of manufacturers, and recognize aliases for them. For example, the official name is "Quest Aerospace", but that never appears in motor files. Instead a variety of abbreviations are used: "Quest", "Q" and "QU" are the ones I've run across.
https://www.thrustcurve.org/manufacturers/Quest/details.html
All the ThrustCurve APIs standardize manufacturers (there is an single database ID per manufacturer and the names are just metadata).

(not to mention there are duplicate entries in Thrustcurve which results in duplicate entries in Rocksim - ugh).

Files may be submitted by multiple people, and in different formats. ThrustCurve shows the most recent file first, but does not remove other entries. I'm not sure that they're really "duplicate"; someone spent time making the file and submitting it.

Each distinct motor has a database ID in ThrustCurve and won't get confused between an "AT G80" and an "AeroTech G80T". (Motor "names" also suffer from the same spelling variations as manufacturers.)

IMO, OpenRocket and RockSim need to handle these variations, since I don't think they're going away. I suggest that adopting a database orientation (with an ID for each manufacturer an motor) will fix most of this problems and improve the user experience.

I'd be happy to work with the developers of those programs if there is something the ThrustCurve API can do to make it easier. (Currently each distinct entity has an ID, which the API uses and the names are just metadata.) However, since they will still need to work with files manually added to their respective databases, I don't think that will entirely solve the problem.

 

[Alan Whitmore]

Whitmore's B14 data shows Burns 13-16. So what happened with Burns 1-12? Anomalous, too ugly to show?

"never use more ink than you need to make your point."

 

[DaHabes]

This feature has been there for a while, but perhaps it was more manual in the past.

However, since they will still need to work with files manually added to their respective databases, I don't think that will entirely solve the problem.

John, Rocksim 11 now updates the engines files in real-time, automatically, when you open the program; you aren't given a choice (yes, that is a problem)! Before, you MIGHT get updates when Rocksim issues updates, but most updates had to be done manually by the user to the engine database and import the updated file manually. That's why there is an EngEdit program. I've been doing this forever to keep MY version of the motor database up to date. With all of the motors Aerotech has been adding in recent years, it's been a regular thing AND you have to be aware of new motors that come out, whether you follow the updates in TRF or see an ad from the manufacturer (which works for Aerotech, but NOT for CTI or Loki - new stuff, if any and rarely, that comes from them is really word-of-mouth only). Finally, I updated my version to (stupidly, now) to include a designation to a motor being a reload in the name, since you can't tell what motors are reloads or SU in the Rocksim simulation list and, to me, it matters, since it affects prep requirements, and I can't remember all that detail. Now those motors show up as invalid in my simulations list since they are no longer in the DB in RS 11 - all of my manual edits for the last decade are gone, and I wasn't given a choice (but I digress) ...

The motor DB is massive and multiple entries for the same motor is an annoyance at best and an issue for me. If you select by manufacturer, you will either miss some motors when searching (AT vs. Aerotech) or you have to search for every variant of a manufacturer's name, which assumes you know them all or you have to search for ALL motors, which becomes an unholy mess (I don't fly CTI of Loki motors, so don't want them in my search, at all). I edited my motor file to standardize on Aerotech as the name years ago (getting rid of all aliases), and, now, those updates are kaput (gone!) [deep sigh] ...

I doubt if Apogee will want to make changes to the data they pull (I wouldn't), since there is no standard naming enforced in the source data. It's metadata and anyone can put in anything. I suspect most motor files submitted to Thrustcurve are cut/pasted/updates of other motors with the appropriate metadata modified, with the manufacturer's name unedited. No one builds a motor file from scratch, that would be nuts at this point. As we say in the IT world GIGO - without verifying the data on input (aka, manufacturer's name), it's a crapshoot.

Now, if there were a form for entering motor data into Thrustcurve which generated both a .eng and .rse file for a motor, with validation behind each data entry field, then standardization is possible. I know, that's a lot of work, but it fixes the issue permanently (along with a subsequent existing data cleanup effort). I would offer to help do that if I were a programmer; unfortunately, my skillset favors the analyst, process and project management components of the IT world. I suck as a programmer.

I know this is beyond the original scope/intent of updates to the Thrustcurve data, but as an IT guy, I know that's what is needed to make it work the way everyone would want it to work - we want valid, reliable data.

So, who should do this? It would be in the best interests of Tripoli and NAR to spearhead such an effort. Without motors, we don't have much of a hobby, except for the research guys. What sense does it make to certify motors but then have the data for those certifications not be validated and standardized going forward? That's a bit ridiculous when you think about it.

So, there is no easy answer, only opportunities (said tongue-in-cheek).

 

[JohnCoker]

I'll try one more time: within ThrustCurve.org (and thus through its API) the motor and manufacturer are identified with database IDs and everything else is just metadata. There is no need to extract metadata from the RASP/RockSim files. If the simulators are just using the API to download the data files and ignoring the standardized metadata in ThrustCurve, that is a missed opportunity.

I agree that "cleaning up" the simfiles in ThrustCurve could help, but I think it's a short-term solution that will break as soon as the next file is submitted since the formats are naturally loose. (I also don't want to take responsibility for the individual files nor add any more barriers to submitting data.)

Ironically, the first iteration of the web site was based on the idea that I would get the test stand data from the cert organizations and produce simfiles from that. That was never fully realized because the cert orgs are not willing to share the data (other than a brief period when Sue McMurray was TMT chair). Maybe we could start discussions within NAR, TRA and CAR about making high-quality data available and/or how to auto-generate simulator files.

 

[DAllen]

USLI teams are going to love that L2775

 

[Alan Whitmore]

I'll try one more time: within ThrustCurve.org (and thus through its API) the motor and manufacturer are identified with database IDs and everything else is just metadata. There is no need to extract metadata from the RASP/RockSim files. If the simulators are just using the API to download the data files and ignoring the standardized metadata in ThrustCurve, that is a missed opportunity.

I agree that "cleaning up" the simfiles in ThrustCurve could help, but I think it's a short-term solution that will break as soon as the next file is submitted since the formats are naturally loose. (I also don't want to take responsibility for the individual files nor add any more barriers to submitting data.)

Ironically, the first iteration of the web site was based on the idea that I would get the test stand data from the cert organizations and produce simfiles from that. That was never fully realized because the cert orgs are not willing to share the data (other than a brief period when Sue McMurray was TMT chair). Maybe we could start discussions within NAR, TRA and CAR about making high-quality data available and/or how to auto-generate simulator files.

I would be more than willing to share the processed test stand data with you. There must first be some discussion of what data goes into constructing a "typical" thrust curve and precisely how that curve is constructed. For G and smaller motors there are a minimum of 10 tests, which, at 1000 samples/sec produce an immense amount of digital data. What do you want and what do you propose to do with it?
Consider the discussion started.

 

[kjhambrick]

I would be more than willing to share the processed test stand data with you. There must first be some discussion of what data goes into constructing a "typical" thrust curve and precisely how that curve is constructed. For G and smaller motors there are a minimum of 10 tests, which, at 1000 samples/sec produce an immense amount of digital data. What do you want and what do you propose to do with it?
Consider the discussion started.

Alan --

What do you have to share ?

Sue McMurray offered, Fred Brenion, Tim Van Milligan and I an opportunity to generate thrust curves from TMT Data back in Sep 1999.

She sent us an Excel file with summary info along with one-or-more .zip files with 'one most representative sample' of the raw test stand data for each motor referenced in the Excel File.

The motor data was in .prn files ( EDIT: but they are self-referenced as .dap files within )

Sue selected the representative samples from among multiple test firings.

I don't know how she selected the representative samples.

EDIT: I went and looked at a few of the TMT Certifications and there was a Typical Thrust Curve on each. Maybe reference that Test Stand Data File and the .eng files could be extracted from the data for the typical thrust curve ( more or less what Sue must have done, I suppose )

Attached is Sue's kick off email, her Excel summary and the raw data for an AT H180W

I wrote UNIX scripts to process the raw .prn files, tweak them a tad to match the certified total impulse and then to generate ,eng and .jpeg files for each motor, more or less automatically.

I imagine you've got the metadata for each TMT testing session as well as the individual test stand files.

What does your testing session Metadata summary look like ?

And what do raw TMT test stand files look like these days ?

Thanks !

-- kjh

p.s. I can't commit to anything right now due to time constraints but I would be happy to share the scripts I wrote way back when and help make them work with your current TMT Testing data sets.

I also attached the following:

1 - aeh180w.prn.txt - raw test stand data for an AT H180W tested in 1997
2 - aeh180w.raw.txt - preprocessed aeh180w.prn data merged with Sue's Excel Metadata
3 - aeh180w.eng - the resulting RASP .eng file
4 - aeh180w.jpg - gnuplot picture of the thrust curves ( raw TMT.prn and processed RASP.eng )

 

[JohnCoker]

I would be more than willing to share the processed test stand data with you. There must first be some discussion of what data goes into constructing a "typical" thrust curve and precisely how that curve is constructed. For G and smaller motors there are a minimum of 10 tests, which, at 1000 samples/sec produce an immense amount of digital data. What do you want and what do you propose to do with it?
Consider the discussion started.

I think that if the cert. orgs could publish "official" data files, we'd save the need for people to create their own. This would also help with the issues DeHabes raised because the files would be created through a single process, at least for recently-certified motors.

As to how they could do this, I would be willing to add a feature to ThrustCurve to reduce the data appropriately, once we decide what is "appropriate." It would be easy to create a simfile from a single firing. It would also be straight-forward to upload multiple firings and average the results.

Do we have any idea if NAR and CAR would participate? Some NAR cert. docs include simfiles, so maybe S&T is already on board.