SSU Questions thread

[GLS]

As said above, if the burn is good nd it’s done at the correct point, what could csuse the trajectory data to be wrong? The L2 website data MUST be correct since they were taken realtime from NASA source during reentry, so I wonder why the discrepancy at EI is so huge..

The MCC feeding live data to a website? Could be, but I don't think so. :lol:
IMO, taking the last available TLE from NORAD and applying the deorbit burn to it should yield better results.

 

[Urwumpe]

In other words you mean that if we target and do a burn that results in the desired HP value we cannot rely on that?
So to get a proper reentry path will need a lot of trial and error?
Sorry I missed that you ment Orbiter values: yes I crosschecked with orbit MFD and the values match (HP is around 25 Km)

Yes, you should not exclude it. But if the values match, its not the problem.

 

[GLS]

I mean in Orbiter. I would not trust our displays further than I can throw an equivalent hardware.... and a GPC is a heavy thing.

Generally, the numbers are right in SSU, but if you really depend on them, they will be wrong. I call this my dualism law of SSU.

Playing with DG shows the ~90m/s (297fps) burn producing a ~26Km (14NM) perigee, so it isn't that bad.
If I had money, I'd bet on the data being wrong.

 

[DaveS]

The MCC feeding live data to a website? Could be, but I don't think so. :lol:
IMO, taking the last available TLE from NORAD and applying the deorbit burn to it should yield better results.

Actually, speaking as member of the L2 section of NASASpaceflight.com, I can say that the data was indeed live and fed into a special kml file that is used by Google Earth. So the data was generated by the FDO console in the White FCR and then routed through the JSC internal network which was captured by this special kml file. And anyone with this special kml file could watch the trajectory being generated in real time.

 

[Wolf]

The MCC feeding live data to a website? Could be, but I don't think so. :lol:
IMO, taking the last available TLE from NORAD and applying the deorbit burn to it should yield better results.

Thanks for the suggestion; where do I find those vslues.

Don’t mean to bother you guys but could anyone whenever you have time check the STS-131 scenario and see what happens during your re entry? This way I can confirm it was either something wrong with the scenario itself or me screwing up something with the reentry.
I would really appreciate that

Thanks guys

 

[Urwumpe]

Playing with DG shows the ~90m/s (297fps) burn producing a ~26Km (14NM) perigee, so it isn't that bad.
If I had money, I'd bet on the data being wrong.

I have no idea what could be wrong - the initial conditions seem to fit, the deorbit burn is correct, the only difference could be the timing.

 

[GLS]

Thanks for the suggestion; where do I find those vslues.

Don’t mean to bother you guys but could anyone whenever you have time check the STS-131 scenario and see what happens during your re entry? This way I can confirm it was either something wrong with the scenario itself or me screwing up something with the reentry.
I would really appreciate that

Thanks guys

https://celestrak.com/ Historical Archives >> US Space Shuttle

---------- Post added at 10:45 PM ---------- Previous post was at 10:43 PM ----------

I have no idea what could be wrong - the initial conditions seem to fit, the deorbit burn is correct, the only difference could be the timing.

If it is timing, then a 1000NM error equals about 4 minutes...

 

[DaveS]

https://celestrak.com/ Historical Archives >> US Space Shuttle

---------- Post added at 10:45 PM ---------- Previous post was at 10:43 PM ----------



If it is timing, then a 1000NM error equals about 4 minutes...

Timing is about right when comparing to the historical calculated de-orbit TIG: https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts131/news/dol_pad.html

I'm thinking, that the de-orbit burn targets are wrong. Too steep. That would lead to an earlier EI point. Need to shallow it out a bit.

 

[Wolf]

I'm thinking, that the de-orbit burn targets are wrong. Too steep. That would lead to an earlier EI point. Need to shallow it out a bit.

That's also what I thought. So would it be possible to fix it if you think it is a bug with SSU? In the meantime could the solution be to reduce the burn DV a (resulting in a higher Periapsis) in order to get a shallower reentry angle?

 

[Urwumpe]

How did you program the burn? PEG7 or PEG4?

 

[GLS]

Timing is about right when comparing to the historical calculated de-orbit TIG: https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts131/news/dol_pad.html

I'm thinking, that the de-orbit burn targets are wrong. Too steep. That would lead to an earlier EI point. Need to shallow it out a bit.

If the burn is correct, and as Newton didn't made any errors when he invented gravity :lol:, then the orbit data is wrong somehow, putting the vehicle in the wrong place at the wrong time. :shrug:

---------- Post added at 11:36 PM ---------- Previous post was at 11:34 PM ----------

How did you program the burn? PEG7 or PEG4?

Looking at the screenshots: PEG7.

 

[Wolf]

Timing is about right when comparing to the historical calculated de-orbit TIG: https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts131/news/dol_pad.html

Something must be wrong with the deorbit burn time infos aswel:

L2: 12:00:41 UTC
SSMS: 12:02:59 UTC

the above link actaully matches with SSMS

 

[DaveS]

That's also what I thought. So would it be possible to fix it if you think it is a bug with SSU? In the meantime could the solution be to reduce the burn DV a (resulting in a higher Periapsis) in order to get a shallower reentry angle?

It isn't a bug in SSU. It is your de-orbit burn targets that are wrong. The 14 NM perigee is just low. Remember, you don't have to go very deep in the atmosphere for it to capture the orbiter. 30 NM or so is sufficient.

 

[Wolf]

It isn't a bug in SSU. It is your de-orbit burn targets that are wrong. The 14 NM perigee is just low. Remember, you don't have to go very deep in the atmosphere for it to capture the orbiter. 30 NM or so is sufficient.

So the data from SSMS are not reliable? they give a post burn orbit of
190.6x14.2 nm (HAxHP) exactly

---------- Post added at 12:59 AM ---------- Previous post was at 12:45 AM ----------

How did you program the burn? PEG7 or PEG4?

I do confirm PEG7

 

[GLS]

Something must be wrong with the deorbit burn time infos aswel:

L2: 12:00:41 UTC
SSMS: 12:02:59 UTC

the above link actaully matches with SSMS

Earlier deorbit burn would make range at EI even greater.

It isn't a bug in SSU. It is your de-orbit burn targets that are wrong. The 14 NM perigee is just low. Remember, you don't have to go very deep in the atmosphere for it to capture the orbiter. 30 NM or so is sufficient.

A ~14NM perigee matches the ~300fps burn, so it must be correct.

 

[Urwumpe]

Must not be correct. AFAIR historic deorbit burns are PEG4, not PEG7. Even if the magnitude of the burn is equal, the direction must not and could have small effects.

 

[DaveS]

Must not be correct. AFAIR historic deorbit burns are PEG4, not PEG7. Even if the magnitude of the burn is equal, the direction must not and could have small effects.

Does PEG-4 even work in SSU currently? I tried it in the past but none of the MNVR EXEC displays would accept any PEG-4 ITEM inputs.

 

[Wolf]

Does PEG-4 even work in SSU currently? I tried it in the past but none of the MNVR EXEC displays would accept any PEG-4 ITEM inputs.

If you can confirm PEG-4 works ok then I'll try with that

---------- Post added at 11:17 AM ---------- Previous post was at 10:42 AM ----------

A ~14NM perigee matches the ~300fps burn, so it must be correct.

So I feel like I am running around in circles now

To summarize:

1) BURN: it seems to be good: DV around 300 fps gives me a matching 14NM Perigee.
This is also pretty much the same DV required for a tipical ISS mission deorbit burn, so if SSU is accurate it cannot be that different from 300 fps and if I need, let's say a lower DV with a higher Perigee to adjust the reentry angle (as Dave suggested) then it means maybe something is not right with SSU behaviour, given that Orbiter physics are accurate.

2) TIG: The deorbit burn point is also confirmed to be ok, as per L2 forum data. SSU orbit is almost identical to the real one and the burn happens at the actual TIG it was done.

3) R.E.I. : the SSU Range is 1000NM higher than it should be. IF the above data are correct there is still margin for some errors but how can it lead to such a wrong reentry profile? Now, looking at the problem from the opposite side I know how to make a perfect SSU reentry hitting EI at 4200NM followed by an automatic flawless glide down to the RWY, but to do that the deorbit burn must be done a LOT closer to the landing site (TIG done much later than the real one). By doing this I am happy with SSU performance in Orbiter but I am far away from a realistic reentry..

So the question is: have you done any succesful deorbit using the same parameters and targets they guys at NASA did? If so, how can I do that?

Thanks for your support

 

[Urwumpe]

Does PEG-4 even work in SSU currently? I tried it in the past but none of the MNVR EXEC displays would accept any PEG-4 ITEM inputs.

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

 

[GLS]

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.