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

[DaveS]

Well...... you know how a classic linker works, right? I think the one used for the PASS Software was called PILOT (DaveS might correct me)

The PILOT (Portable In-flight Landing Operations Trainer) software lived only on the HDD of the PGSCs (Payload/Portable General Support Computer). This photo shows Greg "Box" Johnson, the PLT of STS-125 taking his turn with the PILOT set up at the CDR station on Flight Day 11: https://spaceflight.nasa.gov/gallery/images/shuttle/sts-125/hires/s125e013050.jpg
Noteworthy is that PILOT uses its own RHC clone and not the actual orbiter RHCs as I have thought in the past.

Here's the earliest shot of PILOT I have managed to find: https://science.ksc.nasa.gov/mirrors/images/images/pao/STS67/sts67073.jpg
For STS-67 it was designated as Detailed Test Objective-(DTO)667.

 

[GLS]

There's an interesting conundrum about loading the I-LOADs from the mission file... The mission file gets loaded just before the subsystems and panels get their scenario parameters. The Realize() function is only called later, so using it for the classes to load the I-LOADs doesn't really work if the parameter is also saved to the scenario... which reminds my "how to we control what in the COMPOOL gets saved?" :facepalm:

 

[DaveS]

Test fit of the new SRBs: https://www.dropbox.com/s/qpvrrjzke0ut0pl/New_SRBs_test_fit_1.jpg?dl=0

Note the new additional details on the aft skirt including normal maps on the appropriate areas.

---------- Post added at 02:10 AM ---------- Previous post was at 12:52 AM ----------

Nearly done, just need to fine tune a few things: https://www.dropbox.com/s/q1ceaxat6ai2cdt/New_SRBs_test_fit_2.jpg?dl=0

---------- Post added at 07:16 PM ---------- Previous post was at 02:10 AM ----------

So I have gotten the new SRBs up and running but I have come across a very strange problem which is that the SRBs no longer separate cleanly from the stack. I spent several hours troubleshooting the issue to no avail. I've checked the positions and directions of the BSMs and they're correct.

Should I check in what I got on the new RSRBs for troubleshooting?

 

[GLS]

Should I check in what I got on the new RSRBs for troubleshooting?

Why not, the trunk is broken anyway... :shrug: but I might not get to that today.

 

[DaveS]

Why not, the trunk is broken anyway... :shrug: but I might not get to that today.

No problem, the new RSRBs have been checked in.

 

[GLS]

I had a quick look at the code changes in the trunk, and I see that the OMS (and SSME) positions have changed.... weren't they "written in stone" with precise data from a diagram, sometime ago when the OMS TVC was worked???

 

[DaveS]

I had a quick look at the code changes in the trunk, and I see that the OMS (and SSME) positions have changed.... weren't they "written in stone" with precise data from a diagram, sometime ago when the OMS TVC was worked???

They were but the previous data were measured incorrectly. These ones were measured from very accurate points.


I'm still investigating the previously mentioned vertical offset of the stack on the MLP. I thought it might have been the SRBs but those have been cleared now with the new meshes which were based on actual data from a MSFC SRB Pictorial document. Now I don't know where the issue might be. I have already checked vertical positions of the hold down posts on the MLP and they look correct.

 

[Donamy]

Until we find more accurate ones. :leaving:

 

[DaveS]

I think I have found the cause of the vertical offset issue. I caution that this is very new and preliminary findings but things now point to the ET(s) being the culprit. Checking with the SLWT System Definition Handbook Vol. II, lengths seem to be off.

More investigations need to be done.

 

[Urwumpe]

Until we find more accurate ones. :leaving:

Luckily, nobody noticed yet that LC-39 moved southwest by 1 cm since the first shuttle launch because of continental drift.

 

[GLS]

Luckily, nobody noticed yet that LC-39 moved southwest by 1 cm since the first shuttle launch because of continental drift.

We currently have many Kms of error in relation to the center of the Earth due to the Earth in Orbiter being a perfect sphere, so IMO we can ignore that 1cm error... I take full responsibility for any issues resulting from this. :rofl:

 

[DaveS]

I think I have found the cause of the vertical offset issue. I caution that this is very new and preliminary findings but things now point to the ET(s) being the culprit. Checking with the SLWT System Definition Handbook Vol. II, lengths seem to be off.

More investigations need to be done.

Further investigations have yielded a weak "maybe". Some things are off but the important stuff like attachment points (Orbiter/ET, ET/SRBs) seems to only have minute offsets like 1 or 2 cm. That's not enough to make up the vertical offset.


I'll continue checking things though.

 

[Urwumpe]

How accuratly can you check the dimensions? Something better than a measurement tape function around?

 

[DaveS]

How accuratly can you check the dimensions? Something better than a measurement tape function around?

Decimal accuracy is 5 digits, so down to nanometers. I use the station numbers in the SLWT SDH which are listed in inches. So I convert those to meters as that's what AC3D uses. Then create a box that has the Z dimension set to where the desired station is located.

The forward-most end is located at a confirmed good point, in this case I use the forward end cover of the LOX tank (Sta X_T371). The aft most end then is at where the desired station is. So for the GH2 vent the station is X_T1021.730. So I subtract 371 from that number (1021.730-371=650.73). Then I multiply that with 0.0254 to get it in meters, so 650.73*16.528542. So that number gets copied into AC3D's sizing tool, so I end up with a very accurately sized box.
Since I know that the forward end of the LOX is confirmed to be good, I place the forward vertices of the box to intersect the vertices of the forward end of the LOX tank. So then I just check where the aft vertices of the box end up and compare it to what we have right now.

I don't think there's any better way.

 

[GLS]

So the problem is OV aft/TSM not matching? It can be TSM/HDP error, OV aft/OV-ET attach error, ET-OV attach/ET-SRB attach error, SRB-ET attach/SRB aft skirt error, or all of the above. :shrug:

 

[DaveS]

So the problem is OV aft/TSM not matching? It can be TSM/HDP error, OV aft/OV-ET attach error, ET-OV attach/ET-SRB attach error, SRB-ET attach/SRB aft skirt error, or all of the above. :shrug:

The above is correct. If you look you'll see that the carrier plates not matching up with the orbiter due to the orbiter sitting too high. That's what the white box shows, it shows where the aft ball fittings on the ET should be according to various documents.

---------- Post added 07-28-18 at 01:27 AM ---------- Previous post was 07-27-18 at 09:39 PM ----------

So I decided to check just how far off the current alignment is and it's much more than I ever thought it was. It's 45 cm and I don't know where that much of a misalignment could come from.

I have checked the MLP side again, and everything looks good there. The HDPs are flush with the blast decks as they should be. So no offset build up there. I'll check the aft SRB segments again to be sure that I didn't screw up there.

---------- Post added at 02:15 AM ---------- Previous post was at 01:27 AM ----------

This is the schematic that I have used for the TSMs, as it has the X_O coordinates for various points of the TSM: https://www.dropbox.com/s/yoi7t3xmiijyre1/MLP TSM 4.jpg?dl=0

As you can see, the bottom of the TSM is at X_O1744. The F/D is at X_O1453.

The above schematic comes from this document: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19760021185.pdf

 

[GLS]

Yeah.... that seems to be an "early" document, where they are testing a design, which could have changed between 1976 and 77-78 when the TSMs where built. The GVA was only added to the pad design in 1979, so diagrams that pre-date the hardware should be taken with a grain of salt. :shrug:

 

[DaveS]

Yeah.... that seems to be an "early" document, where they are testing a design, which could have changed between 1976 and 77-78 when the TSMs where built. The GVA was only added to the pad design in 1979, so diagrams that pre-date the hardware should be taken with a grain of salt. :shrug:

This is true but everything does line up, with the coordinates being correct. Even the HAER document on MLP-3 states that the height of the TSMs are 31'.

 

[GLS]

And how are things at the top-end of the stack? Is there any info on the OAA, GVA and ETVAS positions, and do they fit the vehicle?

 

[DaveS]

And how are things at the top-end of the stack? Is there any info on the OAA, GVA and ETVAS positions, and do they fit the vehicle?

I got this updated version from a rather detailed document on the STS facilities and operations at KSC, dated 1984: https://www.dropbox.com/s/g7dawf7rau5di2h/Pad_schematic.jpg?dl=0


And as you can see, the orbiter coordinate control system also places the MLP 0-level at X_O1744.