SSU Development Thread (2.0 to 3.0)

[DaveS]

Is this video of any use? Actual launch sim in the Motion Base Simulator:

 

[Urwumpe]

Is this video of any use? Actual launch sim in the Motion Base Simulator:

NASA Space Shuttle Full Motion Simulator Launch & RTLS - YouTube

The main problem right now is just filling the gaps between OI-32 and OI-33. Looks like there is some documentation missing. Or I need a L2 account.

I think the current displays are the right ones, SCOM is newer after all. I just need to look what this means to the use of the DPS Dictionary as reference.

 

[DaveS]

Here's another this time with the late Alan Poindexter in the CDR seat:

 

[GLS]

I had removed the non-SSU displays and powered those off, that would have been showing displays that we don't have yet.

What "non-SSU displays"? In the STS-107 launch scenario (the one I checked so far) you turned off the CDR2 MDU, which had the A/E PFD, and in CDR1 removed the OMS/MPS and moved the A/E PFD to there.

---------- Post added at 07:47 PM ---------- Previous post was at 07:46 PM ----------

The main problem right now is just filling the gaps between OI-32 and OI-33. Looks like there is some documentation missing. Or I need a L2 account.

I think the current displays are the right ones, SCOM is newer after all. I just need to look what this means to the use of the DPS Dictionary as reference.

I means the displays were updated, the documentation wasn't.

 

[Urwumpe]

What "non-SSU displays"? In the STS-107 launch scenario (the one I checked so far) you turned off the CDR2 MDU, which had the A/E PFD, and in CDR1 removed the OMS/MPS and moved the A/E PFD to there.

Strange - actually it should show the following standard launch configuration:

MDU | View Angle | Port Config | Selected Port | Flight Critical Bus | Display | Edgekey Menu
CRT1|positive|man|primary|3|DPS|DPS
CRT2|positive|man|primary|4|DPS|DPS
CRT3|positive|man|primary|4|DPS|DPS
CRT4|negative|man|primary|1|DPS|DPS
CDR1|positive|auto|primary|3|OMS/MPS|FLT INST
CDR2|positive|auto|primary|3|A/E PFD|DATA BUS
MFD1|positive|auto|primary|3|HYD/APU|SUBSYS STATUS
MFD2|positive|auto|primary|4|OMS/MPS|SUBSYS STATUS
PLT1|positive|auto|primary|4|A/E PFD|DATA BUS
PLT2|positive|auto|primary|4|HYD/APU|FLT INST
AFD1|negative|auto|n/a|n/a|n/a|n/a

Will look again what went wrong there, only AFD1 should be powered off by switch config. I had found some many orbit MFDs there, which people can enable if they really like to.

 

[GLS]

Strange - actually it should show the following standard launch configuration:

MDU | View Angle | Port Config | Selected Port | Flight Critical Bus | Display | Edgekey Menu
CRT1|positive|man|primary|3|DPS|DPS
CRT2|positive|man|primary|4|DPS|DPS
CRT3|positive|man|primary|4|DPS|DPS
CRT4|negative|man|primary|1|DPS|DPS
CDR1|positive|auto|primary|3|OMS/MPS|FLT INST
CDR2|positive|auto|primary|3|A/E PFD|DATA BUS
MFD1|positive|auto|primary|3|HYD/APU|SUBSYS STATUS
MFD2|positive|auto|primary|4|OMS/MPS|SUBSYS STATUS
PLT1|positive|auto|primary|4|A/E PFD|DATA BUS
PLT2|positive|auto|primary|4|HYD/APU|FLT INST
AFD1|negative|auto|n/a|n/a|n/a|n/a

Will look again what went wrong there, only AFD1 should be powered off by switch config. I had found some many orbit MFDs there, which people can enable if they really like to.

AFAIK all the launch scenarios had that configuration. Just revert the changes of r2227 and r2224 and it will be fine again. Like I said, I had the Orbit MFD in CRT3, but if you think it's bad, then just delete the "BEGIN_MFD 7" block.

 

[Urwumpe]

AFAIK all the launch scenarios had that configuration. Just revert the changes of r2227 and r2224 and it will be fine again. Like I said, I had the Orbit MFD in CRT3, but if you think it's bad, then just delete the "BEGIN_MFD 7" block.

Reverted and made CRT3 display DPS... its better it will constantly remind us that we have neither GNC OPS 101, nor a way to save the System summary display.

Looks like I had from one point on copied the wrong set of MFD blocks into the scenarios, verified them now again.

 

[GLS]

Reverted and made CRT3 display DPS... its better it will constantly remind us that we have neither GNC OPS 101, nor a way to save the System summary display.

Looks like I had from one point on copied the wrong set of MFD blocks into the scenarios, verified them now again.

Looks fine now. :thumbup:
But, what do you mean with "nor a way to save the System summary display"? Is it related to ticket #101?

 

[Urwumpe]

Looks fine now. :thumbup:
But, what do you mean with "nor a way to save the System summary display"? Is it related to ticket #101?

No, its related to ticket 111.

all MDUs showing DPS displays revert to the current OPS display after saving and loading a scenario, even if you show a SPEC or DISP above the OPS.

I tried fixing the problems with the connected MDUs, but removing the ignore list results in a crash when trying to activate the AFD. Back to square one there.

Because of the large number of displays and low number of display updates (DPS updates only twice per second) , I would say we can maybe soon replace the standard orbiter MFDs by our own painting implementation and leave the Orbiter MFDs to the extMFD world. Would save us this trouble, could get some more performance and we could reduce the amount of code needed to wrap everything around the Orbiter MFDs.

---------- Post added at 10:31 PM ---------- Previous post was at 10:02 PM ----------

Would it be out of scope for the release to do the following refactoring on the DPS?

1. Separate MDU display painting code for the TRAJ displays into a new class, let ascent guidance only do what its name says.
   
2. Use TRAJ 1 also for the prelaunch sequence.
   
3. Maybe unite RSLS and ascent guidance into one guidance class from prelaunch to orbit.

 

[GLS]

No, its related to ticket 111.

all MDUs showing DPS displays revert to the current OPS display after saving and loading a scenario, even if you show a SPEC or DISP above the OPS.

I tried fixing the problems with the connected MDUs, but removing the ignore list results in a crash when trying to activate the AFD. Back to square one there.

Because of the large number of displays and low number of display updates (DPS updates only twice per second) , I would say we can maybe soon replace the standard orbiter MFDs by our own painting implementation and leave the Orbiter MFDs to the extMFD world. Would save us this trouble, could get some more performance and we could reduce the amount of code needed to wrap everything around the Orbiter MFDs.

Yes, 111. :facepalm: All seems fine here. When loading the "Testing scenarios\EDW 22 TAEM", does the SPEC 50 (Horiz Sit) show up on CRT1?

 

[Donamy]

The UARS is just a release payload. Not much to it. But I would be willing to work with another payload (not IUS related) for SSU.

 

[DaveS]

The UARS is just a release payload. Not much to it. But I would be willing to work with another payload (not IUS related) for SSU.

How about STS-99/SRTM (First shuttle launch of the millennium) or STS-95 (the John Glenn flight)?

 

[Urwumpe]

The UARS is just a release payload. Not much to it. But I would be willing to work with another payload (not IUS related) for SSU.

AFAIR, it also communicated with the Shuttle during deployment, just like Chandra.

---------- Post added at 10:40 PM ---------- Previous post was at 10:39 PM ----------

Yes, 111. :facepalm: All seems fine here. When loading the "Testing scenarios\EDW 22 TAEM", does the SPEC 50 (Horiz Sit) show up on CRT1?

There it works. But when you use the SYS SUMM key, it does not save, will test it with the DISP numbers.

EDIT: When you use SPEC 18 PRO to enter GNC SYS SUMM 1, it saves and loads correctly. Only by using the SYS SUMM key, it fails to save.

 

[Donamy]

AFAIR, it also communicated with the Shuttle during deployment, just like Chandra.

I would think most do.

 

[GLS]

Would it be out of scope for the release to do the following refactoring on the DPS?

1. Separate MDU display painting code for the TRAJ displays into a new class, let ascent guidance only do what its name says.
   
2. Use TRAJ 1 also for the prelaunch sequence.
   
3. Maybe unite RSLS and ascent guidance into one guidance class from prelaunch to orbit.

I think we could move the XXXXXX TRAJ displays to the GeneralDisplays class. That way it could show up during MM101. Let me try that, and also changing the math of the predictors, and then I'll report back.
The RSLS has nothing to do with the AscentGuidance (which should be called AscentDAP), so they should stay separated.

---------- Post added at 09:49 PM ---------- Previous post was at 09:47 PM ----------

There it works. But when you use the SYS SUMM key, it does not save, will test it with the DISP numbers.

EDIT: When you use SPEC 18 PRO to enter GNC SYS SUMM 1, it saves and loads correctly. Only by using the SYS SUMM key, it fails to save.

Let me check that then (I think I did that so it could be my fault...)

 

[Urwumpe]

The RSLS has nothing to do with the AscentGuidance (which should be called AscentDAP), so they should stay separated.

Yes, but its also part of the same memory configuration and executed in MM101, once the guidance is internal.

The same applies to the gimbal checks done, the software to react to the commands polled from the LDB is also part of the memory configuration.

 

[GLS]

I would think most do.

Try the "box" that was used by the RMS on STS-3, or the SPAS from STS-7 or the PAFAwhatever used on STS-8.

Let me check that then (I think I did that so it could be my fault...)

Nop, calling things with the keyboard works here.

Yes, but its also part of the same memory configuration and executed in MM101, once the guidance is internal.

The same applies to the gimbal checks done, the software to react to the commands polled from the LDB is also part of the memory configuration.

It might be part of the same memory config, but they are 2 distinct parts. I don't see any gains in merging then, in fact, I think there're a lot of things that should be separated (RHC SOP, FCS).
AFAIK the gimballing is done by the ATVC SOP. Where do the commands for it come from, I'm not sure. Is there a "place" in the memory where it reads from and acts, or each of the possible sources has a distinct "place" in the memory and the SOP listens to who it wants? I don't know.

---------- Post added at 10:37 PM ---------- Previous post was at 10:16 PM ----------

With the limitations on DPS work I need to know if I can fix 2 small bugs I just found in the DPS:
1) class MM801 prevents any DISP/SPEC from running - fixed waiting clearance to commit
2) Key index has FAULTSUMM as "0", which causes the IDP to think the scratch line is complete - I think changing the numbering of the keys will fix it.

 

[Urwumpe]

AFAIK the gimballing is done by the ATVC SOP. Where do the commands for it come from, I'm not sure. Is there a "place" in the memory where it reads from and acts, or each of the possible sources has a distinct "place" in the memory and the SOP listens to who it wants? I don't know.

Yes... I try my best to explain something that is a mystery to myself sometimes:

Each GPC uses shared memory for all processes or tasks, how they are called in the HAL/s language. This is defined in software with a structure called COMPOOL or common pool. Simplified, every layer in the software hierarchy has its own COMPOOL:

There is a FCOS COMPOOL for the variables of all system software (which the application software in the overlays above does not directly interfere with)

There is a GNC COMPOOL shared by all GNC software.
There is a OPS1 COMPOOL for all OPS1 software.

In reality, the common memory is made often of multiple COMPOOLs at fixed memory addresses, because of software development decisions.

The important thing of PASS: Everything in memory above FCOS is practically the same for all GPCs in a redundant set. Because of the synchronization, the software is executed equal in all GPCs and only the data hidden in the FCOS memory is special for every GPC (for example, it contains the number of the GPC)

When you do I/O, you are not directly talking to a subsystem, as you already expect. The software instead tells the IOP of its GPC, to execute a small program and write the results of the IO into memory or read the commands for the subsystem from memory. The PASS software can then either wait for I/O to finish or go on with processing while the IOP is busy. Even more, because of the chosen execution model, tasks can have I/O programs attached that are executed in advance of running the task, so that the task is always started with new data.

All that data that goes around with I/O is in the common memory. When you read the position of the SBTA, you don't directly talk to it. You tell the responsible MDM to execute a small program in its memory and the stream of 16 bit words that arrives is stored in structures in GPC memory.

Because of that structure and because only the FCOS operating system knows which GPC it is, the displays are not drawn by the application software, but by a special system process of FCOS. The application does not even know how its display looks like. All that the application software does, is telling the FCOS operating system, which "format" it uses. The FCOS checks if it has already loaded this format, and if not, it loads the format from tape. All the numbers, symbols, text and stuff are not painted by the application. When the software is compiled, the memory locations for the variables that the software has in its COMPOOL is compiled into the display formats and stored as RAM addresses there. When the display gets updated by the "cyclic display processor" process of FCOS, it reads the format and replaces special commands that reference to GPC memory by the actual drawing commands in the display buffer. And then sends the current display buffer to the DEU that needs the update.

So: Every RM and SOP write to the same memory. SOPs for the navigation systems would write directly to GNC COMPOOLs, the SOPs that talk to SRBs or SSMEs would use the OPS1 COMPOOL. And the data that goes into the COMPOOLs is read by the operating system for drawing the displays according to the format, that describes the displays.

That separation of application, UI and operating system software is what makes it possible to run 4 GPCs in a redundant set as one computer. Everything, that could depend on one special GPC being used to execute the software is done by the FCOS.

Things get much more funny with the ILOADS - the constants for the mission are written into the software tapes and loaded into memory when a new memory overlay is selected. And the software on the tape can be edited even just a few hours from launch away, via LDB commands. And memory inside the GPCs can be loaded with new ILOADS even seconds from launch. Or updated in orbit.

 

[GLS]

About ticket 108, could it be caused by not having the "dynamic = true" argument when calling oapiLoadTexture() on line 80 of Atlantis_Tank? With that on it still works on both graphics clients. Any dev here has this problem, to test stuff? Anyway, I'm committing this and a further check to find to problem.

 

[Urwumpe]

About ticket 108, could it be caused by not having the "dynamic = true" argument when calling oapiLoadTexture() on line 80 of Atlantis_Tank? With that on it still works on both graphics clients. Any dev here has this problem, to test stuff? Anyway, I'm committing this and a further check to find to problem.

"dynamic = true" just decompresses the texture and keeps it in CPU memory for painting. If dynamic = true makes a problem disappear, it could be a problem with the texture compression.