# ProjectShuttle FDO MFD

#### Donamy

Donator
Beta Tester
So I finally had some time to practice some Rendezvous with SSU and FDO MFD. So far I have succesfully completed STS-114, STS-121 and STS-115. I am still very far from mastering FDO MFD but Indy's walkthrough was very helpful. In all 3 cases I made it to the ISS though the Ti TIGs were not exactly the same as in real life (and in the original FDO MFD plan). In order to keep the Lighting and the vertical velocity within the desired constraints I had to modify the Terminal Initiation TIGs. Long way to go but I am very happy so far.
This tool has been in my wish list since ages and IMHO it brings SSU realism to different level.

Some pics from STS-121 RBar arrival just prior to orbital sunset on July 6th 2006

Discovery 600 feet below the ISS

View of the PB and the Docking Camera in the monitor

A bit of sci-fi with the ISS clearly visible against the darkness of space with the camera switched in Night Vision mode

Nice to see the ISS in the correct config. :thumbup:

#### Wolf

##### Donator
Donator
Nice to see the ISS in the correct config. :thumbup:

I will :thumbup:. With a bit of patience so far I was able to reproduce the ISS AtoZ from 1A to 12A (basically from STS-88 to STS-114)

#### indy91

So I finally had some time to practice some Rendezvous with SSU and FDO MFD. So far I have succesfully completed STS-114, STS-121 and STS-115. I am still very far from mastering FDO MFD but Indy's walkthrough was very helpful. In all 3 cases I made it to the ISS though the Ti TIGs were not exactly the same as in real life (and in the original FDO MFD plan). In order to keep the Lighting and the vertical velocity within the desired constraints I had to modify the Terminal Initiation TIGs.

A bunch of things have to come together for TI to happen at the same time as it happened in reality. Most importantly non-spherical gravity has to be enabled in Orbiter (and the MFD of course). From launch to rendezvous the lighting could be off by a few minutes already due to that. And then very important of course an accurate initial ISS state vector in the launch scenario. In the one or two rendezvous I have flown where those conditions were fulfilled I had TI TIGs that were less than a minute off from reality. And moving it by a few seconds off the ideal lighting doesn't hurt much and was probably done in reality to optimize some of the previous maneuvers.

There also is the case of a low beta angle, in which case TI isn't set at SS - 36 minutes, but SS - 38.5 minutes. I had that with STS-129 but noticed too late that I should have used 38.5min, only when I checked the Execute Packages. The result is the sun right in the face during the TORVA. Definitely was undesirable in reality. So a few missions (not that many probably) will have the lighting at TI moved to 38.5 minutes to avoid that.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
I will :thumbup:. With a bit of patience so far I was able to reproduce the ISS AtoZ from 1A to 12A (basically from STS-88 to STS-114)
You mean 11A, 12A was STS-115. STS-113 brought it to 11A with the addition of the P1 ITS in December 2002, the last ISS mission prior to the fateful STS-107 mission. STS-114 was LF1. Also, the inboard/outboard radiators on S1/P1 were deployed after STS-120/10A. Up until then, only the center radiators had been deployed. The reason for waiting to deploy the remaining radiators was that the FGB solar arrays had to be retracted to provide enough clearance as the Thermal Radiator Rotary Joints (TRRJ, pronounced "targ") rotates the radiators to keep them mostly shaded for optimal cooling performance.

Last edited:

#### Wolf

##### Donator
Donator
You mean 11A, 12A was STS-115. STS-113 brought it to 11A with the addition of the P1 ITS in December 2002, the last ISS mission prior to the fateful STS-107 mission. STS-114 was LF1. Also, the inboard/outboard radiators on S1/P1 were deployed after STS-120/10A. Up until then, only the center radiators had been deployed. The reason for waiting to deploy the remaining radiators was that the FGB solar arrays had to be retracted to provide enough clearance as the Thermal Radiator Rotary Joints (TRRJ, pronounced "targ") rotates the radiators to keep them mostly shaded for optimal cooling performance.

Correct. I haven’t added the P3/P4 truss yet, so it is up to 11A

#### Gingin

##### Member
Nice Indy for the new release
Well done Wolf
Camera mfd looks nice &#55357;&#56397;

#### Wolf

##### Donator
Donator
Is it ok to use FDO MFD (0.1.9) with Non Spherical Gravity enabled?
I am asking since I am checking it with STS-114 and I get an extremely high DV in the plan for the NPC burn. I am using the actual launch date/time with the ISS state vectors uploaded via the closest time available from Celestrak. With Gravity disebled I end up at MECO with a 0.1° RInc and with Gravity enabled I have 0.05°. I guess this does not work well in the latter case since my mis-alignment will likely get bigger and bigger as I proceed with the mission (I guess due to the nodal regression effect) and that is probably why I have such a huge DV for the NPC burn.
Could it be my ISS state vectors are off?

Here is the plan before OMS-2 where NPC DV is 171 fps!

#### indy91

Yes, the MFD should give good results with non-spherical gravity enabled in the most recent versions.

The differential nodal regression can cause as much as 0.5° in two days and I've seen NPC DVs of 200 ft/s and more. I've only really had one case where I got a small DV after the ascent. It could be the ISS state vector, but the SSU ascent guidance might also be the problem. I used the "Scenario Editor TLE" for the target vectors, I wonder if it has a problem with propagating a TLE backwards, because in those cases I had bad results. But that is just a theory, it could just be a SSU issue.

The trajectory calculation in the MFD is always reliable, so if the TI and MC4 DVY are small, then you know that the NPC targeting worked right.

Last edited:

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Scenario Editor TLE definitely has issues with historical TLEs. I experienced this first hand when I was setting up the STS-109 launch scenario, that the HST wasn't where it was supposed to at T0. I knew exactly where it was supposed to be at T0 (directly over Tampa, FL) so I checked when it overflew Tampa and adjusted the epoch accordingly. IIRC, it was to make the epoch earlier by about 83 seconds.

#### GLS

##### Well-known member
Orbiter Contributor
but the SSU ascent guidance might also be the problem.
It is a problem, as it only targets orbital inclination, so launch time is very critical as that is the only way to control LAN. Plus, the pad being in the wrong place, means that even launching at the correct time will very likely not work perfectly.

---------- Post added at 08:59 PM ---------- Previous post was at 08:50 PM ----------

Scenario Editor TLE definitely has issues with historical TLEs. I experienced this first hand when I was setting up the STS-109 launch scenario, that the HST wasn't where it was supposed to at T0. I knew exactly where it was supposed to be at T0 (directly over Tampa, FL) so I checked when it overflew Tampa and adjusted the epoch accordingly. IIRC, it was to make the epoch earlier by about 83 seconds.

I'm pretty sure I've read in some thread that Orbiter doesn't use "our clock time", so launching, e.g., at noon just because STS-XYZ launched at noon, probably won't result in the same trajectory. This will affect the TLE conversion.
Plus, for 28.45º orbits, launching on time almost certainly will not work perfectly as the pad isn't where it should, so the vehicle does a dog leg to correct the inclination, and doing this with no control over LAN... how knows exactly what happens.:facepalm:
What we can do is get a way to convert "our time" to "Orbiter time", and if the TLEs also need a time conversion, figure that out as well, and that should fix the on-orbit issues. For the launch issues, currently it's all about timing, as we lack LAN target capability. Maybe for SSU 6.0... :shrug:

#### indy91

Plus, the pad being in the wrong place, means that even launching at the correct time will very likely not work perfectly.

Quickly ran the numbers for geodetic vs. geocentric latitude for LC-39, targeting 51.6° inclination. I might have simplified the calculation too much, but I am getting a LAN difference of 0.183°. So definitely significant. You would need to adjust the launch time by 44 seconds to account for that.

NASSP of course has to account for that as well and we are using the historically flown targeting polynomials (inclination/LAN as a function of launch azimuth) for the lunar missions with the Saturn V. And the Iterative Guidance Mode really just does a little bit of yaw steering to correct for the wrong launchpad latitude, not very noticable, so it's not really a performance issue.

Plus, for 28.45º orbits, launching on time almost certainly will not work perfectly as the pad isn't where it should, so the vehicle does a dog leg to correct the inclination, and doing this with no control over LAN... how knows exactly what happens.:facepalm:

I've tried launching STS-82 to the HST. The first attempt was at the actual launch time, which happened at the beginning of the launch window, so without yaw steering that gave me a very high relative inclination, 4° or so. Then I tried the middle of the launch window which resulted in about 1°. Then I got tired of it, because I always had to adjust the HST state vector in the launch scenario etc. So I simply moved the Shuttle in the right orbit. I'm sure by manually tweaking the launch time I could have gotten better results, at least good enough so that the HST can be reached without cheating. Just as an example.

And I'll look into the time definition issue, maybe I can figure out how much of a problem it really is. It's also relevant for NASSP of course, but it hasn't caused any noticable problems so far.

#### Urwumpe

##### Not funny anymore
Donator
Orbiter uses MJD, which means, leap seconds are not correctly included.

There is the $\Delta T$ the difference between UT and TT, those could explain it (UT is based on earths real rotation, TT assumes a fixed day length like Orbiter). Its about 60 seconds between the origin of the Julian Date (1858) and today.

#### GLS

##### Well-known member
Orbiter Contributor
Quickly ran the numbers for geodetic vs. geocentric latitude for LC-39, targeting 51.6° inclination. I might have simplified the calculation too much, but I am getting a LAN difference of 0.183°. So definitely significant. You would need to adjust the launch time by 44 seconds to account for that.
If we had an ascent guidance that targeted an actual plane, that would be almost a no-issue, as 44s is pennies in a 10m launch window. I think working ascent is what I'll do first for SSU 6.0... just hope it doesn't take 1 year like the landing did... :facepalm:

I've tried launching STS-82 to the HST. The first attempt was at the actual launch time, which happened at the beginning of the launch window, so without yaw steering that gave me a very high relative inclination, 4° or so. Then I tried the middle of the launch window which resulted in about 1°. Then I got tired of it, because I always had to adjust the HST state vector in the launch scenario etc. So I simply moved the Shuttle in the right orbit. I'm sure by manually tweaking the launch time I could have gotten better results, at least good enough so that the HST can be reached without cheating. Just as an example.
The way SSU gets to a 28.45º orbit is by heading off to 90º and waiting for vehicle the latitude to drop below the target orbit inclination, then the "normal" orbital inclination logic kicks in... pretty much an open-loop solution, which is not very flexible or good in terms of performance, but it allows the vehicle to get to the correct orbit of a target. :shrug:

And I'll look into the time definition issue, maybe I can figure out how much of a problem it really is. It's also relevant for NASSP of course, but it hasn't caused any noticable problems so far.
I'm sure the difference is just a few seconds, but at 7km/s, the distances accumulate fast. Plus there could be 3 time systems at play here: Orbiter, TLEs and "wrist clock".

#### indy91

If we had an ascent guidance that targeted an actual plane, that would be almost a no-issue, as 44s is pennies in a 10m launch window. I think working ascent is what I'll do first for SSU 6.0... just hope it doesn't take 1 year like the landing did... :facepalm:

Many years ago I played around with the Shuttle ascent targeting, I even got the logic working for using throttling to intercept a target in orbit (for Design Reference Mission 3B). That code is not really in a very usable state, but if you are lacking documentation, I can at least point you to the useful documents.

And once SSU has that stuff implemented I can implement some launch window targeting in the FDO MFD.

#### GLS

##### Well-known member
Orbiter Contributor
Many years ago I played around with the Shuttle ascent targeting, I even got the logic working for using throttling to intercept a target in orbit (for Design Reference Mission 3B). That code is not really in a very usable state, but if you are lacking documentation, I can at least point you to the useful documents.
DRM-3B, a.k.a., total insanity. :lol:
I've some pdfs with some general info on ascent guidance, and the coordinate systems, but I haven't sat down with them to know if they are enough or not. But, even if just the general scheme of things is presented, we can at least start to walk in the right direction.

And once SSU has that stuff implemented I can implement some launch window targeting in the FDO MFD.
Yeah, that way you could estimate a nominal SV for post MECO (that SSU would have to meet), and the flight plan could be calculated on the ground pre-launch.

#### Wolf

##### Donator
Donator
About adjusting for the errors and glitches above: with Non Spherical disabled it is just a matter of changing the launch time. Problem is how do we do that when Non Spherical is enabled. I wonder if there is a way to predict Nodal Regression at a future time (hence the magnitude of my desired RInc at MECO) if my chasing orbit keeps changing from launch to Rendezvous time.

#### indy91

Yeah, that way you could estimate a nominal SV for post MECO (that SSU would have to meet), and the flight plan could be calculated on the ground pre-launch.

Yes. By the way, is the MPS dump after ET sep propulsive in SSU? That would be important to know for that. The rendezvous launch window targeting that was used generated a post-MPS dump state vector to then be used in all the orbital calculations.

About adjusting for the errors and glitches above: with Non Spherical disabled it is just a matter of changing the launch time. Problem is how do we do that when Non Spherical is enabled. I wonder if there is a way to predict Nodal Regression at a future time (hence the magnitude of my desired RInc at MECO) if my chasing orbit keeps changing from launch to Rendezvous time.

It's difficult to do that in any manual way, because that difference in LAN that you want after the ascent is not constant, but will depend on the phase angle as well. Large phase angle needs a low orbit for the Shuttle to catch up and the lower orbit has a stronger effect on the differential nodal regression. Small phase angle will need a higher Shuttle orbit to avoid catching up too quickly and then the difference in nodal regression isn't very large. So far these numbers have (roughly) varied from 0.1° to 0.5° for me.

And inclination is also not constant, but varies over one orbit (with a mean inclination that always stays constant). So, I think, the insertion inclination you would want is the osculating inclination that the target has at the same point in orbit. :facepalm: Luckily that effect is smaller than than the LAN difference, but if you are simply using the mean inclination of the target then that might still cause NPC maneuvers that are 0-20 ft/s larger than they should be.

All of this can only really be solved by some prelaunch targeting that would give you the right launch time and inclination (and later the LAN).

Last edited:

#### GLS

##### Well-known member
Orbiter Contributor
Yes. By the way, is the MPS dump after ET sep propulsive in SSU? That would be important to know for that. The rendezvous launch window targeting that was used generated a post-MPS dump state vector to then be used in all the orbital calculations.
Yes it is. From memory I think it should be +/- 11fps... but then they started using it to pitch the vehicle up to put the ET in the overhead windows, so if that is made the dV is not all in one direction... :shifty:
Plus, some missions had the +X RCS burn, so there's another variable to add.

#### Tim13

##### Member
And once SSU has that stuff implemented I can implement some launch window targeting in the FDO MFD.

That statement almost made me wet myself. :lol: :rofl:

Your MFD has made the SSU go from an A+ to an A+++

It's greatly appreciated!

Tim

#### GLS

##### Well-known member
Orbiter Contributor
That statement almost made me wet myself. :lol: :rofl:

Your MFD has made the SSU go from an A+ to an A+++

It's greatly appreciated!

Tim

Not yet.... but let's hope a rewrite of the ascent guidance/FCS doesn't take as much as the entry did... :facepalm:

Replies
10
Views
626
Replies
1
Views
332
Replies
8
Views
357
Replies
7
Views
584
Replies
3
Views
375