SiameseCat
Addon Developer
The Ascent Aborts Flight Procedures Handbook gives the SRB staging altitude as 152,545 ft (46.5 km). With the new CG code, staging occurs around 42 km.
Space Shuttle Ultra 1.25 Revision B development
- Thread starter Urwumpe
- Start date
What could make us not to make the altitude despite having the actual pitch table? Could our drag/PMI settings be wrong?
---------- Post added at 10:53 PM ---------- Previous post was at 10:21 PM ----------
Here's a comparison table between SSU and the STS-135 Ascent CC. Format is MET, Alt(km), H.(m/s²). According to the table, we're too high at 30 seconds while being too fast in H. at the same time. It's down-hill from there, being too low and too slow. So we're losing performance around the Max Q/throttle bucket that is never regained.
0:30|3.09/188|2.70/199.5
0:50|7.48/249|7.8/300.3
1:10|13.35/338|15.3/431.7
1:30|21.35/464|25.2/570
1:50|31.36/553|37.8/659.4
Another ascent problem is that the roll program occurs too early and too low. After cross-checking with independent sources, I have determined that correct speed to use in AscentGuidance.cpp is 64 m/s². This yields an roll program start at around T+10 and 300 m which is consistent with actual launches.
Cras
Spring of Life!
- Joined
- Apr 13, 2011
- Messages
- 2,215
- Reaction score
- 0
- Points
- 36
- Location
- Los Angeles
- Website
- www.youtube.com
10 seconds might be just a tad too long to wait for the roll program. I timed it once from footage I shot myself for the Launch MFD launch profile and found it to be near 8 seconds...not a big difference.
Most sources I looked at had the roll program being initiated when the vehicle reached at a velocity of 135 mph (60 m/s²), so I guess that could be used instead.
Just a quick little image for the coders of SSU. If it were possible, could we recreate the digital ADI system used in the real shuttle? I'd add a lot more realism to the entire flight rather than the default surface MFD; Here is the best image of the display that I could find:
Attachments
SiameseCat
Addon Developer
The ADI ball is a pain to draw on an MFD. The surface MFD works well enough, so I don't think it's worth the effort to implement the ADI ball - there are a lot of more important things.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Also, the resolution of the MFDs is, despite all tricks that we used, still less than the 1024x1024 of the real MEDS. It is a compromise now, and not really capable of rendering a readable MEDS PFD.
Cras
Spring of Life!
- Joined
- Apr 13, 2011
- Messages
- 2,215
- Reaction score
- 0
- Points
- 36
- Location
- Los Angeles
- Website
- www.youtube.com
The Surface MFD though uses the wrong units for flying the Space Shuttle. If SSU is truly to be a complete simulation of the Shuttle and be able to use the real checklists to fly it, something is needed to show things like nautical miles, feet, feet per second. Not to mention the indicators for the commanded attitude since a few times the orbiter was put into correct attitude by hand.
---------- Post added at 10:35 AM ---------- Previous post was at 10:31 AM ----------
Yeah that is what I recall as well. Launch MFD I think only could determine the roll time by altitude so I had to time it and get a rough guesstimate that way, but if you have the control over being able to do it at a speed, then obviously that would be the ideal way to go, as long as the Shuttle accelerates correctly.
---------- Post added at 10:35 AM ---------- Previous post was at 10:31 AM ----------
Yeah that is what I recall as well. Launch MFD I think only could determine the roll time by altitude so I had to time it and get a rough guesstimate that way, but if you have the control over being able to do it at a speed, then obviously that would be the ideal way to go, as long as the Shuttle accelerates correctly.
SiameseCat
Addon Developer
There's some commented out stuff in Common.cpp that seems to reference JSC-19041 Rev. F, section 4.3, which is the Booster Systems Briefs.
SiameseCat
Addon Developer
That's the thrust curve. JSC-19041 4.3 doesn't have any useful information about the propellant mass profile.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes. The performance summary of the SRBs contains a few tables, I think it also contained estimated propellant mass during the burn time. (It is a bit hard to measure on a SRB)
SiameseCat
Addon Developer
Apart from fixing ticket 20 (the launch problem), what else do we need to do before the next release?
I'm in the process of fixing ticket 23 (HAC problems). I've also got a working autopilot from the start of TAEM up to the preflare, which I'd like to have in the next release. If everything goes well, I can check this stuff in tomorrow.
I would like to see tickets 21(ODS animation), 14(ET texture) and 11(MECOTool) closed.
Ticket#14 seems to deal only with the post-SRB stage texture swap, but loading of a different main texture should be implemented.
SiameseCat
Addon Developer
For ticket 14, the ET textures need to be fixed. At the moment, the burnt texture (and some of the other textures, I think) don't work with the latest ET mesh. I can add scenario file entries for the ET texture name and the burnt ET texture name.
For ticket 11, I can't compile the MECO Tool, so it's up to Urwumpe. Since we're going to redo the tool from scratch, I think it might be better to release the new tool separately once we have it working, instead of holding up the entire release.
For ticket 11, I can't compile the MECO Tool, so it's up to Urwumpe. Since we're going to redo the tool from scratch, I think it might be better to release the new tool separately once we have it working, instead of holding up the entire release.
