SSU Development Thread (2.0 to 3.0)

[DaveS]

OK, then I will make two separate systems which will just have annoyingly much code in common.

How are you thinking? There shouldn't be any code differences as the only differences are forward of the important stuff (Deployment Adapter). The animations should be exactly the same with same animation data.

Everything else is identical. Another pro to this integrated approach is that we enable the use of the PRLA switches on A6U to operate the PRLAs that hold the Centaur trunnion pins for launch/entry.

 

[Urwumpe]

How are you thinking? There shouldn't be any code differences as the only differences are forward of the important stuff (Deployment Adapter). The animations should be exactly the same with same animation data.

Everything else is identical. Another pro to this integrated approach is that we enable the use of the PRLA switches on A6U to operate the PRLAs that hold the Centaur trunnion pins for launch/entry.

I am thinking about using mostly the same code for both, but use a structure with meshgroup IDs to map between the different definitions.

Should we get other internal differences (connections to the Centaur, pneumatics, etc), we can still build it on the same base code.

 

[DaveS]

I am thinking about using mostly the same code for both, but use a structure with meshgroup IDs to map between the different definitions.

Should we get other internal differences (connections to the Centaur, pneumatics, etc), we can still build it on the same base code.

All data should be in these two documents:

Centaur G Technical Description: https://dl.dropboxusercontent.com/u/24122088/STSCentaur/CENTAUR G TECHNICAL DESCRIPTION.PDF

Centaur G Prime Technical Description: https://dl.dropboxusercontent.com/u/24122088/STSCentaur/Centaur G-Prime Technical Description.PDF

 

[Urwumpe]

All data should be in these two documents:

Centaur G Technical Description: https://dl.dropboxusercontent.com/u/24122088/STSCentaur/CENTAUR G TECHNICAL DESCRIPTION.PDF

Centaur G Prime Technical Description: https://dl.dropboxusercontent.com/u/24122088/STSCentaur/Centaur G-Prime Technical Description.PDF

I will take a look at this tomorrow...had been working 10 hours today, I need a rest for the next long workday.

So far I think I have a plan there, but I will try to keep things easy so we have a chance to merge the Centaur into the current release without delays.

---------- Post added at 11:53 PM ---------- Previous post was at 11:38 PM ----------

LOL... The Control Units on the CISS had been based on a Zilog Z-80 ... somebody around who still knows how to program these beauties?

 

[SiameseCat]

Thanks a bunch for the updated manual! :thumbup:
Now, this is not complaining, but I have compiled a "nitpicking list" (I would do all of this, but after 2 attempts at installing TeX editors, I've given up on that format... :compbash

page 4
> The spacecraft3 reference is not needed.
> Should mention the need to activate/enable CRTMFD.
> I know it probably doesn't look good, and it might not make sense, but could the URLs be shown? If the document is printed there's no way to know the link.
> About the lines to be added, the readme file (SSU Readme First.txt) mentions a few more... who's wrong?

page 8/9
> Is it possible to put the 2 images in the same page? Maybe by cropping some white space off the edges of the images?

page 10
> RMS grapple/release keys don't work here, but key 8 works.

page 11
> In the ascent phase: "MECO is commanded" should be replaced by "A manual MECO is commanded".
> At the top of the 2 column: "The table below" should be "Table 2", and maybe with a link to it?

page 13
> The image description should say something like "attachment locations on the Orbiter with (right) and without (left) ODS".
> About the text below the image: aren't bridgerails shown now? We just don't have the horn-like "guide things", right?

page 16
> At the end of the text: shouldn't the OMS/MPS etc, have a chapter for them? Something like "MEDS displays", after the DPS displays. If so, please inform so I can give a hand in the writing.

page 17
> Should add the phrase "Currently no item entries are supported" to the ENTRY TRAJ chapter.
> Correction to the HORIZ SIT chapter: "Only ITEMs 41, 3, 4, 6, 8 and 39 are supported. ITEM 41 selects the landing site, ITEMs 3 and 4 switch between the primary and secondary runway (not necessarily the same physical runway), ITEM 6 switches between a straight-in and overhead approach, ITEM 8 switches the aim point between nominal and close, and ITEM 39 switches between nominal, short and ELS (Emergency Landing Site) speedbrake configurations for final approach. These parameters all affect the entry autopilot, so they should be set as early as possible, preferably before Entry Interface (EI)."

page 18
> The table is outdated, "Landing Sites currently available in SSU" file has current list.

general
> There should be one (or more) empty lines after the TOCs.
> Question: the "Version 1.XX Rev. B" refers to the manual or the SSU "code"?

I finally got round to making these changes. I haven't added a section on the MEDS displays. I think the MEDS displays are close to the actual displays, so the NASA documentation should be mostly sufficient. If you want to write something, I can add it to the tex file.

---------- Post added at 09:42 PM ---------- Previous post was at 09:40 PM ----------

I am thinking about using mostly the same code for both, but use a structure with meshgroup IDs to map between the different definitions.

Should we get other internal differences (connections to the Centaur, pneumatics, etc), we can still build it on the same base code.

If you want to use the same code but with different animations, it might be a good idea to look at the Crawler code. The Crawler has 2 versions, which are identical but have different meshes.

 

[GLS]

I finally got round to making these changes. I haven't added a section on the MEDS displays. I think the MEDS displays are close to the actual displays, so the NASA documentation should be mostly sufficient. If you want to write something, I can add it to the tex file.

As that section of the manual is basically describing the differences between our displays and the real ones, I think we should mention the missing parts, that as you say aren't many. I'll write something for that.
Another thing, should we add an image of the display next to the text for each of them? Everybody likes images with the text... :lol: If everybody is cool with it, I can get the images ready to be put in the manual.

 

[GLS]

I just added to the trunk the display images.
Here is the text description for the displays (with a few corrections on the existing ones (my opinion of course):
ASCENT TRAJ
This display is used in MM 102 and MM 103 to monitor the vehicle's trajectory during ascent. The DROOP ALT digital output is not being driven, and no item entries are currently supported.

BFS GNC SYS SUMM 1
This display shows the status and data of several systems. At the moment only the MPS He pressures and dP/dT, ET ullage pressures, MPS manifold pressures and aerosurface position digital outputs are being driven.

ENTRY TRAJ
These displays are used during entry to monitor the vehicle's trajectory. Currently the only digital outputs being driven are the q-bar, delta-AZ and NY outputs. The guidance box and trailers are not displayed, the phugoid scale is not driven and no item entries are supported.

VERT SIT
These displays are used during TAEM to monitor the vehicle's trajectory. Currently the only digital outputs being driven are the SPD BK, SPD BK CMD and NY outputs. The Theta scale and the E/W scale are not driven.

HORIZ SIT
... the shuttle relative to the HAC and the runway. Currently the vertical error scale is not driven prior to A/L interface, and only ITEMs 3, 4, 6, 8, 39 and 41 are supported. ITEM 41 selects the landing site...

OMS/MPS
The OMS/MPS display provides information about various pressures in the OMS and MPS systems. The OMS He TK P and N2 TK P meters are not driven.

APU/HYD
The APU/HYD display shows pressures, quantities and temperatures related to the hydraulic system. The APU H2O QTY %, OIL IN TEMP ºF and HYDRAULIC QTY % meters are not driven.

SPI
The SPI display shows the position of the orbiter's aerosurfaces. The BODY FLAP % indicator is non-functional.

A/E PFD
The A/E PFD display shows several parameters relevant to Ascent and Entry. Currently the attitude error needles are not properly driven, so they are not to be trusted. The ADI is operating in LVLH mode only with yaw zeroed, so the ADI ATT switches have no effect. During TAEM, and up until A/L interface, the vertical position error is not being driven, and the heading error is not being driven. The HSI is missing all the bearing pointers, and during launch it is not referenced from the target plane. The X-Trk value is not being driven.

ORBIT PFD
The Orbit PFD is used for on-orbit display of vehicle attitude. Currently the attitude error needles currently are not being driven properly, so they are not to be trusted. The ADI currently operates only in the LVLH mode with yaw zeroed, so the ADI ATT switches have no effect.

I think putting the images after the first phrase would look good.

And now some more "complaining" :lol::
page 3
>> caps usage not consistent: used in 2.1, 2.2 and 3.1, but not in 2.3, 3.2 and 3.3.

page 9
>> at the bottom right add "(Terminal Area Energy Management)" after "TAEM"

page 6
>> the TOC and the 2.2.1 entry are "full page" instead of in a column. maybe putting the key actions in 3 tables (or all in 1?) would work better, with the table heading: "key combination" and "action"

page 14
>> is there really a need for this description? if so, what other systems should be added?

page 16
>> "3.3.7 VERT TRAJ" should be " 3.3.7 VERT SIT"

---------- Post added at 10:40 PM ---------- Previous post was at 09:13 PM ----------

I just noticed a small "error" in the pad: the SRB deflector shields (or whatever they are called) are not in the "launch position" below the MLP but instead are parked on the north end of the pad. (Also, the SSWS pipes on the north side of the flame trench seem to be north of where they should be.) So this got me thinking, and this seems to be a good "project" for me to start working on animations. It's just translation (attaching the pipe there would be asking too much ), and I don't think this is critical for this release so I can take my time and play with it. So, I need the group IDs of those deflectors (right? :blush.

 

[DaveS]

I just noticed a small "error" in the pad: the SRB deflector shields (or whatever they are called) are not in the "launch position" below the MLP but instead are parked on the north end of the pad. (Also, the SSWS pipes on the north side of the flame trench seem to be north of where they should be.) So this got me thinking, and this seems to be a good "project" for me to start working on animations. It's just translation (attaching the pipe there would be asking too much ), and I don't think this is critical for this release so I can take my time and play with it. So, I need the group IDs of those deflectors (right? :blush.

West SRB Side Flame Deflector (SFD): Line18, Box311
West SRB Side Flame Deflector (SFD): Line13, Box310

---------- Post added 04-04-15 at 12:01 AM ---------- Previous post was 04-03-15 at 11:50 PM ----------

This photo shows the "J" pipe that connects the east flame trench water deluge pipe with the SRB IOP suppression system pipes on the MLP: https://www.flickr.com/photos/apacheman/5738691904/

And this photo show the same flame trench water deluge pipe without the "J" pipe: https://www.flickr.com/photos/apacheman/5738135949/

 

[GLS]

[/COLOR]This photo shows the "J" pipe that connects the east flame trench water deluge pipe with the SRB IOP suppression system pipes on the MLP: https://www.flickr.com/photos/apacheman/5738691904/

And this photo show the same flame trench water deluge pipe without the "J" pipe: https://www.flickr.com/photos/apacheman/5738135949/

So, looking back in Orbiter I see that actually it doesn't seem to be nothing wrong with the positions, it's just missing a small section that connects the horizontal pipe to the "J" pipe. IMO it can stay as is, because there are more important things to do.

 

[DaveS]

So, looking back in Orbiter I see that actually it doesn't seem to be nothing wrong with the positions, it's just missing a small section that connects the horizontal pipe to the "J" pipe. IMO it can stay as is, because there are more important things to do.

Actually, the "J" pipe is what connects the MLP SRB IOP suppression system to the pad water system. It's called a "J" pipe because it looks like a "J" when it is disconnected.

 

[GLS]

Actually, the "J" pipe is what connects the MLP SRB IOP suppression system to the pad water system. It's called a "J" pipe because it looks like a "J" when it is disconnected.

Yes I know, but there's a small segment of horizontal pipe missing between the "J" and the horizontal pipe with the water nozzles. But like I said it's not important.

---------- Post added 04-04-15 at 04:41 PM ---------- Previous post was 04-03-15 at 11:55 PM ----------

Commited the movable flame deflectors! It was faster/easier than I expected... hopefully everything is working.
It looks like the MLP and the pad don't agree in their sizes, because the SRB holes seem to be too much to the south, so the deflectors aren't 100% in the correct position in relation to the MLP. I placed using the main flame deflector as reference and overall it doesn't look bad.

 

[DaveS]

Could someone come up with MECO data that has the orbiter in a 228x60x51.64 (km) trajectory at MECO? This is for STS-114 which had a historical post-OMS-2 orbit of 228.9072x157.7904x51.64 (km).

The historical TIG for OMS-2 was 000/00:38:00.0. OMS-2 CO TGO was 1:05 with a DV of 98.9 fps.

 

[GLS]

Could someone come up with MECO data that has the orbiter in a 228x60x51.64 (km) trajectory at MECO? This is for STS-114 which had a historical post-OMS-2 orbit of 228.9072x157.7904x51.64 (km).

The historical TIG for OMS-2 was 000/00:38:00.0. OMS-2 CO TGO was 1:05 with a DV of 98.9 fps.

I'm afraid that's not going to work. In order to meet the 228Km apogee and a 55Km perigee it takes 7878.034702m/s, and for STS-114 MECO was at 25819.6fps or 7869.814m/s. So I think the problem here is that those MECO values you gave are not exactly from MECO, but are instead from the pre-OMS-2 orbit, and those are different because of (at least) 3 events post-MECO: the -Z translation, the MECO dump and the +X translation.
I could add those 3 effects to the MECOTool calculations, but it might take a while as I'm short on time. Anyway, the current values in the STS-114 mission file for MECO speed and altitude* are pretty much correct. The flight path angle is (very likely) incorrect, due to lack of (exact) data (just committed a correction that I think makes it less wrong).
On top of all this, the AscentGuidance code doesn't hit the exact flight path angle, so that doesn't help.
All in all, I'd say we have a +/- good system. If we want to get precision from it we must feed it precision as well.

*) MECO altitude, and perigee, play a very critical roll in this. We read MECO altitude of 52NM, but is it really 52.0NM or 51.6NM or 52.4NM? All of these uncertainties add up and that doesn't help us...

 

[DaveS]

How about a compromise: MECO targets for an OMS-2 burn with the historical burn data (DV 98.9 fps, TGO 1:05, TIG of 38 even, post-burn orbit of 228x157).

---------- Post added at 07:31 PM ---------- Previous post was at 04:50 PM ----------

So as I'm doing some more work on the orbiter, the turn has come to the midbody payload umbilical panels (T-4 umbilical panels). How should I make them to be most efficient, code-wise?

 

[Urwumpe]

How should I make them to be most efficient, code-wise?

A Meshgroup for the panel that covers them, that can be Activated/Deactivated by modifying the meshgroup flags?

Possibly for the outside, a separate meshgroup for the existing and the removed versions.

 

[DaveS]

A Meshgroup for the panel that covers them, that can be Activated/Deactivated by modifying the meshgroup flags?

Possibly for the outside, a separate meshgroup for the existing and the removed versions.

The exterior of the panel is currently part of the Centaur_Mission_Kit_plumbing.msh file in ShuttleCentaur branch. The standard panel doesn't really look like much other than the holes for the fasteners around perimeter of the panel. They're partially obscured by the "United States" lettering on the midbody.

 

[Donamy]

How about a compromise: MECO targets for an OMS-2 burn with the historical burn data (DV 98.9 fps, TGO 1:05, TIG of 38 even, post-burn orbit of 228x157).

---------- Post added at 07:31 PM ---------- Previous post was at 04:50 PM ----------

So as I'm doing some more work on the orbiter, the turn has come to the midbody payload umbilical panels (T-4 umbilical panels). How should I make them to be most efficient, code-wise?

Please dont break it. :facepalm:

 

[DaveS]

Please dont break it. :facepalm:

What do you mean?

 

[Urwumpe]

Please dont break it. :facepalm:

He should do it on a branch anyway. :lol:

What happens in the army Centaur branch, stays in the Centaur branch - unless something magical happens, the Centaur branch should not be ready for the next release anyway. I think we are too far in the trunk to wait.

 

[GLS]

How about a compromise: MECO targets for an OMS-2 burn with the historical burn data (DV 98.9 fps, TGO 1:05, TIG of 38 even, post-burn orbit of 228x157).

But to do that the MECO targets would not match the historical data...


Question about the OMS/RCS mass change in r2090: where did those numbers come from? I'm asking because 38% OMS load seems WAY too little, it should be 70% at least for an ISS mission plus with the OMS assist (for STS-114 OMS load was 95.7%).
A word of caution: currently the OMS shares the same propellant resource as both ARCS. The way I updated those masses a while back was I calculated the OMS mass and then added a full ARCS load mass (standard, right?), and then calculated the % of the OMS prop resource. Yes, it's a major simplification/limitation to have a shared resource, but I vote to keep things as they are for this release. Fixing it now would probably break every scenario, and we will have to do that for the OMS/RCS update after this release, so this is something I can live with for now.