lakeroadster
When in doubt... build hell-for-stout!
There's an example rocket that has tube fins... maybe start by modifying that, then others can follow along.
ANNOUNCEMENT: OpenRocket version 22.02 Final is now available for download
- Thread starter neil_w
- Start date
Help Support The Rocketry Forum:
Deleted.
Will re-post process shortly. Sorry.
Will re-post process shortly. Sorry.
OK. Here is what I did. Open the Example Tube Fin Rocket.
[ Shows apogee at 1175ft with the D12-7 in the example file.]
1) Open the "fin set" and un-check the automatic calculations.
2) Set OD to .976in and leave ID at .95 & Wall at .013
3) Change Number of fins to 3
---- Apogee changes to 784ft.
---- In the plot of Drag vs Mach. CD=2.3 @ Mach.25
4) Change Number of fins to 4
---- Apogee changes to 876ft.
---- In the plot of Drag vs Mach. CD=1.9 @ Mach.25
5) Change Number of fins to 5
---- Apogee changes to 999ft.
---- In the plot of Drag vs Mach. CD=1.55 @ Mach.25
6) Change Number of fins back to 6
---- Apogee changes back to original 1175ft.
---- In the plot of Drag vs Mach. CD=1.12 @ Mach.25
____________________________________________________________________
2nd issue
If I wanted to show 3 fins as red and 3 as black in the image. I made 2 sets of 3 fins. (File attached.) The design file looks exactly like the original and should be the same simulation. (ie 1175ft.)
BUT
---- Apogee drops to 573ft
---- In the Plot of Drag vs Mach. CD=4.0 @ almost Mach.25
Any Ideas..... ?
[ Shows apogee at 1175ft with the D12-7 in the example file.]
1) Open the "fin set" and un-check the automatic calculations.
2) Set OD to .976in and leave ID at .95 & Wall at .013
3) Change Number of fins to 3
---- Apogee changes to 784ft.
---- In the plot of Drag vs Mach. CD=2.3 @ Mach.25
4) Change Number of fins to 4
---- Apogee changes to 876ft.
---- In the plot of Drag vs Mach. CD=1.9 @ Mach.25
5) Change Number of fins to 5
---- Apogee changes to 999ft.
---- In the plot of Drag vs Mach. CD=1.55 @ Mach.25
6) Change Number of fins back to 6
---- Apogee changes back to original 1175ft.
---- In the plot of Drag vs Mach. CD=1.12 @ Mach.25
____________________________________________________________________
2nd issue
If I wanted to show 3 fins as red and 3 as black in the image. I made 2 sets of 3 fins. (File attached.) The design file looks exactly like the original and should be the same simulation. (ie 1175ft.)
BUT
---- Apogee drops to 573ft
---- In the Plot of Drag vs Mach. CD=4.0 @ almost Mach.25
Any Ideas..... ?
Yeah: if you add enough additional tube fins it looks like you could go to the moon.
We will investigate.
Thanks for all your hard work, OpenRocket devs! Just installed the new version. Is there any way to show the propellant designations in the motor names again (on the main motor config and sim tabs)? Remembering which motor is which is much harder without those.
Thanks! That seems to be the default, and definitely helps on that dialog. Is there a way to show that on the lists of motor configurations and simulations?
SiboVG
OpenRocket Developer
No, that's currently not possible, but it would be a great feature.
I downloaded the latest OR and while looking for motors to sim, I came across something interesting.
The length of the Aerotech 54/1280 case is all over the place.
Per Aerotech drawings, the length of the case from thrust face to forward end is 12.442" or 316mm. The total length of the case is 12.772" or 323mm. It looks like the J800 is the only one with the right length. I can only guess about the case weights. I would suspect they are all over the place like the lengths. That certainly doesn't make the sims very accurate.
Where do the motor files come from? I assumed Thrustcurve.org and that you are using .rse files, not .eng files. I'm not familiar with editing/updating the thrustcurve.org engine files, but wouldn't mind trying some. I don't have the time to comb through all of them.
If the files on thrustcurve are updated, would that also update OR?
BTW, the Total Weight - Propellant weight, which should be case weight, on Thrustcurve.org for the six 54/1280 motors listed, vary by only about 4.2 oz.
The length of the Aerotech 54/1280 case is all over the place.
Per Aerotech drawings, the length of the case from thrust face to forward end is 12.442" or 316mm. The total length of the case is 12.772" or 323mm. It looks like the J800 is the only one with the right length. I can only guess about the case weights. I would suspect they are all over the place like the lengths. That certainly doesn't make the sims very accurate.
Where do the motor files come from? I assumed Thrustcurve.org and that you are using .rse files, not .eng files. I'm not familiar with editing/updating the thrustcurve.org engine files, but wouldn't mind trying some. I don't have the time to comb through all of them.
If the files on thrustcurve are updated, would that also update OR?
BTW, the Total Weight - Propellant weight, which should be case weight, on Thrustcurve.org for the six 54/1280 motors listed, vary by only about 4.2 oz.
Last edited:
Good find. I'd noticed variations before (like those you show between 314 and 368mm above), but I'd not noticed the gigantic differences you found. It appears the lengths are the same as in the rse data from ThurstCurve. Interestingly, the motors shown in the 700mm range are all out of production, which could be why the data for them have not been corrected.
We do get the motor files from thrustcurve.org, and we use both the .eng and the .rse files. thrustcurve maintains metadata (including length) for all the motors separately from the motor files; we get the metadata from that.
All of the *really* long ones seem to be hybrids. I don't know -- when Aerotech was selling hybrids, did they use a standard motor casing for the grain and stick a tank on it? If so, that would explain what you're seeing.
Of the ones that are close but short (314mm), all the ones I checked said that length came from the certification data.
Yes, if thrustcurve is updated then the next OR release will contain the updated data.
Learn something every day. I never knew Aerotech sold Hybrid motors!
Yes, they got into it back when BATF was trying to shut down high power rocketry. After NAR/TRA won the lawsuit they got out of it (along with pretty much everyone else who got into it then).
I beleive they did, and that does explain it. Cool mystery with a cool solution. Neat that @Handeman found such an interesting anomaly, and neat that you remember the cause. Rocketry has been through many eras of interesting times!
I had actually forgotten until I went on thrustcurve to make sure we didn't have an error, and found that information there. We ought to be displaying it in our motor details... https://github.com/openrocket/openrocket/issues/2069
Great catch.
That’s digging back pretty deep. I think they used standard cases with cellulose fuel grains. Maybe I have an old ad at home.
Otherwise, would different fwd closures - plugged for J1799, extended for the J135- explain those?
The Aerotech Master Motir Matrix (8-24-21) shows 368mm for all 54/1280 motors. I haven’t looked at the individual drawings.
Starfire73
OpenRocket Wannabe
I’m nervous… I’m almost finished with a multiple hours rocket sim project with the 22 beta version. Will the final 22 version affect my sim, or is it a 100% compatible file?
Should be completely compatible.
- Joined
- Jun 4, 2018
- Messages
- 1,296
- Reaction score
- 940
Backup your ork file
Here's a "what do I do?" question about simulator conditions. I'm trying to get a sense of performance of models flown on a warm day at a relatively high altitude site (NARAM-64, Lordsburg, NM). In the simulation conditions under "launch site" I can input a site altitude, and in the atmospheric conditions I could put in the air pressure at that altitude from the standard atmosphere model (or other sources). OR I could do both.
Changing either the site altitude or the pressure affects the altitude kind of as I would expect (the model goes higher than it would launched at sea level using the standard atmosphere.
The question is, should I do one or the other, or both to get the "right" results? Yes, I know I'd need to tweak the temperature to fit as well, but that only happens in one place.
Thanks!
Changing either the site altitude or the pressure affects the altitude kind of as I would expect (the model goes higher than it would launched at sea level using the standard atmosphere.
The question is, should I do one or the other, or both to get the "right" results? Yes, I know I'd need to tweak the temperature to fit as well, but that only happens in one place.
Thanks!
- Joined
- Sep 5, 2009
- Messages
- 3,537
- Reaction score
- 1,672
If the site air pressure comes from a measurement at the field or from a local weather station, I think you can do both. This changes the P0 in the SAM. I think.
Read the RASAero documentation on this topic. It may help. I read it over and over, and I am still confused.
Read the RASAero documentation on this topic. It may help. I read it over and over, and I am still confused.
Something I came across trying to do a file on an existing rocket is that there are no nose cones in OR that match what manufactures actually supply. I put in a feature request in GitHub already.
All the fiberglass kits I've bought in the last 5 years or so have fiberglass nose cones that have a coupler that slides in and forms the shoulder. This works because the first 2 - 4 inches of the base of the nose cone is a tube, not part of the nose cone shape. None of the OR NCs work like this. They all start the shape narrowing from the base.
My work around is, to select a nose cone that is only as long as the section the coupler will NOT fit into and then add a piece of body tube as the lower part of the nose cone. On my 2.2" DX3 the NC is 13" long and the couple fits in 2". So I selected a NC with a similar shape and added a 2" piece of BT to make up the last of the NC. It would be nice if this piece of BT could be added under the NC, instead of an additional piece below the NC.
I suppose I could make the Payload Tube longer instead, but this is less confusing keeping track of where the end cap and any internals for the NC go, at least for me.
All the fiberglass kits I've bought in the last 5 years or so have fiberglass nose cones that have a coupler that slides in and forms the shoulder. This works because the first 2 - 4 inches of the base of the nose cone is a tube, not part of the nose cone shape. None of the OR NCs work like this. They all start the shape narrowing from the base.
My work around is, to select a nose cone that is only as long as the section the coupler will NOT fit into and then add a piece of body tube as the lower part of the nose cone. On my 2.2" DX3 the NC is 13" long and the couple fits in 2". So I selected a NC with a similar shape and added a 2" piece of BT to make up the last of the NC. It would be nice if this piece of BT could be added under the NC, instead of an additional piece below the NC.
I suppose I could make the Payload Tube longer instead, but this is less confusing keeping track of where the end cap and any internals for the NC go, at least for me.
- Joined
- Jun 7, 2011
- Messages
- 260
- Reaction score
- 264
RASAero II uses the launch site pressure and the launch site temperature to calculate the launch site density altitude. Then as the rocket flies on the flight simulation the atmospheric density is varied starting from the density altitude of the launch site as the rocket gains altitude. The launch site temperature is also used to calculate the launch site temperature altitude for speed of sound calculations as the rocket gains altitude. The atmospheric pressure is also used for the pressure altitude of the launch site for varying thrust with altitude.
You can enter the launch site barometric pressure in in-hg if you have measurements at the launch site or from nearby weather stations or airports, but it is based on the technique used at airports. (See the RASAero II Users Manual.) As noted, it can get somewhat confusing.
It is best to just enter the launch site elevation (above sea level) and leave the launch site barometric pressure input blank. RASAero II will calculate the atmospheric pressure at the launch site based on the launch site elevation assuming a Standard Day. When you enter a launch site elevation of 3,900 ft (above sea level), with the launch site barometric pressure entry left blank, then RASAero II will use an atmospheric pressure for the launch site of 3,900 ft above sea level on a Standard Day. An example is shown below.
This is the best approach, as you can easily get the elevation above sea level of your launch site, but very, very few people are taking atmospheric pressure measurements at the launch site, or looking up the barometric pressure/atmospheric pressure on the day of launch for their launch sites.
Charles E. (Chuck) Rogers
Rogers Aeroscience
Thanks @Chuck Rogers.
I had a hunch that by putting in both the atmospheric pressure (from the SAM, NOT modified as they do at airports) and the site altitude I was putting the compensation in twice (and the calculated apogees reflect that). It didn't really make sense to me that both were needed but since both inputs are there and there's no note in OpenRocket to only fill in one or the other (or to use a "corrected to sea level" baro reading), I was left wondering. Since I'm trying to at least see if something I have will work for Precision Fragile Payload (essentially a one-egg TARC-style event) that will be flown at NARAM-64, I need the help of a simulator to map what I observe here (just a few hundred feet above sea level) to what to expect there.
Hopefully someone with knowledge of the inner workings of OR will confirm what you've laid out here for your tool.
In the meantime I need to gather local real data on this model (which is ready for sealer now) to refine the simulation I have built. Then I can feel more confident about corrections for a hot day in July at 4500 feet giving me plausible results.
I had a hunch that by putting in both the atmospheric pressure (from the SAM, NOT modified as they do at airports) and the site altitude I was putting the compensation in twice (and the calculated apogees reflect that). It didn't really make sense to me that both were needed but since both inputs are there and there's no note in OpenRocket to only fill in one or the other (or to use a "corrected to sea level" baro reading), I was left wondering. Since I'm trying to at least see if something I have will work for Precision Fragile Payload (essentially a one-egg TARC-style event) that will be flown at NARAM-64, I need the help of a simulator to map what I observe here (just a few hundred feet above sea level) to what to expect there.
Hopefully someone with knowledge of the inner workings of OR will confirm what you've laid out here for your tool.
In the meantime I need to gather local real data on this model (which is ready for sealer now) to refine the simulation I have built. Then I can feel more confident about corrections for a hot day in July at 4500 feet giving me plausible results.
- Joined
- Jun 4, 2018
- Messages
- 1,296
- Reaction score
- 940
Yeah , right! What about us that have no idea about coding, GitHub or how software is built. Where is the answer? This is not helpful at all. It's like telling us to find the answer in the Minitour's cave.The answer is in here https://github.com/openrocket/openrocket
rharshberger
Well-Known Member
But we do know that the Minotaurs cave was on Crete.....
- Joined
- Aug 6, 2022
- Messages
- 3,257
- Reaction score
- 2,960
Feature request for the next round:
It would be super-awesome if there was a way to "comment out" components of a rocket. e.g., I could have different configurations of fins, nose cones, recovery devices, etc. all in one file, and just select or deselect them to be active in the sim. That way, I could compare different design elements all in one place. As far as I've figured out how to use OR so far, I can delete or modify something, but if I want to retain the old version, I have to save a new file. If I then make a change to some other component, I have to remember to go and manually propagate that change through all the desired versions of the file. If you're looking at differences in multiple components, it leads to an exponential increase in the number of files to be managed.
Would be way better if, when I wanted to try, say, a different fin design, or a parachute instead of a streamer, if I could just tell the program to ignore a component and use a different one, turning components on and off all within the same sim file.
Or is this already possible and I'm just not smart enough to have found the switches yet?
It would be super-awesome if there was a way to "comment out" components of a rocket. e.g., I could have different configurations of fins, nose cones, recovery devices, etc. all in one file, and just select or deselect them to be active in the sim. That way, I could compare different design elements all in one place. As far as I've figured out how to use OR so far, I can delete or modify something, but if I want to retain the old version, I have to save a new file. If I then make a change to some other component, I have to remember to go and manually propagate that change through all the desired versions of the file. If you're looking at differences in multiple components, it leads to an exponential increase in the number of files to be managed.
Would be way better if, when I wanted to try, say, a different fin design, or a parachute instead of a streamer, if I could just tell the program to ignore a component and use a different one, turning components on and off all within the same sim file.
Or is this already possible and I'm just not smart enough to have found the switches yet?
Similar threads
- Sticky
