SSU Development Thread (2.0 to 3.0)

[DaveS]

Can somebody confirm that the MEDS displays revert to DAP, when the VC position is changed?

What do you mean by "DAP"?

 

[Urwumpe]

What do you mean by "DAP"?

Sorry, I mean DPS... when all MFD and CRT screens are active and the CDR screens are set to a MEDS screen, the CDR screens and the MFD screens revert to DPS, when switching VC position.

 

[DaveS]

Sorry, I mean DPS... when all MFD and CRT screens are active and the CDR screens are set to a MEDS screen, the CDR screens and the MFD screens revert to DPS, when switching VC position.

I can't reproduce it here. All MDUs set to some MEDS display or another and they set through all VC position switches.

 

[asdad]

GLS , Can you give me Space Shuttle Ultra Sound Configuration please ?

 

[GLS]

Sorry, I mean DPS... when all MFD and CRT screens are active and the CDR screens are set to a MEDS screen, the CDR screens and the MFD screens revert to DPS, when switching VC position.

I tried to explain what I found about this in ticket #110. Basically we have 11 displays and Orbiter only allows 10 MFDs, so we have to keep some "in the pocket". When changing VC positions, a screen that was nº 3 becomes nº 1, and will thus show what the previous nº 1 screen was showing. Cycle around the VC a few times and it all gets messed up.
It's a PITA but I can live with it, as when we get rid of CRTMFD and move away from using Orbiter's MFDs in the MDUs, that will be a non-issue.

 

[Urwumpe]

I tried to explain what I found about this in ticket #110. Basically we have 11 displays and Orbiter only allows 10 MFDs, so we have to keep some "in the pocket". When changing VC positions, a screen that was nº 3 becomes nº 1, and will thus show what the previous nº 1 screen was showing. Cycle around the VC a few times and it all gets messed up.
It's a PITA but I can live with it, as when we get rid of CRTMFD and move away from using Orbiter's MFDs in the MDUs, that will be a non-issue.

Nooooo... its different, I mean: I sit in the CDR seat, switch to PLT, go back, and all displays that had been active show DPS.

Have experienced it in MM201, maybe thats part of the problem.

 

[GLS]

Nooooo... its different, I mean: I sit in the CDR seat, switch to PLT, go back, and all displays that had been active show DPS.

Have experienced it in MM201, maybe thats part of the problem.

I just played around between CDR and PLT in MM201 (in the ShuttleCentaur branch) and didn't have any issues.

 

[Urwumpe]

I just played around between CDR and PLT in MM201 (in the ShuttleCentaur branch) and didn't have any issues.

Strange. I was able to reproduce it with the Atlantis in Orbit scenario.

EDIT: Full recompile, only CDR1&2, MFD1 and CRT1 and 3... problem reproduced again. CDR1, CDR2 and MFD1 have not been showing PFD and OMS/MPS, CRT1 and 3 showed DPS before switching to PLT, after going to PLT, I have all MFDs showing DPS.

 

[DaveS]

Strange. I was able to reproduce it with the Atlantis in Orbit scenario.

Could you set up a scenario where this bug occurs and post it here?

 

[Urwumpe]

Could you set up a scenario where this bug occurs and post it here?

We already have it, Just use the Atlantis in Orbit scenario from our testing scenarios and set-up the above.

 

[DaveS]

We already have it, Just use the Atlantis in Orbit scenario from our testing scenarios and set-up the above.

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

 

[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