SSU Development Thread (2.0 to 3.0)

[Donamy]

New ODS Airlock.

 

[SiameseCat]

DaveS: Can you still tell me where I can find the proper rotation rates of the transition DAP?

It's 0.5 deg/sec, I think.

---------- Post added at 10:06 PM ---------- Previous post was at 10:06 PM ----------

Well, very likely we will have a reason for a major version increment then anyway. :lol:

So, anybody objecting to call this already the 3.0? (which would also end this Dev thread after a very long time, almost 30 months)

V3.0 sounds good to me.

 

[Urwumpe]

In that case, everything is A-OK here, no MDU switches back to DPS here.

That's strange. Regardless what I do, I can reproduce the bug reliable. Even recompiling and checking that there are no local changes did not change the problem.

 

[GLS]

That's strange. Regardless what I do, I can reproduce the bug reliable. Even recompiling and checking that there are no local changes did not change the problem.

I suggest checking if the CRTMFD is reading (and saving) its state (the prm something variable).

 

[Urwumpe]

I suggest checking if the CRTMFD is reading (and saving) its state (the prm something variable).

That's also what I suspect. But I had been too tired to go looking at the code myself yesterday.

---------- Post added at 02:50 PM ---------- Previous post was at 12:10 PM ----------

Lots of good information and data for scenario design and testing:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110001406.pdf

I am surprised that I did not find it earlier.

 

[Donamy]

That's also what I suspect. But I had been too tired to go looking at the code myself yesterday.

---------- Post added at 02:50 PM ---------- Previous post was at 12:10 PM ----------

Lots of good information and data for scenario design and testing:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110001406.pdf

I am surprised that I did not find it earlier.

Well that killed an hour of my day.

 

[Urwumpe]

Well that killed an hour of my day.

Yeah... especially the section "Performance Enhancements" is pretty interesting to see.

 

[zerofay32]

Well that killed an hour of my day.

Only an Hour?! I started looking at that shortly after sitting down at my desk this morning, the next thing I know it's past lunch time! :blink:

 

[kuddel]

SSU config?

Hi there,

in the latest nightly (r2244) the "check for 90% thrust" was disabled -thanks for that- but
I was thinking I could make this behavior configurable and searched the source. But I coul not find anything like "config" there.

Am I right that there is no generic SSU-Config where something like this could be placed?

...
[RSLS]
CHECK_SSME_90_PERCENT=true ; enable / disable T-2s SSME PC>=90% check (it may cause aborts when frame rate is low)
...

And if there is no general SSU-Config, why is that so?

/Kuddel

 

[Urwumpe]

Hi there,

in the latest nightly (r2244) the "check for 90% thrust" was disabled -thanks for that- but
I was thinking I could make this behavior configurable and searched the source. But I coul not find anything like "config" there.

Am I right that there is no generic SSU-Config where something like this could be placed?

...
[RSLS]
CHECK_SSME_90_PERCENT=true ; enable / disable T-2s SSME PC>=90% check (it may cause aborts when frame rate is low)
...

And if there is no general SSU-Config, why is that so?

/Kuddel

Such stuff goes into the SpaceShuttleUltra.cfg, which is parsed in clbkSetClassCaps.

You are right, we have no central configuration class or structure. Not sure if we really need one now, but I like your idea. :lol:

 

[GLS]

IMO it doesn't make much sense giving users the control of redlines like that. When we have a proper LCC, then it would make sense to allow control over the LCCs. The user would navigate to the GLS or SPE console and could disable this or that. But that is in the future.
About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

 

[DaveS]

IMO it doesn't make much sense giving users the control of redlines like that. When we have a proper LCC, then it would make sense to allow control over the LCCs. The user would navigate to the GLS or SPE console and could disable this or that. But that is in the future.
About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

Disabling red-line limits monitored by the GLS is the sole responsibility of the GLS console operator, callsign CGLS. This is after a GO given by the NTD. CGLS can even inhibit/override the SRO "hold-fire" if required.

The NTD is the absolute top-level of the launch/test team, everyone including Houston FLIGHT, reports to the NTD. The only one higher is the Launch Director, callsign LD. In fact, the LD is so high that not even the chair of the MMT can override the LD. As long as the vehicle is bolted to the MLP, it belongs to KSC. JSC gets to "borrow" it for a weeks but as soon as GSE cooling is initiated post-landing it returns to KSC and the one actually flipping switches and reconfiguring the GPCs is a KSC Spacecraft Operator or SCO who is specially trained KSC Orbiter tech. The callsign of the SCO is CDR.

 

[Urwumpe]

About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

Can be done, still glitching around the MFD bugs.

---------- Post added at 11:12 PM ---------- Previous post was at 11:06 PM ----------

This is how the MFDs look like after saving the above mix of CRT and MEDS displays.

BEGIN_MFD Left
  TYPE User
  MODE CRT
  Mode2 1
  Display 2
END_MFD

BEGIN_MFD Right
  TYPE User
  MODE CRT
  Mode2 2
  Display 5
END_MFD

BEGIN_MFD 5
  TYPE User
  MODE CRT
  Mode2 3
  Display 0
END_MFD

BEGIN_MFD 6
  TYPE User
  MODE CRT
  Mode2 3
  Display 0
END_MFD

BEGIN_MFD 7
  TYPE User
  MODE CRT
  Mode2 3
  Display 0
END_MFD

BEGIN_MFD 8
  TYPE User
  MODE CRT
  Mode2 2
  Display 3
END_MFD

BEGIN_MFD 9
  TYPE User
  MODE CRT
  Mode2 2
  Display 4
END_MFD

That was even before I switched position, so the problem is somewhere internal to the CRT MFD.

---------- Post added at 11:26 PM ---------- Previous post was at 11:12 PM ----------

Interesting.... when I load and save the scenario, it works.

It works even so good, when I quit Orbiter and start "Atlantis in Orbit" again, so all MDUs are offline, turning the MDUs on and switching from Orbit MFD to CRT MFD results in all MDUs having the configuration, which I last saved in another scenario.

Looks like a non-initialized memory glitch.

---------- Post added at 11:35 PM ---------- Previous post was at 11:26 PM ----------

Bug fixed now... question to the other devs, are you using debug mode or release mode for compiling SSU? I only use debug mode when using breakpoints.

 

[DaveS]

I exclusively use Release mode when compiling.

 

[Urwumpe]

Found the bug in the runway drawing code:

rwy_pos_x[i] = hps->CX + static_cast<int>( Round(hps->Scale*DEG*atan(error[i].x/error[i].z)) );
rwy_pos_y[i] = hps->CY + static_cast<int>( Round(hps->Scale*DEG*atan(-error[i].y/error[i].z)) );

Who calls atan, gets atan. Instead of atan2 or a proper projection using only linear algebra instead of trigonometry

3.0 RC1 is on the server now, tomorrow I will look at making a better projection of the runway

 

[GLS]

About 95% debug. Occasionally I go to release to see if anything (bad) happens, as the structure is different. I also play with the compiler settings. So far didn't find anything different between them.

 

[Urwumpe]

About 95% debug. Occasionally I go to release to see if anything (bad) happens, as the structure is different. I also play with the compiler settings. So far didn't find anything different between them.

Its important because debug mode does initialize the memory with a control pattern, release does not.

 

[kuddel]

Such stuff goes into the SpaceShuttleUltra.cfg, which is parsed in clbkSetClassCaps.

You are right, we have no central configuration class or structure. Not sure if we really need one now, but I like your idea. :lol:

SpaceShuttleUltra.cfg! I missed that one :facepalm:
Thanks for the quick response.

 

[Urwumpe]

IMO it doesn't make much sense giving users the control of redlines like that. When we have a proper LCC, then it would make sense to allow control over the LCCs. The user would navigate to the GLS or SPE console and could disable this or that. But that is in the future.
About the present: Urwumpe, don't forget to release another nightly today or tomorrow.

I think that for performance and stability reasons, we should be able to either:

Disable certain checks or
Reduce the sensitivity of the checks


so they are stable even at low FPS. And that independent of any in-game feature like a LCC.

---------- Post added at 12:35 AM ---------- Previous post was at 12:12 AM ----------

Increased the RCS PRI RATE default value to 2.0°/s instead of 0.2°/s, which is the absolute minimum legal entry to ORBIT DAP.

As future improvement, we should create a clone of OrbitDAP and merge it into TransitionDAP, instead of letting OrbitDAP handle Rotations and Translations in OPS 104-106

 

[SiameseCat]

A default RCS PRI RATE of 2.0 deg/s is way too high. Looking at the DAP tables for STS-134 (https://www.nasa.gov/centers/johnson/pdf/539927main_ORB_OPS_134_F_A_1.pdf), the PRI ROT RATE is usually 0.2 deg/s, or less, with the maximum value being 0.5 deg/s.