Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Well, I'm back investigating why we don't have a proper looking SRB sep and I have discovered that the aft BSM thruster positions and directions are seriously off. I have corrected this on the LSRB but then I noticed something weired, the aft BSMs made the booster spin around it's axis(the longitudinal axis, Y).

I am troubleshooting this now. My main theory is that the lone single aft BSM is responsible for the spinning. I have made it part of the main clustered group of aft BSMs to see how this affects the booster's behavior.

---------- Post added at 03:48 AM ---------- Previous post was at 03:12 AM ----------

OK, so the lone aft BSM is not to blame for the spin along the longitudinal axis. Seems like it's the grouped BSMs.

---------- Post added at 04:37 AM ---------- Previous post was at 03:48 AM ----------

Can someone translate this into rotational angles I can use in GMAX:

Separation motors shall be installed in a forward SRB position (nose cone frustum) and
in an aft position (aft skirt). At both the forward and aft locations there shall be a cluster
of four BSMs. At both locations, the thrust vector of the BSM cluster shall be parallel
! 4° to a plane containing the SRB centerline which is rotated 20° about the centerline
from the SRB +Z axis toward the ET (Figure 3.2.1.1.9.1.1.3). The thrust vector of the
forward cluster shall pass within 2.6 inches of the SRB centerline. The thrust vector of
the aft cluster shall be offset 1.95 ! 3.9 inches from the SRB centerline toward the ET
in a direction normal to the 20° plane. In addition, the thrust vector of each cluster shall
be pitched, in the 20° plane, 40 ! 4° from the SRB Y-Z plane; the forward cluster shall
be pitched forward and the aft cluster shall be pitched aft.

 

[DaveS]

I'm creating a set of STS-114/LF1 scenarios and would ike something double-checked.

Here's the mission file, can someone verify that the PayloadZPos lines are correctly defined?

Name=STS-114
Orbiter=Discovery
OrbiterTexture=STSDiscovery
TargetInc=51.620000
TargetLAN=0.000000
MECOAlt=105000.000000
MECOVel=7861.448473
MECOFPA=0.673925
UseOMS=true
OMSAssistStart=133.000000
OMSAssistEnd=223.000000
RollToHeadsUpStartVelocity=15232.54593175853
UseRMS=TRUE
UseODS=TRUE
UseSTBDMPM=TRUE
ODSZPos=10.15
PayloadZPos1=4.00 ;Keel position for ESP-2
PayloadZPos2=-1.80; Keel position for MPLM-F2(Rafaello)
PayloadZPos3=-5.90; Keel position for LMC with replacement CMG and DTO-848 Orbiter TPS repair Demo

And how would the ATTACHED line lines look like for each of the three payloads? Do note that the ESP-2 and MPLM are unberthable/berthable payloads while the LMC is a fixed payload, so I want the A6 PRL panel switches/talkbacks to be active for those two payloads.

 

[SiameseCat]

ESP-2: attachment point 5
MPLM: attachment point 6
LMC: attachment point 8
The PayloadZPos lines start from 0, so you should have

PayloadZPos0=4.00 ;Keel position for ESP-2
PayloadZPos1=-1.80; Keel position for MPLM-F2(Rafaello)
PayloadZPos3=-5.90; Keel position for LMC with replacement CMG and DTO-848 Orbiter TPS repair Demo

 

[DaveS]

ESP-2: attachment point 5
MPLM: attachment point 6
LMC: attachment point 8
The PayloadZPos lines start from 0, so you should have

PayloadZPos0=4.00 ;Keel position for ESP-2
PayloadZPos1=-1.80; Keel position for MPLM-F2(Rafaello)
PayloadZPos3=-5.90; Keel position for LMC with replacement CMG and DTO-848 Orbiter TPS repair Demo

Thanks. So with these numbers, I should have a active A6 PRL panel?

---------- Post added at 06:59 AM ---------- Previous post was at 05:53 AM ----------

Where are we standing on getting the APDS fully working? Currently we have a small bug with saving/loading of the APDS ring state(IE extend the ring, then quit and reload the current state scenario and it will be retracted).

Two other bugs with the APDS is that the struts become detached from the main ODS structure when fully extended in the FORWARD position and that the A/B/C DS lights doesn't work.

 

[Urwumpe]

Where are we standing on getting the APDS fully working? Currently we have a small bug with saving/loading of the APDS ring state(IE extend the ring, then quit and reload the current state scenario and it will be retracted).

Two other bugs with the APDS is that the struts become detached from the main ODS structure when fully extended in the FORWARD position and that the A/B/C DS lights doesn't work.

Can get to this on the weekend maybe, but I actually planned getting the IDP stuff done for commit and move on with the quick GPC simulation (though I also had some small success with the AP-101S emulation in the past weeks)

On an other topic, are there any pad/LCC changes planned? If not, I would prefer doing some support work again, this time start adding a shared plug-in to the project for simulating (radio) communication, TACAN and GPS.

 

[DaveS]

Can get to this on the weekend maybe, but I actually planned getting the IDP stuff done for commit and move on with the quick GPC simulation (though I also had some small success with the AP-101S emulation in the past weeks)

On an other topic, are there any pad/LCC changes planned? If not, I would prefer doing some support work again, this time start adding a shared plug-in to the project for simulating (radio) communication, TACAN and GPS.

Pad/LCC changes: Well, I'm working on a new MLP that now has the correct sound suppression system water pipes for this particular MLP(2).

With these I'll be able to add the aft compartment water deluge nozzles which are activated in case of an RSLS abort. They were installed on all MLPs following the hydrogen fire incident following the RSLS abort during the first launch attempt of STS-41D.

With that I was thinking that FRFs and RSLS aborts could be implemented. FRFs could be implemented by setting ENGINE_FAIL to 101. RSLS aborts could be implemented by taking pre-launch engine starts into account by the ENGINE_FAIL parameter.

 

[Urwumpe]

Pad/LCC changes: Well, I'm working on a new MLP that now has the correct sound suppression system water pipes for this particular MLP(2).

With these I'll be able to add the aft compartment water deluge nozzles which are activated in case of an RSLS abort. They were installed on all MLPs following the hydrogen fire incident following the RSLS abort during the first launch attempt of STS-41D.

OK.

With that I was thinking that FRFs and RSLS aborts could be implemented. FRFs could be implemented by setting ENGINE_FAIL to 101. RSLS aborts could be implemented by taking pre-launch engine starts into account by the ENGINE_FAIL parameter.

I think it would be better to replace the standard flight software configuration for the FRF to prevent a RSLS abort. Also it would be nice if we could get away from the engine fail codes in the long run and have more specific engine failures.

 

[DaveS]

I think it would be better to replace the standard flight software configuration for the FRF to prevent a RSLS abort.

I guess that would be better. Otherwise I was thinking that the RSLS abort would only be included for the ranges 0-100. 101 would be special case, as then you would essentially guarantee an RSLS abort. Ranges 0-100 would be random failures, so you might get an engine failure that results an RSLS abort.

We of the original Atlantis Mod team([ame="http://www.orbithangar.com/searchid.php?ID=1804"]Atlantis Mod 15a[/ame]) did something similar to trigger unrealistic SRB failures on launch. Ranges 0-100 would be for SSME failures(no RSLS aborts though, just in-flight failures), while 101 would tell you pre-launch which engine would fail and 200 would force an SRB failure.

 

[Urwumpe]

I guess that would be better. Otherwise I was thinking that the RSLS abort would only be included for the ranges 0-100. 101 would be special case, as then you would essentially guarantee an RSLS abort. Ranges 0-100 would be random failures, so you might get an engine failure that results an RSLS abort.

Yes, but the problem with the codes is, that we actually plan to move past this level of abstraction. Just a engine shutdown would result in different operations in the VC as a red line trigger.

I would prefer having a line in the scenario file for each failure that is scheduled to happen in the future, and already existing failures being stored in the subsystem state data.

This way to can trigger more specific failures...with the same result (engine stopped), but with different indications or timings.

And a FRF wouldn't be a failure to ignite SRBs anyway, it would be having the ignition commands disabled in the software and the S&A devices of the SRBs safed.

 

[DaveS]

Yes, but the problem with the codes is, that we actually plan to move past this level of abstraction. Just a engine shutdown would result in different operations in the VC as a red line trigger.

I would prefer having a line in the scenario file for each failure that is scheduled to happen in the future, and already existing failures being stored in the subsystem state data.

This way to can trigger more specific failures...with the same result (engine stopped), but with different indications or timings.

And a FRF wouldn't be a failure to ignite SRBs anyway, it would be having the ignition commands disabled in the software and the S&A devices of the SRBs safed.

All true and correct. Based on this, I now see that the software way is the best way to go.

 

[Urwumpe]

All true and correct. Based on this, I now see that the software way is the best way to go.

Yeah, but since we have only a limited number of C++ coders in the project, I think you also agree that we need more ways to get the software work done without needing coders. :lol:

At least there we have more chances to abstract stuff, the subsystem simulation is less forgiving. The ALT software specs (44 MB pdf) describes how the DEUs are driven in Enterprise, and how the display data is stored on the magnetic tapes, this stuff can be made to be edited outside the code, so we only need ITEM, OPS and SPEC handlers from the C++ side. The software specs also contain examples how switch throws of the crew are translated into virtual ITEM inputs. DISPs would even run without application software attached, directly in the cyclic display processor of the GPC.

(Bad is just that there is still no complete listing of the static format control words, I still need to read the specs page by page and gather the FCWs one by one)

The differences to todays Space Shuttles is rather small as far as I can tell, the biggest changes are in the hardware, not in the software or the formats.

 

[DaveS]

How long would it take to code a water deluge test function into the MLP module? Also, could the MLP Side 1 lights be implemented the same way as the FSS pad lights?

 

[Urwumpe]

How long would it take to code a water deluge test function into the MLP module? Also, could the MLP Side 1 lights be implemented the same way as the FSS pad lights?

If it is the same as a normal Sound suppression system activity on the MLP, pretty easily. We would just have to have a visual for the water and separate it from the smoke produced by the engines.

The lights would be quickly added.

 

[DaveS]

If it is the same as a normal Sound suppression system activity on the MLP, pretty easily. We would just have to have a visual for the water and separate it from the smoke produced by the engines.

The lights would be quickly added.

RSLS abort videos:

[ame="http://www.youtube.com/watch?v=KE2R1J-cZIw"]YouTube- STS-51 pad abort (8-12-93)[/ame]

[ame="http://www.youtube.com/watch?v=-zVN9V5uBNc"]YouTube- STS-41D pad abort (6-26-84)[/ame]

 

[Urwumpe]

Any ideas on how to visualize the water? We can make heavier than air particle streams in Orbiter, but these solve only a small part of the view.

 

[DaveS]

Any ideas on how to visualize the water? We can make heavier than air particle streams in Orbiter, but these solve only a small part of the view.

What part of the view? Can you be more specific?

 

[Urwumpe]

What part of the view? Can you be more specific?

The particle streams would just fall through the MLP if we let them run for longer time, and the fog would also look strange with particle streams.

 

[DaveS]

The particle streams would just fall through the MLP if we let them run for longer time, and the fog would also look strange with particle streams.

I was thinking of the aft compartment deluge streams that is activated following an RSLS abort. Not the main SRB overpressure suppression system streams or the rain birds. The SSME sound suppression system systems is rather similar in appearance to the aft compartment deluge streams.

 

[Urwumpe]

I was thinking of the aft compartment deluge streams that is activated following an RSLS abort. Not the main SRB overpressure suppression system streams or the rain birds. The SSME sound suppression system systems is rather similar in appearance to the aft compartment deluge streams.

I think about adding all in a pass, since we have currently only the steam modeled, but no feedback on the sound suppression system

 

[DaveS]

I think about adding all in a pass, since we have currently only the steam modeled, but no feedback on the sound suppression system

Speaking of the steam: I have noticed that there's a lag of approx. 1 second between ME start and the steam, it should be no lag between the two.

Also we need to model the steam being reflected up the sloped section of the south flame-trench as well as the SRB smoke being transported through the north section.