SSU Questions thread

[Wolf]

It is integrated into the SSU Workbench, which is in the OrbiterSDK folder (needs compilation).

I could not compile it (VS gives me a .Net framework issue message)
Would it be possible for tou guys to update the mission files in order to get the correct MECO speed and FPA to match the nominal mission values?
For example STS-114 resulted in a MECO orbit of 119x31,3 NM.

On top of that, the orbit ApA increases of a couple of NM after MECO due to MPS fuel dump accelerating the Orbiter. Is that what happened in real life?

 

[GLS]

I could not compile it (VS gives me a .Net framework issue message)
Would it be possible for tou guys to update the mission files in order to get the correct MECO speed and FPA to match the nominal mission values?
For example STS-114 resulted in a MECO orbit of 119x31,3 NM.

We have a mission file for STS-114 and it should be correct.

On top of that, the orbit ApA increases of a couple of NM after MECO due to MPS fuel dump accelerating the Orbiter. Is that what happened in real life?

Yes it did. Same goes for the +X ET photo maneuver. In an ideal world we would factor those dVs when calculating the MECO targets (NASA probably did).



For now, I don't think it is worth investing in super-duper detailed MECO targets, as we have a very rudimentary lateral control during ascent (no LAN control), and vertical control is not that good in the final seconds prior to MECO (low FPA accuracy).
Plus, targeting what happened in a mission isn't necessarily the best course of action, because what happened is not exactly what was planned. So maybe targeting what was planned is better overall.

 

[Donamy]

Also, the roll program has too much pitch.

 

[GLS]

Also, the roll program has too much pitch.

Currently that is more like brute force instead of the mathematical elegancy of a 3-axis rotation... :uhh:
It all needs a major rework. :shrug:

 

[Wolf]

We have a mission file for STS-114 and it should be correct.

Well the current mission file generates a MECO orbit of 122x38 NM against the actual 119x31 NM.

---------- Post added at 12:17 AM ---------- Previous post was at 12:16 AM ----------

For now, I don't think it is worth investing in super-duper detailed MECO targets, as we have a very rudimentary lateral control during ascent (no LAN control), and vertical control is not that good in the final seconds prior to MECO (low FPA accuracy).
Plus, targeting what happened in a mission isn't necessarily the best course of action, because what happened is not exactly what was planned. So maybe targeting what was planned is better overall.

Still wouldn't it be nice to have Mission Files that reflect at least the planned outcomes?

 

[GLS]

Still wouldn't it be nice to have Mission Files that reflect at least the planned outcomes?

Yes it would, but the current logic doesn't provide much accuracy. Plus, it is frame rate dependant, so the same MECO targets on my pc will give a different orbit than you'll get on your pc. :shrug:

 

[Wolf]

Yes it would, but the current logic doesn't provide much accuracy. Plus, it is frame rate dependant, so the same MECO targets on my pc will give a different orbit than you'll get on your pc. :shrug:

Can the MECO orbit significantly change depending on the FPS, I mean in the order of some NM?
And do you know if the FPS issue also affect all other burns when using SSU (on orbit and deorbit)?

That could help me understand some discrepancies I ran into in the past with the STS-114 NC burns (the mission timeline included in the Flight Plan doc gives you all the details for those burns but I never had an actual post-burn orbit matching with the target one... a bit frustrating)

 

[GLS]

Can the MECO orbit significantly change depending on the FPS, I mean in the order of some NM?
And do you know if the FPS issue also affect all other burns when using SSU (on orbit and deorbit)?

That could help me understand some discrepancies I ran into in the past with the STS-114 NC burns (the mission timeline included in the Flight Plan doc gives you all the details for those burns but I never had an actual post-burn orbit matching with the target one... a bit frustrating)

The lower the FPS the lower the precision of whatever burns you make, because each timestep will last longer, thus it will mean more dV. Burns with higher acceleration will also have lower precision, because each timestep in be adding a higher dV. So, e.g., if a burn is adding 1m/s in each timestep, you might get a deviation between 0 and +1m/s from the target.
This shouldn't be a big issue for OMS burns, due to their low acceleration, but MECO much is more sensitive being at just under 3g.

 

[Thorsten]

The lower the FPS the lower the precision of whatever burns you make, because each timestep will last longer, thus it will mean more dV.

Quite so.

The standard response to the issue in simulator environments seems to be to remove flight dynamics from the main loop and run it at fixed timing (JSBSim runs at 120 Hz regardless of what the graphical framerate happens to be) - this generally works because usually rendering is the largest chunk.

 

[Wolf]

Quite so.

The standard response to the issue in simulator environments seems to be to remove flight dynamics from the main loop and run it at fixed timing (JSBSim runs at 120 Hz regardless of what the graphical framerate happens to be) - this generally works because usually rendering is the largest chunk.

Is that doable in our case?

 

[Thorsten]

I honestly don't know what Orbiter internally does and whether it would allow any SSU code to run threaded or not.

What is doable if you have the current frame spacing is estimating the discretization error in the code running at that framerate and using higher terms of e.g. a Taylor series to correct.

I.e. in a simple example assume you know you compute every seconds, but you code receives a 'cut thrust' command at 510.25 seconds - knowing that, you could make the last velocity increment just 1/4 of what it was before.

Whereas if you were to compute at 0.5 seconds, you'd know you'd cut it in half, if you compute at 0.25 seconds you have no discretization error here.

And so on. It requires a bit of experience in numerical math to do that, but it is doable - I have make a co-orbiting object running at 3 fps accurately synchronized with an object at 120 fps by countering the discretization errors with a drift or < a few cm per minute.

 

[GLS]

Orbiter has the graphics "step-locked" with the physics, so it is what it is. :shurg:
Returning to the original MECO targets discussion: IMO the largest error (FPA) is fixable on SSU... we just need to correct the ascent guidance/FCS part.

 

[Wolf]

Orbiter has the graphics "step-locked" with the physics, so it is what it is. :shurg:
Returning to the original MECO targets discussion: IMO the largest error (FPA) is fixable on SSU... we just need to correct the ascent guidance/FCS part.

Good news. In the meantime, after some trial and error I have found the MECO values for the STS-114 Mission file (speed and FPA) that give me almost the correct orbit (118x31 NM) at least on my computer

 

[amalahama]

Hi!

Is it possible to export CRTs to another monitor?

Is it possible to use physical keyboard to input data into the IDP, instead of the clickable keyboard in the VC?

Thanks!

 

[GLS]

Hi!

Is it possible to export CRTs to another monitor?

Is it possible to use physical keyboard to input data into the IDP, instead of the clickable keyboard in the VC?

Thanks!

You could probably get the CRTs, or any other MFD, to be displayed anywhere, if you could access the texture where the drawing is taking place. The graphics people should know if this is possible.

As for the keyboard, I don't think so, as it only responds to mouse clicks. I'm sure it could be done, but there would have to be changes in SSU, and right now I don't have the time. :facepalm: Unless you want to do it... :shrug:

 

[GLS]

This is what I get on the PFD after recompiling from the branch

View attachment 16305

Any idea on what happened?

This has now been fixed.

 

[Wolf]

This has now been fixed.

So we can go back to the latest D3D9 release?

---------- Post added at 06:54 PM ---------- Previous post was at 06:15 PM ----------

Houston we have a problem: I recompiled with the trunk this time and run the EDW 22 Final Approach and TAEM sceanarios with the FCS in AUTO to verify the autoland performance.
NO preflare at all. SSU flies straight into the ground :facepalm:
Could it be something went wrong while recompiling?...
--------------------------------------------------------------------

Also the "STS-1 T-45s_SRB FIX" in the testing scenario folder causes CTD. The LC39A:SSU_Pad1985 should be replaced by LC39A:SSU_LC39_1985 I guess

 

[DaveS]

So we can go back to the latest D3D9 release?

---------- Post added at 06:54 PM ---------- Previous post was at 06:15 PM ----------

Houston we have a problem: I recompiled with the trunk this time and run the EDW 22 Final Approach and TAEM sceanarios with the FCS in AUTO to verify the autoland performance.
NO preflare at all. SSU flies straight into the ground :facepalm:
Could it be something went wrong while recompiling?...

No. the trunk doesn't have any autoland capabilities implemented. Remember, the new landing stuff is in the OrbitersimBeta branch and it hasn't been merged with the trunk yet.

 

[Wolf]

No. the trunk doesn't have any autoland capabilities implemented. Remember, the new landing stuff is in the OrbitersimBeta branch and it hasn't been merged with the trunk yet.

I thought I GLS wrote he merged all the new stuff into the trunk... this is what happens when you come back from work after waking up at 4:00 am :zzz:

 

[DaveS]

I thought I GLS wrote he merged all the new stuff into the trunk... this is what happens when you come back from work after waking up at 4:00 am :zzz:

Nope. What he did was to update the branch with the latest changes to the trunk. So trunk-to-branch, not branch-to-trunk.