SSU Questions thread

[GLS]

Also, having +/- the correct mass would help, as without payload the burn is faster, which makes the vehicle fall earlier into the atmosphere (even with the correct burn dV).

 

[Wolf]

Used ScenarioEditorTLE to load the last STS-131 TLE to Orbiter and surprise surprise: it puts the vehicle 117 to 227Km* ahead of Wolf's scenario.

It's not the full 1000NM difference, but adding the deorbit burn and half a lap around the Earth and it might just be the problem.


*) It depends when on the time the TLE is loaded.

Thanks GLS!
So it should work with your editing using the same official DVs and TIG?
Could you please post the scenario you've edited with the TLE loaded?
I am not very familiar with feeding the scenario with the TLEs..

---------- Post added at 12:23 PM ---------- Previous post was at 12:18 PM ----------

BTW I have tried the deorbit with a higher HP (26NM with a DV -275 fps) as suggested:
SSU catches a good profile, still REI is 4900 NM (still a little too far from nominal)

Raising further the HP (tried 30NM) generates a too shallow reentry angle: SSU not able to cpature the profile and flies over Florida at Mach 21 with an Alt of 210 kft (NO GO!)

 

[GLS]

Thanks GLS!
So it should work with your editing using the same official DVs and TIG?
Could you please post the scenario you've edited with the TLE loaded?
I am not very familiar with feeding the scenario with the TLEs..

For the scenario you posted (starting at 12:00UTC), everything should be the same except this:

  STATUS Orbiting Earth
  RPOS -151118.148 -6464691.404 1848625.199
  RVEL -7554.6160 544.1731 1317.2668
  AROT 16.389 -41.070 14.841
  VROT -0.0800 0.0000 0.0000

Go to O-H and grab ScnEditorTLE, it allows TLEs to be loaded into Orbiter.

---------- Post added at 11:50 AM ---------- Previous post was at 11:37 AM ----------

Also, don't forget to add mass to the vehicle with the PAYLOAD_MASS parameter (or the real payload), so it +/- matches the real thing. Wikipedia has the landing weight at 102,039 kilograms (224,957 lb), so with the OMS prop for the burn you would need to start the scenario with a mass of about 231klbs.

 

[Wolf]

For the scenario you posted (starting at 12:00UTC), everything should be the same except this:

  STATUS Orbiting Earth
  RPOS -151118.148 -6464691.404 1848625.199
  RVEL -7554.6160 544.1731 1317.2668
  AROT 16.389 -41.070 14.841
  VROT -0.0800 0.0000 0.0000

Go to O-H and grab ScnEditorTLE, it allows TLEs to be loaded into Orbiter.

---------- Post added at 11:50 AM ---------- Previous post was at 11:37 AM ----------

Also, don't forget to add mass to the vehicle with the PAYLOAD_MASS parameter (or the real payload), so it +/- matches the real thing. Wikipedia has the landing weight at 102,039 kilograms (224,957 lb), so with the OMS prop for the burn you would need to start the scenario with a mass of about 231klbs.

Thanks a lot for the help
As far as importing the TLE in oObiter I tried with this (seems to be more updated/accurate than ScnEditorTLE) but got problems running it
https://www.orbithangar.com/searchid.php?ID=6850

Have you tried it yourself?

 

[GLS]

Thanks a lot for the help
As far as importing the TLE in oObiter I tried with this (seems to be more updated/accurate than ScnEditorTLE) but got problems running it
https://www.orbithangar.com/searchid.php?ID=6850

Have you tried it yourself?

I just used ScnEditorTLE, which still works in Orbiter 2016.

 

[Wolf]

Not sure if it does correctly, but it does. The implementation just looks different to the reference documents.

Where do I get the data to input in PEG 4? (C1, C2, hp etc.)

 

[GLS]

Where do I get the data to input in PEG 4? (C1, C2, hp etc.)

Yes, those are the ones.

 

[Urwumpe]

Where do I get the data to input in PEG 4? (C1, C2, hp etc.)

Those are essentially standard parameters of a generic orbit, you can find the names of those in the DPS dictionary. Its actually easier to describe an Orbit with those than with the PEG7 inputs, because you can literally punch in your target orbit there, if you know how to translate the parameters.

But yes, I must guess sometimes as well there, I can't remember their definition all the time. :facepalm:

 

[Wolf]

Those are essentially standard parameters of a generic orbit, you can find the names of those in the DPS dictionary. Its actually easier to describe an Orbit with those than with the PEG7 inputs, because you can literally punch in your target orbit there, if you know how to translate the parameters.

But yes, I must guess sometimes as well there, I can't remember their definition all the time. :facepalm:

So what values are supposed to be used for a specific deorbit burn targeting?

 

[Urwumpe]

So what values are supposed to be used for a specific deorbit burn targeting?

Look here for example for STS-135 on page 18:

https://www.nasa.gov/pdf/573049main_fd14_expk.pdf

Seriously: Those execute packages are one nice thing I REALLY want to have in SSU soon....

 

[Wolf]

Look here for example for STS-135 on page 18:

https://www.nasa.gov/pdf/573049main_fd14_expk.pdf

Seriously: Those execute packages are one nice thing I REALLY want to have in SSU soon....

A lot of very useful info. Thanks!

---------- Post added at 01:07 PM ---------- Previous post was at 01:11 AM ----------

Now I am disappointed :thumbsdown:
The only Execute package containing the MNVR PAD with PEG-4 data seems to be the STS-135 one (nothing for previous missions)
Is there any other source you are aware of where we can get the MNVR PADS filled in?

 

[Urwumpe]

A lot of very useful info. Thanks!

---------- Post added at 01:07 PM ---------- Previous post was at 01:11 AM ----------

Now I am disappointed :thumbsdown:
The only Execute package containing the MNVR PAD with PEG-4 data seems to be the STS-135 one (nothing for previous missions)
Is there any other source you are aware of where we can get the MNVR PADS filled in?

Not sure, but I know where I would try to ask...

(Except my external HDD, where I have saved some packages in the past)

 

[Wolf]

Not sure, but I know where I would try to ask...

:rofl:

(Except my external HDD, where I have saved some packages in the past)

:thumbup:

---------- Post added at 02:30 PM ---------- Previous post was at 02:26 PM ----------

It's too bad NASA did not retain them in the published docs. They say Executive Packs were in force since STS-7 so theoretically we could use them for almost all SSU missions.
If only we knew where they are hidden...

Your external HDD could be our saviour here

 

[Urwumpe]

Your external HDD could be our saviour here

Or simply asking NASA about them. I think I just have the packages for 5-6 missions around.

---------- Post added at 14:50 ---------- Previous post was at 14:45 ----------

BTW, google is also your friend:

https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts131/news/execute_packages.html

https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts128/news/execute_packages.html

https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts121/mission_docs/execute_packages.html


https://www.jsc.nasa.gov/news/columbia/107_onboard_archive/web/index.html

---------- Post added at 15:05 ---------- Previous post was at 14:50 ----------

BTW, who ever wanted to know the root password for NASA*, here you can find it:

https://www.jsc.nasa.gov/news/columbia/107_onboard_archive/messages/msg182.pdf

* Of course, just the root password for a unix-like experiment computer on board the space shuttle. But still amusing to find such information in a public PDF. :rofl:

 

[Wolf]

Or simply asking NASA about them. I think I just have the packages for 5-6 missions around.

---------- Post added at 14:50 ---------- Previous post was at 14:45 ----------

BTW, google is also your friend:

https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts131/news/execute_packages.html

https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts128/news/execute_packages.html

https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts121/mission_docs/execute_packages.html


https://www.jsc.nasa.gov/news/columbia/107_onboard_archive/web/index.html

These are the same files I looked into and caused my disappointment: look inside and you won't find the MNVR Pads

---------- Post added at 03:56 PM ---------- Previous post was at 03:54 PM ----------

https://www.jsc.nasa.gov/news/columbia/107_onboard_archive/messages/msg182.pdf

the link doesn't work for me: a blank page shows...

 

[Thorsten]

Those are essentially standard parameters of a generic orbit, you can find the names of those in the DPS dictionary. Its actually easier to describe an Orbit with those than with the PEG7 inputs, because you can literally punch in your target orbit there, if you know how to translate the parameters.

Except the most important non-trivial one to make it all work is the ignition time - and there's no easy way to get it.

Anyway - HT is the height of the entry interface (400.000 ft) - that one is easy. Unless you pose the question whether that's for a geoid earth or a spherical earth...

C1 and C2 describe the descent angle at EI in the most non-intuitive way imaginable - via the implicit relation

v_vert = c2 * v_horiz + c1

Usually these are fairly constant from mission to mission and you might get something like c1= 15,430 and c2 = -0.62 for a de-orbit solution.

theta-T is the angle from TIG to EI how large that ought to be selected depends on how high your orbit initially is.

You can easily eye-ball a de-orbiting solution just based on looking at targeted periapsis (or just by doing rules of thumb with PEG-7) and it's going to be well within cross-range - but the one thing that's always difficult to get is TIG, and messing this up carries you out of cross range pretty quickly.

If you want to guesstimate PEG-4, the problem is that a good theta-T depends on TIG and how high your current orbit is, so to get good non-wasteful parameters, you want to run an optimizer over the possible trajectories - but of course once you run such an offline tool, you might as well use the PEG-7 targets it spits out.

All of this makes a lot more sense if you have weak on-board computing capability and strong on-ground computers - today your smartphone can give you an optimixed PEG-7 target before the Shuttle has done a single guidance cycle...

 

[Wolf]

Except the most important non-trivial one to make it all work is the ignition time - and there's no easy way to get it.

Anyway - HT is the height of the entry interface (400.000 ft) - that one is easy. Unless you pose the question whether that's for a geoid earth or a spherical earth...

C1 and C2 describe the descent angle at EI in the most non-intuitive way imaginable - via the implicit relation

v_vert = c2 * v_horiz + c1

Usually these are fairly constant from mission to mission and you might get something like c1= 15,430 and c2 = -0.62 for a de-orbit solution.

theta-T is the angle from TIG to EI how large that ought to be selected depends on how high your orbit initially is.

You can easily eye-ball a de-orbiting solution just based on looking at targeted periapsis (or just by doing rules of thumb with PEG-7) and it's going to be well within cross-range - but the one thing that's always difficult to get is TIG, and messing this up carries you out of cross range pretty quickly.

If you want to guesstimate PEG-4, the problem is that a good theta-T depends on TIG and how high your current orbit is, so to get good non-wasteful parameters, you want to run an optimizer over the possible trajectories - but of course once you run such an offline tool, you might as well use the PEG-7 targets it spits out.

All of this makes a lot more sense if you have weak on-board computing capability and strong on-ground computers - today your smartphone can give you an optimixed PEG-7 target before the Shuttle has done a single guidance cycle...

Thanks a lot for the explanation Thorsten.
So if I understood well I could use those C1 and C2 values since they are pretty much always the same and I can also input a correct HT value (since EI ALT is always 400 kfeet/65,8 NM) but that will not guarantee a correct deorbit and reentry due to TIG uncertainty...
So that could be done with an "external tool": is there any available that I can use on my PC?

 

[Thorsten]

but that will not guarantee a correct deorbit and reentry due to TIG uncertainty...

That - and you're not guaranteed to get a solution you can burn with your propellant reserves - the PEG-4- to PEG-7 step just determines what it takes to get you to the specified point, but it doesn't tell you whether there's a better solution nearby.

So that could be done with an "external tool": is there any available that I can use on my PC?

I was kind of assuming there'd be one around for Orbiter... I seem to recall having come across an excel sheet for the purpose in this forum (?)

In any case, I'm going to write one in C++ for my own use soonish (need a Linux tool) - once that exists, you're welcome to use it as well.

 

[Wolf]

Very kind of you. Thanks :thumbup:

 

[Thorsten]

Just realizing...

I have a 'rule of thumb' bit of code that gives you a valid TIG (and PEG-7 target) for a de-orbit based on optimizing over parametrized trajectories (in the implementation, you can ask MCC for a de-orbit solution and it'll tell you what to use). This has an accuracy of perhaps 100 miles (well within the cross range), so this leads to something an AP should be able to handle.

I don't know how strong your coding skills are to read source code in an exotic language or how confusing the references to external functions are, but... it's just about 100 lines, and it should be moderately easily adaptable by anyone interested.

https://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tree/Nasal/mcc.nas

(specifically the function mcc_request_process_deorbit )

I guess the interesting bits are the desired periapsis determination and the relatively simple TIG determination (compute REI assuming you'd de-orbit now, get TIG by minimizing that error).