SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
I am using rev 2727 but I just did a SVN update and not sure what I have now (got a strange error message).
How can I verify what rev I have now?

It should be displayed in the properties of the trunk. Or you can update the trunk and you should get the latest version. Please close VS while you update as I organized some source files and did some changes to some projects, so it should be "less error-prone" to update with VS closed.
 

Wolf

Donator
Donator
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire

Wolf

Donator
Donator
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan
Whenever it will be, one month or one light-year from now, I think it will be a giant leap for SSU mankind :thumbup:
 

Wolf

Donator
Donator
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan
I did some research and was able to get the target data to feed the DEORB MNVR PADs for the first 6 Shuttle missions (STS-1 to STS-6). We also have the PAD for STS-135 available from the mission's Executive Package so that makes 7 missions in total where PEG-4 targets are available.

Is there anyone willing to test those against SSU?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
I did some research and was able to get the target data to feed the DEORB MNVR PADs for the first 6 Shuttle missions (STS-1 to STS-6). We also have the PAD for STS-135 available from the mission's Executive Package so that makes 7 missions in total where PEG-4 targets are available.

Is there anyone willing to test those against SSU?

Can you also get the TLE of the missions? Otherwise we would be comparing apples to oranges.
 

Wolf

Donator
Donator
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan
Can you also get the TLE of the missions? Otherwise we would be comparing apples to oranges.

Yes Sir:
https://celestrak.com/NORAD/archives/STS/

the latest available are quite close to the TIG time so, correct me if I am wrong, they should work well for deorbit and reentry testing.

I have used them already but in most cases I heave huge VGO's residuals after the burn with resultant HP values up to 6-8 NM higher than target/nominal ones, so unless you trim a lot with RCS or pre-bank at E.I. they won't work..
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Yes Sir:
https://celestrak.com/NORAD/archives/STS/

the latest available are quite close to the TIG time so, correct me if I am wrong, they should work well for deorbit and reentry testing.

I have used them already but in most cases I heave huge VGO's residuals after the burn with resultant HP values up to 6-8 NM higher than target/nominal ones, so unless you trim a lot with RCS or pre-bank at E.I. they won't work..

At least we can then be sure that they work out.
 

Wolf

Donator
Donator
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan
These are the MNVR PADS with data taken from missions' AtoG Transcripts. NOTE: For STS-1 there is a discrepancy between the DVtot and TGO between the Transcript and the official MNVR PAD (which I retrieved from the Operational Flight Plan). I have reported both of them kin the PAD for clarity. For STS-2 to STS-6 the data are from the Transcript so it was not possible to cross check them against the real MNVR PAD, in the STS-135 case it is just the opposite: PAD available but no Transcript.

View attachment STS-1 Deorbit MNVR PAD.pdf

View attachment STS-2 Deorbit MNVR PAD.pdf

View attachment STS-3 Deorbit MNVR PAD.pdf

View attachment STS-4 Deorb MNVR PAD.pdf

View attachment STS-5 Deorbit MNVR PAD.pdf

View attachment STS-6 Deorbit MNVR PAD.pdf

View attachment STS-135 Deorbit MNVR PAD.pdf
 

Wolf

Donator
Donator
Joined
Feb 10, 2008
Messages
1,091
Reaction score
11
Points
38
Location
Milan
Sidenote: I was quite surprised to see that for all the first missions the HP values are close to ZERO or even negative (STS-3 beign -17NM !) STS-135 is different with a HP= +25NM (I think all the ISS missions were similar).
Does that depend on the entry orbit altitude (HA/HP)?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Once again, the inaccuracies of MECOTool has shown themselves. I was trying to get a accurate post-MECO trajectory for STS-107, based on the numbers in the STS-107 Mission Report. Using these numbers into MECOTool yields a too low target altitude in Orbiter. I encountered the same problem when trialing the MECO parameters for STS-109, in the end I had tell it to aim for a target altitude 10 km above that of what I wanted. It seems that MECOTool is seriously lowballing the numbers.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Once again, the inaccuracies of MECOTool has shown themselves. I was trying to get a accurate post-MECO trajectory for STS-107, based on the numbers in the STS-107 Mission Report. Using these numbers into MECOTool yields a too low target altitude in Orbiter. I encountered the same problem when trialing the MECO parameters for STS-109, in the end I had tell it to aim for a target altitude 10 km above that of what I wanted. It seems that MECOTool is seriously lowballing the numbers.

Which altitude is too low?

MECO?
Initial AP?
Initial PE?
AP after OMS1?
PE after OMS1?
AP after OMS2?
PE after OMS2?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Which altitude is too low?

MECO?
Initial AP?
Initial PE?
AP after OMS1?
PE after OMS1?
AP after OMS2?
PE after OMS2?
Everything is post-MECO, pre-OMS-anything, MET around 10:40, few seconds after MPS Dump termination. Target altitude in my mind is MECO apogee taking in account things like +Z, +X and MPS dump. It's the apogee that's off. I had to increase the altitude to 308 km in MECO tool to get the result I wanted. STS-107 was a PE mission, so RTHU, OMS Assist and DI. According to the mission report post-OMS 2 orbit was 146x156 n.mi, with the burn occurring at MET 41:24 with a dV of 185.7 fps.

How sensitive are the MECO calculations to vehicle mass? And is the Orbiter weight parameter in MECOTool used at all? Right now it is fixed at 120k lbs which is below the very dry and empty mass of any of the orbiters.
Initial design goal weight of the orbiters was 150k lbs, but as we all know, that was unrealistically light.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Everything is post-MECO, pre-OMS-anything, MET around 10:40, few seconds after MPS Dump termination. STS-107 was a PE mission, so RTHU, OMS Assist and DI. According to the mission report post-OMS 2 orbit was 146x156 n.mi, with the burn occurring at MET 41:24 with a dV of 185.7 fps.

How sensitive are the MECO calculations to vehicle mass? And is the Orbiter weight parameter in MECOTool used at all? Right now it is fixed at 120k lbs which is below the very dry and empty mass of any of the orbiters.
Initial design goal weight of the orbiters was 150k lbs, but as we all know, that was unrealistically light.

Actually it is not used at all there. It just defines the state vector at MECO. But it is possible highly realistic that the fixed FPA at MECO is a bad simplification. I did not have much information about how the ET trajectory is planned for all missions, that is why I simply guessed there. The real MECO target would include ET dump area just like it will include AOA.

Everything regarding mass happens inside the Shuttle AP, but we also have no ILOADS for vehicle mass for the first OMS maneuvers.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Actually it is not used at all there. It just defines the state vector at MECO. But it is possible highly realistic that the fixed FPA at MECO is a bad simplification. I did not have much information about how the ET trajectory is planned for all missions, that is why I simply guessed there. The real MECO target would include ET dump area just like it will include AOA.

Everything regarding mass happens inside the Shuttle AP, but we also have no ILOADS for vehicle mass for the first OMS maneuvers.
OK. As far as ILOADs are concerned, currently the MASS parameter is automatically computed whenever 104/105/202/30x is entered.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
Once again, the inaccuracies of MECOTool has shown themselves. I was trying to get a accurate post-MECO trajectory for STS-107, based on the numbers in the STS-107 Mission Report. Using these numbers into MECOTool yields a too low target altitude in Orbiter. I encountered the same problem when trialing the MECO parameters for STS-109, in the end I had tell it to aim for a target altitude 10 km above that of what I wanted. It seems that MECOTool is seriously lowballing the numbers.

Please, what inaccuracies does MECOTool have????
I'll say it once again, I've checked the math it and it's all correct.

As I know it, our "trajectory issues" are:
1) MECOTool doesn't take into account the -Z translation;
2) MECOTool doesn't take into account a possible post-MECO +X translation;
3) MECOTool doesn't take into account the MPS dump;
4) MECOTool doesn't take into account the MECO perigee altitude (I made a version where MECO Pe is a parameter, but I think I haven't committed it because MECOTool is so hated...);
5) MECOTool doesn't take into account atmospheric drag post-MECO;
6) for Standard Insertions, the "standard" MECO target probably changed during the program, and is probably different with the flight inclination... MECOTool has 1 MECO SI target, which will make the OMS-1/2 not match for flights with a different MECO SI target;
7) our AscentDAP is unstable in pitch prior to MECO, generating a FPA error;
8) our AscentDAP has generic SSME tailoff dV values, which will produce an underspeed for heavy vehicles, and overspeed for light ones.

IMO, #7 is by far the one with most blame. The c.g. moving in big steps, plus our algorithm only working in "constant thrust" mode, when late in the ascent we need a "constant acceleration" mode, should be to blame.
On the MECOTool, #4 is the big one and it affects only the OMS-2 MET and dV (not altitude) (and where the ET reenters). IMO the others are not large "error generators" but yes, they do affect OMS-2 time, altitude and dV, but it should be only pennies. So, IMO even with its short comings, MECOTool is very good.

There's also the unexplained "52NM MECO", which apparently means nothing as flights allegedly kept hitting MECO at 57NM. :shrug: If MECO really is at 52NM, and we are targeting 57, this would probably be second on the list behind issue #7.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
The problem in MECOTool isn't the math. That is "tolerable". Its the assumptions that I took for getting to the goal quickly. Its as in this nice quote: "The errors of a theory are rarely found in what it asserts explicitly; they hide in what it ignores or tacitly assumes"

A new MECOTool would need to take this all in account and ideally also calculate other constants for the ascent guidance that make its work easier (for example, tail-off predictions, MPS dump, etc)
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
The problem in MECOTool isn't the math. That is "tolerable". Its the assumptions that I took for getting to the goal quickly. Its as in this nice quote: "The errors of a theory are rarely found in what it asserts explicitly; they hide in what it ignores or tacitly assumes"

A new MECOTool would need to take this all in account and ideally also calculate other constants for the ascent guidance that make its work easier (for example, tail-off predictions, MPS dump, etc)
After reading GLS's post, this are my thoughts exactly. MECOTool worked great in the past, when the ascent was simpler in terms of events. But now that we have a more fleshed out MPS that includes the tail-offs and MPS dumps (this is what, a 10-15 fps dV addition?), MECOTool has gotten out of date. And I think that shows as it still includes an option for SSU v1.06!

But does the ascent guidance math really explain a 19.088 km discrepancy? That's the difference I came to when I finally reached the MECO apogee target I wanted. The target deltas are as follows: MECOVel: 4.042308, MECOFPA: 0.053378.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
But does the ascent guidance math really explain a 19.088 km discrepancy? That's the difference I came to when I finally reached the MECO apogee target I wanted. The target deltas are as follows: MECOVel: 4.042308, MECOFPA: 0.053378.

Yes. 10-20 fps is about the magnitude of the factors we are currently ignoring. But MECOTool was already slightly inaccurate before, so no big surprise.
 
Status
Not open for further replies.
Top