SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

I have checked in a new orbiter mesh that has a few changes. Mainly it is the additions of the PLB liner flight kit that was used on all IUS missions as well as the HST missions and the four PLB radiator panel retract hoses. These hoses are connected to the radiator panel inlet manifolds. There's two retract hoses per side, one for the two forward panels and one for the aft panels.

The hoses are what supply the panels with the actual Freon-21. The hoses are on a take-up reel beneath the PLB sill longerons and are automatically pulled off the reels as the PLBDs are opened and wound up when the PLBDs are closed. So these needs to be animated.

There is an issue with the mislabled (?) Atlantis_5thmod2.dds texture (note the extra 2) in the OV mesh.

 

[GLS]

Good news, bad news... :uhh:

Good: autoland lateral guidance works very well IMO, even with wind. Still have to figure out the yaw (in AerojetDAP) so it responds to the wind with the rudder, but so far so good.

Bad: the autoland vertical guidance works by tracking some reference parameters, that are calculated with a set of equations that are very very washed out in the document I have... :facepalm: :facepalm:

I can barely tell what parameters are used, but then it's pretty much impossible to tell if there's a + or - or whatever between them. I'll have to try reverse engineering something. :shrug:

 

[GLS]

The SLC-6 issue reminded me that we still have "a foot" in SF, and a solution for the tickets and for the files (both releases and the pdfs) has yet to be found... :shrug:

 

[DaveS]

The SLC-6 issue reminded me that we still have "a foot" in SF, and a solution for the tickets and for the files (both releases and the pdfs) has yet to be found... :shrug:

Why wouldn't my suggestion of using an O-F vBulletin project for the tickets work? Works nicely for OHM/O-F and Orbiter itself. The files are different though. Not sure about that one.

 

[Urwumpe]

Why wouldn't my suggestion of using an O-F vBulletin project for the tickets work? Works nicely for OHM/O-F and Orbiter itself. The files are different though. Not sure about that one.

What the NASSP team is doing right now also looks fascinating.

 

[GLS]

So I think I finally scratched an itch I had for some time: where are the MEDS ADCs getting their data from?
It looks like some (and this is only me adding 1 and 1 together, I haven't seen "hard data" on this) of the data displayed in the subsystem displays takes the scenic route to get there. Some data comes directly from the hardware (e.g. MPS He pressures), but for things like SSME PC or aerosurface positions that doesn't work. In the MCDS, that data was sent from the GPCs to MDMs that then generated analog signals that drove the mechanical displays. It seems that in MEDS the ADCs pick up those analog signals from the MDMs, convert them to digital and send it to the IDPs. So, some data goes from the GPCs, to MDMs, to ADCs, to IDPs, which are already connected to the GPCs via, not 1 but, 2 busses! :lol: Even the Galileo spacecraft had an easier path to Jupiter than this... :rofl:
But it makes sense as the MEDS was supposed to be transparent to the GPCs, and this way the display data being output by the GPCs is the same. :shrug:

BTW, the data for the PFDs was originally sent to the DDUs, and is now sent to the IDPs, so that has a more direct route.

---------- Post added at 12:23 PM ---------- Previous post was at 12:21 PM ----------

Why wouldn't my suggestion of using an O-F vBulletin project for the tickets work? Works nicely for OHM/O-F and Orbiter itself. The files are different though. Not sure about that one.

I wouldn't mind having the tickets here. Could they be "inside" our sub-forum?
Also, what about access: do only devs have write access as before, or should they be open to anyone?

 

[Urwumpe]

So I think I finally scratched an itch I had for some time: where are the MEDS ADCs getting their data from?
It looks like some (and this is only me adding 1 and 1 together, I haven't seen "hard data" on this) of the data displayed in the subsystem displays takes the scenic route to get there. Some data comes directly from the hardware (e.g. MPS He pressures), but for things like SSME PC or aerosurface positions that doesn't work. In the MCDS, that data was sent from the GPCs to MDMs that then generated analog signals that drove the mechanical displays. It seems that in MEDS the ADCs pick up those analog signals from the MDMs, convert them to digital and send it to the IDPs. So, some data goes from the GPCs, to MDMs, to ADCs, to IDPs, which are already connected to the GPCs via, not 1 but, 2 busses! :lol: Even the Galileo spacecraft had an easier path to Jupiter than this... :rofl:
But it makes sense as the MEDS was supposed to be transparent to the GPCs, and this way the display data being output by the GPCs is the same. :shrug:?

I think you are still wrong there - there are MANY quantities, that were directly connected to their indicators and/or the OI MDMs.

For example the APU information does not come from the GNC GPCs in the old CRT cockpit.

For the MEDS, those quantities that lost their indicator in the cockpit, the ADC is there, so the display processor can read the digital values for displaying them in the new display pages.

 

[GLS]

I think you are still wrong there - there are MANY quantities, that were directly connected to their indicators and/or the OI MDMs.

For example the APU information does not come from the GNC GPCs in the old CRT cockpit.

For the MEDS, those quantities that lost their indicator in the cockpit, the ADC is there, so the display processor can read the digital values for displaying them in the new display pages.

Yes some data (I can make a list if you want) was displayed directly from the sensors in MCDS, and in MEDS it goes to the ADCs. But, like I wrote, that only works for some things.

 

[Urwumpe]

Yes some data (I can make a list if you want) was displayed directly from the sensors in MCDS, and in MEDS it goes to the ADCs. But, like I wrote, that only works for some things.

Yes. And for the others, it goes via GPC to the IDP.

Each IDP replaces DEU AND Dedicated Display Electronics - only the HUD remains.

 

[GLS]

Yes. And for the others, it goes via GPC to the IDP.

Yes, the data in the PFDs goes from the GPCs to the IDPs via FC bus, at least the everything in the SPI, plus the SSME PC take the GPC/MDM/ADC/IDP route, and the rest comes directly from the subsystem sensors via ADC.

 

[Urwumpe]

SSME PC take the GPC/MDM/ADC/IDP route

I think you are wrong there. I think in the old cockpit, the data path was:

SSME Pc Transducer -> Pc Indicator or:
SSME Pc Transducer -> MEC -> EIU

Thus it should be:

SSME Pc Transducer -> ADC -> MDU

I can do some research later at home, if you like.
Maybe a signal conditioner was between Pc sensor and indicator.

 

[GLS]

I think you are wrong there. I think in the old cockpit, the data path was:

SSME Pc Transducer -> Pc Indicator or:
SSME Pc Transducer -> MEC -> EIU

Thus it should be:

SSME Pc Transducer -> ADC -> MDU

I can do some research later at home, if you like.
Maybe a signal conditioner was between Pc sensor and indicator.

Uh... no. I'm 99.999999% sure all the sensors inside the SSME went only to the Input Electronics of the controller. Plus, according to the diagrams DaveS posted, the SSME Pc meters are feed via MDMs FF1/2/3.

Also, there are 4 Pc sensors in each engine (2 per channel), which one would be used by the ADC? This is the kind of decision made by the controller.

 

[Urwumpe]

Uh... no. I'm 99.999999% sure all the sensors inside the SSME went only to the Input Electronics of the controller. Plus, according to the diagrams DaveS posted, the SSME Pc meters are feed via MDMs FF1/2/3.

Also, there are 4 Pc sensors in each engine (2 per channel), which one would be used by the ADC? This is the kind of decision made by the controller.

I'll check this. But I am 100% sure - there is no MDM or GPC involved. (Because some data involved must be read out by OI, without being in the GNC downlist)

 

[GLS]

I'll check this. But I am 100% sure - there is no MDM or GPC involved. (Because some data involved must be read out by OI, without being in the GNC downlist)

:shrug:

In all the stuff I've read about the SSME, all the engine sensors go to the IE. The only sensors "near" the engines that don't (because they are not part of the engine) are the 3 pairs of GH2 Out P and GO2 Out T sensors.

 

[Urwumpe]

Still no GPC involved there. How does it look like from the engine perspective?

 

[GLS]

Still no GPC involved there.

What?! I was under the impression that if a signal comes out of an MDM FF (or FA) it comes from the GPCs....

How does it look like from the engine perspective?

It has 4 sensors that come out the controller in the VDT: the qualified average for "general use" (DW6), and one average for of each pair on each channel, I suppose for data collection (DW22 and 23).

 

[Urwumpe]

What?! I was under the impression that if a signal comes out of an MDM FF (or FA) it comes from the GPCs....

Must not. But the V72 prefix in the MML suggests the parameter at least has its origin in a DPS or OI component. But still, this does not mean it must go via GPC.

I'll look for what I mean when I am home, give me 40 minutes to drive there.

Would this quantity be calculated by a GPC RM and then output to one of the FFs, it would mean a whole lot of more failure modes than I would have expected for such a critical quantity.

 

[GLS]

Must not. But the V72 prefix in the MML suggests the parameter at least has its origin in a DPS or OI component. But still, this does not mean it must go via GPC.

The flight-critical MDMs only talk to the GPCs (on the command side). The OI MDMs talk to the PCMMUs.

Would this quantity be calculated by a GPC RM and then output to one of the FFs, it would mean a whole lot of more failure modes than I would have expected for such a critical quantity.

AFAIK, the only calculation done in the GPCs is a conversion from PSIA to percent (one multiplication) in the SSME SOP. After that it gets output to the MDMs (by somebody in the GPCs) for display.

---------- Post added at 05:08 PM ---------- Previous post was at 04:55 PM ----------

Looking at the MPS Dedicated Display Driver flowchart, it also drove the MCDS MPS Pc meters (I omitted that in the code as we are doing the MEDS version now), and looking at the IO parameters they match the values in the diagram.

MSID        Nomenclature                   Source     Destination
V95U1186C   MPS E-1 PERCENT CH PRESS       SSME SOP
V72P0040C   MPS E-1 MAIN CHAMBER PR/CMPT              D&C Panel
V95U1187C   MPS E-2 PERCENT CH PRESS       SSME SOP
V72P0041C   MPS E-2 MAIN CHAMBER PR/CMPT              D&C Panel
V95U1188C   MPS E-3 PERCENT CH PRESS       SSME SOP
V72P0042C   MPS E-3 MAIN CHAMBER PR/CMPT              D&C Panel

A conversion is made from percent to 0-5 VDC for those parameters.
So that has to be the way the meters were driven, and it also means eventually I have to add the Pc stuff to the MPS DDD to feed the MEDS display.

 

[Urwumpe]

Nothing more? I thought some redundancy management also takes place in the GPC then, but looks like this is already one before.

Still strange - does it look the same for the OMS?

 

[GLS]

Nothing more? I thought some redundancy management also takes place in the GPC then, but looks like this is already one before.

Still strange - does it look the same for the OMS?

The OMS displays are feed directly from the sensors.
The SSME controller does all the redundancy management for its sensors. The SSME is "special", that's why there are 4 parts in the shuttle: the ET, SRBs, OV and SSMEs.