SSU Development Thread (3.0 to 4.0)

[Urwumpe]

I think this is a good idea. It should allow us to test things in a good environment.

Yeah... but I just need to get some idea about the how, we can't put two subversion repositories into one directory, so it has to be copied.

Also, we should define a reference configuration of Orbiter beta for the tests...

 

[DaveS]

Yeah... but I just need to get some idea about the how, we can't put two subversion repositories into one directory, so it has to be copied.

Also, we should define a reference configuration of Orbiter beta for the tests...

The reference configuration I have in my mind is this:

• Latest Orbiter beta
• SSU for Orbiter beta
• Possibly OrbiterSound

This is as minimal as a configuration can get.

 

[GLS]

Shouldn't the GPC/DPS work be finished first, before moving on to re-working the displays?

 

[DaveS]

Shouldn't the GPC/DPS work be finished first, before moving on to re-working the displays?

The high-res MFD textures are natively supported. There's no need to re-work the displays.

 

[Urwumpe]

The high-res MFD textures are natively supported. There's no need to re-work the displays.

We just have to check if the 10 MFD display limit still plays against us. But for that, a beta branch would be the most reliable.

But GLS is right, I should focus on the DPS rework. But the sooner we have feedback on how SSU behaves in the beta, the sooner we can react and rework SSU for it.

 

[GLS]

The high-res MFD textures are natively supported. There's no need to re-work the displays.

I think most displays are done using 256x256 coordinates.

---------- Post added at 10:08 PM ---------- Previous post was at 10:05 PM ----------

We just have to check if the 10 MFD display limit still plays against us. But for that, a beta branch would be the most reliable

I "shoved" SSU in Orbiter2015 and there were changes make in that department, as there were displays showing in all 11 MDUs at once.

 

[Urwumpe]

I think most displays are done using 256x256 coordinates.

I think I will touch some part of this in the DPS rework anyway. I just want to keep the changes to the existing displays as low as possible.

 

[DaveS]

We just have to check if the 10 MFD display limit still plays against us. But for that, a beta branch would be the most reliable.

But GLS is right, I should focus on the DPS rework. But the sooner we have feedback on how SSU behaves in the beta, the sooner we can react and rework SSU for it.

I think we should create a beta branch from the latest trunk revision. This should allow us to run a quick and dirty performance test.

 

[Urwumpe]

I "shoved" SSU in Orbiter2015 and there were changes make in that department, as there were displays showing in all 11 MDUs at once.

Positive or negative changes in our subjective case?

---------- Post added at 11:11 PM ---------- Previous post was at 11:09 PM ----------

I think we should create a beta branch from the latest trunk revision. This should allow us to run a quick and dirty performance test.

Yes, that is how such branches should always be done.

You split them off from the trunk, you update them from trunk from time to time, and in the end you merge them back to trunk. (But you should NEVER mix the merge directions between the two branches, unless you like work)

 

[GLS]

Positive or negative changes in our subjective case?

Don't know. I just noticed that instead of 1 or 2 white MDUs as we currently have, there was a display (of CRTMFD) on all of them. Didn't check if they were static or anything else.

 

[Urwumpe]

Don't know. I just noticed that instead of 1 or 2 white MDUs as we currently have, there was a display (of CRTMFD) on all of them. Didn't check if they were static or anything else.

Could also be artefacts, since we are trying to use only 10 MFDs right now.

 

[Urwumpe]

Does somebody know, when execute packages are transmitted to the Shuttle? Is it at the end of the last flight day or at the start of the next?

 

[GLS]

Does somebody know, when execute packages are transmitted to the Shuttle? Is it at the end of the last flight day or at the start of the next?

I think they were "constructed" overnight, and were sent to the crew in the morning.

 

[Urwumpe]

I think they were "constructed" overnight, and were sent to the crew in the morning.

Yes, the problem is that I don't know exactly, that is why I want to check this.

Also, the INCO document says that a lot of the configuration of the communication system is done by mission control, that is why I am currently researching what is needed to get mission control into SSU.

 

[DaveS]

I think they were "constructed" overnight, and were sent to the crew in the morning.

This is correct. The execute packages were developed by the Orbit 3 shift team which came in for the "overnight" shift to keep an eye on things while the crew slept. Orbit 1 was the lead shift team which was from "morning" to "mid-day". Orbit 2 handled the "mid-day" to "evening" part.

For launch and landing the Ascent/Entry team replaced Orbit 1 as the lead team. The Entry team was lead starting at L-1 day and handled all the entry check-out stuff (FCS check-out, RCS hot-fire and the L-1 comm checks with MILA, NOR and DFRC). In the event of a 24hr wave-off, the Entry team continued to be the lead team.

 

[Urwumpe]

This is correct. The execute packages were developed by the Orbit 3 shift team which came in for the "overnight" shift to keep an eye on things while the crew slept. Orbit 1 was the lead shift team which was from "morning" to "mid-day". Orbit 2 handled the "mid-day" to "evening" part.

Is the crew doing something for receiving the execute packages? Or is this done while the crew starts their day?

And is it correct that only one copy of the execute package is printed?

 

[DaveS]

Is the crew doing something for receiving the execute packages? Or is this done while the crew starts their day?

I don't think so. I think it sent up by e-mail through the Ku band system based on that for complete Ku band system failure on STS-131 all of the standard execute package stuff was read up manually by the CAPCOM and written down by the crew.

 

[Urwumpe]

I don't think so. I think it sent up by e-mail through the Ku band system based on that for complete Ku band system failure on STS-131 all of the standard execute package stuff was read up manually by the CAPCOM and written down by the crew.

Yes, possible. At least in the recent missions, the printer was connected to the PGSC or a Wireless access point. But I doubt we will add the PGSC anytime soon.

 

[DaveS]

Another thing is that MCC can command the onboard printer and they usually did following the wake call if they had Ku AOS. The printer was a regular printer attached to the PGSC network. E-mail synchs were done by MCC, the crew couldn't send/receive e-mails normally.

 

[Urwumpe]

Another thing is that MCC can command the onboard printer and they usually did following the wake call if they had Ku AOS. The printer was a regular printer attached to the PGSC network. E-mail synchs were done by MCC, the crew couldn't send/receive e-mails normally.

Yeah, the Orbit OPS checklist contains information about how the printer is maintained... was a color Ink Jet for the final missions.