Space Shuttle Ultra 1.25 Revision B development

[Urwumpe]

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.

I know, I can't tell why. The code should start producing smoke immediately.

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.

Can you make a drawing with the "velocity vectors" of the smoke, what you mean? I believe I understand you, but I could need a drawing to be sure.

 

[DaveS]

Can you make a drawing with the "velocity vectors" of the smoke, what you mean? I believe I understand you, but I could need a drawing to be sure.

Here's screenshot of the flame-trench which shows the slope on the south side. Thing in the middle is the flame-deflector.

 

[SiameseCat]

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.

Fixed the ring state bug.

 

[DaveS]

Fixed the ring state bug.

OK, what about the A7 panel bug and the struts becoming detached from the base of the ODS?

 

[DaveS]

And it should be made optional as missions without the airlock doesn't have it anyway!

---------- Post added at 01:51 AM ---------- Previous post was at 01:26 AM ----------

Something I have noticed while doing some STS-107 launch runs is that MECO occurs too early. Post-MECO trajectory is correct and good but the MECO time is very early, occurs at about MET 000/00:07:48.

I don't know if it's because we don't simulate the correct empty mass of OV-102. I have added the approximate correct payload launch mass(14446.4 kg) and I'll see if that additional mass will make the MECO occur later.

---------- Post added at 02:18 AM ---------- Previous post was at 01:51 AM ----------

An update the MECO time situation: Adding the payload launch masses had no effect whatsoever on the MECO time.

Now I know we have a problem somewhere. I just did a test launch with the simulated combined weights of a fully tanked Centaur G Prime upper stage, it's support structure and Galileo which masses 25 mT, something according to my sources would have required 109% on all three SSMEs.

Also increased the mass of the empty mass of the ET to that of a LWT. Still, no problems getting into the planned orbit for Centaur G Prime missions! And that is with the SSMEs at just 104.5%!

We're lighter and/or running something hotter than the real thing.

So right now I would suggest that we try to track this down, going through each propulsion element one-by-one to make sure that the numbers we have are accurate and correct.

 

[Urwumpe]

Now I know we have a problem somewhere. I just did a test launch with the simulated combined weights of a fully tanked Centaur G Prime upper stage, it's support structure and Galileo which masses 25 mT, something according to my sources would have required 109% on all three SSMEs.

Also increased the mass of the empty mass of the ET to that of a LWT. Still, no problems getting into the planned orbit for Centaur G Prime missions! And that is with the SSMEs at just 104.5%!

We're lighter and/or running something hotter than the real thing.

So what? Is that really the error? I have reasonable doubts. Get more data = MECO residuals, otherwise we check around the stuff without any clue.

Data that makes sense: Payload mass, MECO time, MECO velocity vector, MECO altitude, MECO flight path angle, all vs targeting data.

Then we can start looking.

Also, how did you set the payload mass? Did you make sure the payload mass is really included and not dropping away during the initialization?

So right now I would suggest that we try to track this down, going through each propulsion element one-by-one to make sure that the numbers we have are accurate and correct.

See above. I don't think I need to check the tire pressure when the fuel indicator displays empty.

 

[Urwumpe]

Payload mass set through the PAYLOAD_MASS parameter in the scenario.

AFAIR, the parameter had never any effect.

 

[DaveS]

AFAIR, the parameter had never any effect.

Well, that might explain some things. So, how are going to include payload masses? Mission files or getting their actual masses during sim-run and adding that to the shuttle mass?

 

[Urwumpe]

Well, that might explain some things. So, how are going to include payload masses? Mission files or getting their actual masses during sim-run and adding that to the shuttle mass?

No idea yet. If you want, I enable the parameter as cheat, until we have a good way. I would prefer storing payload masses for EACH attachment point.

EDIT: OK... it should already have effect. I thought it did not produce any difference in mass, the last time I checked.

 

[DaveS]

EDIT: OK... it should already have effect. I thought it did not produce any difference in mass, the last time I checked.

Well, that is what I'm seeing here as well. It does have an effect on the vehicle total mass.

 

[Urwumpe]

Well, that is what I'm seeing here as well. It does have an effect on the vehicle total mass.

Yes. So the next question is, where does this mass penalty end in the effect? Do we miss the MECO targets? or do we magically hit them, regardless of the mass?

 

[Donamy]

Maybe it happens after SRB sep.

 

[SiameseCat]

At what mass is the shuttle unable to reach orbit?

 

[DaveS]

Yes. So the next question is, where does this mass penalty end in the effect? Do we miss the MECO targets? or do we magically hit them, regardless of the mass?

Well, a STS-107 mission we hit the MECO targets perfectly, even early based on MET, at around 7:45-7:50.

NASA claims that the Galileo mission as planned back in 1986(Centaur G Prime fully tanked) would have required 109% on the SSMEs.

As designed, the maximum payload to orbit for the shuttle was 65,000 lbs(29.25 mT). I'm going to try with a 75,000 lbs(33.75 mT) payload.

---------- Post added at 07:48 AM ---------- Previous post was at 07:19 AM ----------

75,000 and 70,000 lbs was too much for the shuttle to handle with a LWT, due east from KSC.

Something I did note was that the ET hit 0% exactly at the 8 minute mark in both cases.

---------- Post added at 08:01 AM ---------- Previous post was at 07:48 AM ----------

65,000 lbs was also a bust, same config and orbit. ET ran dry at 8:03 MET.

 

[DaveS]

Can the standard font in CRTMFD be upgraded/changed to more resemble the font used in the real orbiter MDUs? This is a screengrab of the OPS2 SM mode being displayed on Atlantis' CRT4 in OPF1 earlier today.

Second is a shot of the PDRS CONTROL display, OPS2 SM SPEC094, same orbiter, same MDU.

Another one is of the SM GROUND CHECKOUT display.

Edit:
This is for a RMS Turnaround Test that is currently ongoing in OPF1 on Atlantis.

 

[Urwumpe]

Can the standard font in CRTMFD be upgraded/changed to more resemble the font used in the real orbiter MDUs? This is a screengrab of the OPS2 SM mode being displayed on Atlantis' CRT4 in OPF1 earlier today.

The font can be changed, it is just a bitmap currently, we don't paint it by line data like the real Shuttle does (an simplification for better frame rates).

 

[DaveS]

The font can be changed, it is just a bitmap currently, we don't paint it by line data like the real Shuttle does (an simplification for better frame rates).

OK, found the CRTMFD bitmap. Any guess on the closest match font?

 

[Urwumpe]

OK, found the CRTMFD bitmap. Any guess on the closest match font?

Maybe Lucida Console is close, it is sans serif and nonproportional :

0011/ / GPC MEMORY 1 U 122/09:35:17

EDIT: No, doesn't work, the As and Rs are too geometric. It is rather a version of the console standard font, like Terminal in 14 pt size.

 

[DaveS]

Maybe Lucida Console is close, it is sans serif and nonproportional :

0011/ / GPC MEMORY 1 U 122/09:35:17

EDIT: No, doesn't work, the As and Rs are too geometric. It is rather a version of the console standard font, like Terminal in 14 pt size.

Well, posted the question on MEDS DPS font on the NASASpaceflight.com forum. Someone there ought know!

 

[Urwumpe]

Well, posted the question on MEDS DPS font on the NASASpaceflight.com forum. Someone there ought know!

Yeah, would be nice to get some data. I suspect the MEDS uses an avionics standard font, but I am not deep enough into the topic for telling. The DEU used a symbol generator which got the font data loaded during IPL, together with the critical format load.