SSU Questions thread

[Wolf]

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).

I really appreciate your help. Unfortunately my coding skills are ZERO.
Maybe this could be useful to the SSU team though..

 

[Wolf]

Here I am again:
Small question about data entered in MM302:
Do the TRIM values (ITEM 6,7,8) actually work in SSU? I tried doing deorbit burns with and without inputting the values and didn't notice any difference.

Now the big one realated to the previous posts about Deorbit and reentry:
I have done some extensive testing using the data available for STS-135.
For this mission there is basically all the info needed to test a reentry.

I used the NASA Mission Execute Package DEORB MNVR PAD data for ORBIT n.200 entry
https://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts135/news/execute_packages.html

Also this real time reentry video
[ame="https://www.youtube.com/watch?v=sB4_A-NQt2Q"]Last Space Shattle STS135 deorbit, reentry to touchdown tracking - YouTube[/ame]
and data from NASA "Flight Procedures Handbook - Entry" give useful info on the Shuttle reentry profile.

I tried using either PEG-4 and PEG-7

PEG-4:
TIG 12/17:20:00 (08:49:03 UTC)
DV -334.75 FPS
ORBIT 215X34 NM (HAXHP) - (note STS-135 ORBIT was 210x25 NM)
The resultant REI was 4200 NM from KSC (actual STS-135 one was 4430 NM) so it is like an underburn case and a prebank was required to catch the entry path (done manually as SSU AFCS is unable to handle the high energy state and reentry fails). Once back on profile ROLL AFCS was re engaged and the reentry went well.

PEG-7:
Played with different DV's but SSU always reaches EI at the "wrong" distance from KSC, mostly too far (between 5200 and 5000 NM from KSC). To get a correct REI I had to delay the deorbit burn by 04 minutes and 30 seconds from actual TIG (around 800 NM beyond the actual point) but that is not where and when the burn should be done.

Since I could not find PEG-4 data for any other STS mission (except STS-1) I guess I need to use PEG-7: The problem is I cannot find a way to feed SSU with the DV values that will generate a correct reentry profile if compared to the real one.

Any suggestion based on your SSU reentry experience?

 

[Thorsten]

I tried doing deorbit burns with and without inputting the values and didn't notice any difference.

They wouldn't do anything for de-orbit burns in reality either.

As far as I can understand, the gimbals aren't terribly fast in reality. So from neutral you need some time (2-3 seconds) to move them into a position from which thrust is pointed through the CoG.

For a 5 second burn, that means you're off for half the burn - so you want to move them close to the 'through CoG' position from the beginning. For a de-orbit burn, that's really not an issue, because the engines will be vectored correctly for most of the burn duration.

The OMS TVS is actually a rate-controlling DAP, so aside from the transient effects, it trims itself.

 

[Wolf]

2 Q about MM302 CRT data:

1) How does SSU "senses" its weight? what happens if I change it with ITEM 9, will SSU be tricked and "think" the actual weight is the one manually inputted?

2) If I am not mistaking after the target data are inputted a REI value should pop up in the CRT screen. Any reason why nothing shows in SSU?

3) I noticed that after feeding the screen with the data and entering ITEM22 EXEC the post burn TGT Orbit HA/HP values show up but then after a few seconds the numbers go back to the actual orbit (same as CUR HA/HP). I think this only happens when using PREG-4..

Thanks

 

[Urwumpe]

1) How does SSU "senses" its weight? what happens if I change it with ITEM 9, will SSU be tricked and "think" the actual weight is the one manually inputted?

Only for the guidance of course, but yes.

2) If I am not mistaking after the target data are inputted a REI value should pop up in the CRT screen. Any reason why nothing shows in SSU?

Possibly because we did not include this special case yet.

3) I noticed that after feeding the screen with the data and entering ITEM22 EXEC the post burn TGT Orbit HA/HP values show up but then after a few seconds the numbers go back to the actual orbit (same as CUR HA/HP). I think this only happens when using PREG-4..

Sounds like a bug to me.

 

[GLS]

I also noticed the orbit numbers, both current and target change by thenselves from time to time... time acceleration might have something to do with it.

 

[Gingin]

Hello Guys,

I am just getting back into SSU.
I pulled the last revision and regenerated the solution.

Everything worked well except for a missing tiles aft of the payload bay, we can see through the floor :
It might come from I have 15 build succeeded instead of 16 like Dave explained in the tuto

Also I dont remember, is it normal to see the sun shining through the Shuttle?

Thanks for the help

 

[GLS]

The sun in a panel... err, no, it isn't normal. :uhh: Never seen that before.

The libUltra test project might not compile, but don't worry about that one.

Yes, there is a hole in the OV, it's being worked on.

About the STS-88 image you posted, you have to change the mission file so the TAA is placed forward of the external airlock ("AftTAA = false", if I remember well).

---------- Post added at 04:15 PM ---------- Previous post was at 04:13 PM ----------

And also the starboard MPMs shouldn't be there.

 

[Gingin]

Ah, might be some weird Video settings for the sun ?
Alright for the hole, no worries then

I noticed that with Challenger, there is no hole.

Aah right , the TAA. To have the ODS further from the cockpit?
Alright for the MPM thanks.


I had something weird with Unity also.
I captured it, then released it. RMS wasn't moving anymore, still showing captured and Unity just vanished into space like if it wasn't captured.

 

[GLS]

Ah, might be some weird Video settings for the sun ?

If you could provide more info on your settings, it would help.

Aah right , the TAA. To have the ODS further from the cockpit?

Yes, because the RMS couldn't dock Unity to the ODS. Same story for STS-74 and the Mir docking module.

I had something weird with Unity also.
I captured it, then released it. RMS wasn't moving anymore, still showing captured and Unity just vanished into space like if it wasn't captured.

If you grapple something in the PLB, you must then release the retention latches before you take it out.

 

[DaveS]

Ah, might be some weird Video settings for the sun

In the Advanced Setup window for D3D9Client make sure that Post Processing is set to None. The PP shaders are experimental and I pretty sure that none of them are being worked on anymore (they're several years old and date back to way earlier revisions).

 

[Gingin]

Yep, I was on LensFlare, it seems to work with no PP.
Thanks

---------- Post added 12-15-18 at 12:18 PM ---------- Previous post was 12-14-18 at 09:53 PM ----------

Quick question,

What do you recommend for realism option: Complex Flight Model, Damage Failure Simulation, Non Spherical Gravity sources, Radiation Pressure, Gravity-Gradient Torque ?

 

[Urwumpe]

I think wind was the only thing you need to disable... mostly because its a bit strong right now.

 

[GLS]

I think wind was the only thing you need to disable... mostly because its a bit strong right now.

In the trunk, yes.
In the OrbitersimBeta branch, the FCS handles the wind well, although there is still tons of checking to do in the aero.

 

[Gingin]

Alright , thanks
I removed some of them to have more stable Oorbir for Rendez vous on multiple day, hard enough ahah

Ah, there is a SSU branch for Orbiter Beta?


SOmetimes, when I load a quick save or even during a game, I can't click on some switches anymore ( like RMS panel), any work around for that or idea?

thanks guys

 

[GLS]

Ah, there is a SSU branch for Orbiter Beta?

It's not for Orbiter BETA now, but that was its initial purpose back when Orbiter 2016 hadn't be released. This year I just started using it for changes needed for Orbiter 2016, i.e., updating the AerojetDAP to deal with runways at different altitudes.

SOmetimes, when I load a quick save or even during a game, I can't click on some switches anymore ( like RMS panel), any work around for that or idea?

The panel click issue: after much debugging and testing I can't find anything wrong on our end, so I reported it as an Orbiter bug, so that's kinda out of our hands until we hear on this from Martin. :shrug:

 

[Gingin]

Alright, thanks for the info GLS

 

[Snax]

Never seen this post before
Better so I wouldn't need to crrate a new thread just for a quick question ^^

Wich is: do the SSU team have olans to make a cockpit prior the glass-cockpit era for the Shuttle ?
I'd love to fly with the good old analog and tapes hehe

 

[GLS]

Never seen this post before
Better so I wouldn't need to crrate a new thread just for a quick question ^^

Wich is: do the SSU team have olans to make a cockpit prior the glass-cockpit era for the Shuttle ?
I'd love to fly with the good old analog and tapes hehe

Yes, that is in the plans.... but at the current pace of development it will be some years before we get there... :facepalm:

 

[Snax]

Yes, that is in the plans.... but at the current pace of development it will be some years before we get there... :facepalm:

I understand, I've been playing games like Falcon, Flight Simulator and such to realize that development does take time to achieve the best things !