SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Just found the time for some first glances at the Centaur stuff... :blush:

There are quite many ground tiles inside the branch, will have to review what we really need on merge.

About the structure... wouldn't it be smarter to integrate the CISS into the Shuttle as some sort of component? After all, it is not an detachable payload, I would view it like airlock or spacelab/spacehab.

Also we get rid of a lot of inter-vessel communication.

 

[DaveS]

There are quite many ground tiles inside the branch, will have to review what we really need on merge.

Everything except the Centaur stuff can be deleted as they're just older versions of what we currently have in the trunk.

About the structure... wouldn't it be smarter to integrate the CISS into the Shuttle as some sort of component? After all, it is not an detachable payload, I would view it like airlock or spacelab/spacehab.

Also we get rid of a lot of inter-vessel communication.

I agree. We still have to find a way to make the CISS actually do something (mainly rotation and deployment). The CISS was pretty much integrated with the orbiter thanks to the additional plumbing added to 99 and 104. They had even scheduled a Integrated Tanking Test for mid-March 1986 at 39A with the Centaur in the payload bay using 104. I believe it would gone as far as T-31 seconds (GLS Autosequence start) and hold before proceeding into drain and securing.

 

[GLS]

Just found the time for some first glances at the Centaur stuff... :blush:

There are quite many ground tiles inside the branch, will have to review what we really need on merge.

About the structure... wouldn't it be smarter to integrate the CISS into the Shuttle as some sort of component? After all, it is not an detachable payload, I would view it like airlock or spacelab/spacehab.

Also we get rid of a lot of inter-vessel communication.

The only things needed from that branch are just the CISS/Centaur related stuff (meshes, textures, code, config files and scenarios). Can't be harder than the mps merge.:lol:
About the shuttle swallowing the CISS, it's a good idea. This also applies to the ASE for the IUS... and other cradles as well? :S Anyway, that would simplify the mass management on the orbiter. But I think we should do the config upgrades first, and then get the panel done to operate it.

One other thing: the air data probes are not in the correct place when stowed.

 

[Urwumpe]

I agree. We still have to find a way to make the CISS actually do something (mainly rotation and deployment). The CISS was pretty much integrated with the orbiter thanks to the additional plumbing added to 99 and 104. They had even scheduled a Integrated Tanking Test for mid-March 1986 at 39A with the Centaur in the payload bay using 104. I believe it would gone as far as T-31 seconds (GLS Autosequence start) and hold before proceeding into drain and securing.

I'll plan something... first of all, I think about extending the mission file then, to include a "RequiresCISS" flag.

Then, I will simply put it as component into the Shuttle and look how good it works. Since we need an new attachment on loading the scenario, I think I will add three new attachments with fixed numbers to it, that can be also used for other large rocket stages, like PAM-D or IUS, without breaking scenarios quickly. Or had more than three satellites been ever deployed? (except the smaller GAS payloads)

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

Do we really need two similar meshes for the CISS? I think just using a static Prime extension mesh would also do it and we conform to DRY.

 

[DaveS]

I'll plan something... first of all, I think about extending the mission file then, to include a "RequiresCISS" flag.

Then, I will simply put it as component into the Shuttle and look how good it works. Since we need an new attachment on loading the scenario, I think I will add three new attachments with fixed numbers to it, that can be also used for other large rocket stages, like PAM-D or IUS, without breaking scenarios quickly. Or had more than three satellites been ever deployed? (except the smaller GAS payloads)

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

Do we really need two similar meshes for the CISS? I think just using a static Prime extension mesh would also do it and we conform to DRY.

Well, there's no extension. Both needs to be their own meshes due to their forward dissimilarities. As far as I have been able to research, there was no special reconfiguration possible with the CISS. There were going to be two separate versions, one version for the G Prime and one version for the G.

 

[Urwumpe]

Well, there's no extension. Both needs to be their own meshes due to their forward dissimilarities. As far as I have been able to research, there was no special reconfiguration possible with the CISS. There were going to be two separate versions, one version for the G Prime and one version for the G.

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

 

[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?