Space Shuttle Ultra 1.25 Revision B development

[Poscik]

Try that in MM302. In 302, EXEC should start flashing at TIG-15s, but it doesn't. You have to type OPS 303 PRO, then ITEM 22 EXEC to reload targets, then EXEC starts flashing. But transition to MM303 should be done after OMS, not before...

 

[SiameseCat]

MM302 works for me. In DaveS's scenario, the timing issue will mess up MM302 and might be causing the issue you're describing.

 

[DaveS]

MM302 works for me. In DaveS's scenario, the timing issue will mess up MM302 and might be causing the issue you're describing.

But for me and Poscik, the MM302 bug is completely different. For me, the TIG timer counts down nominally and at TIG-15 EXEC does not start to flash and hence no OMS ignition at TIG.

Also, the DV TGTs should be dynamic and not just affected by a GPC commanded OMS burn. This is to facilitate trimming and RCS burns.

---------- Post added at 06:39 PM ---------- Previous post was at 04:13 AM ----------

Anyone feeling brave enough to implement the light flash of OMS ignitions? Here's a video that shows it:
STS-132 Flight Day 2 highlights

The burn begins at 06:38. It's a single OMS burn, using the right OMS.

---------- Post added at 06:55 PM ---------- Previous post was at 06:39 PM ----------

After quite the messing around in the STS-107 de-orbit scenario, I managed to get MM302 working as it should. I'm not sure what the problem was.

 

[SiameseCat]

I'm fairly sure the MM302 issue was also caused by the time problem mentioned above; I fixed this issue yesterday, so MM302 should also be fixed.

 

[DaveS]

I'm fairly sure the MM302 issue was also caused by the time problem mentioned above; I fixed this issue yesterday, so MM302 should also be fixed.

Maybe. I tried it a few times after an update and recompiled and the problem persisted. EXEC did flash but no OMS ignition.

Another thing: How about enabling OMS gimbal check(ITEM 34)? Another critical procedure for entry and landing is FRCS DUMP(ITEMS 36-38).

---------- Post added at 03:30 AM ---------- Previous post was at 01:40 AM ----------

Have done quite a number of burns using MM202 and everything seems solid, except for the DV items noted earlier.

Decided to change the OMS exhaust texture to something that looked a bit closer to the one shown in the STS-132 video:

 

[SiameseCat]

If you've been using the STS-107 deorbit scenario, the WT is set to 0 when the scenario starts. Unless this value is changed, the burn time calculated will be zero. I've checked in a fixed version, with the burn setup correctly.

 

[DaveS]

I think I have found some issues with the max OMS/ARCS propellant quantities we're using in SSU. Right now the max OMS propellant load in SSU is 14538.0 kg which works out to = 32050.8037 lbs. According to this document: STS-107 L-1 Day Crew Briefing, the OMS load combined was 7860.6 kg or 17329.6566 lbs. That should show up on the O3 RCS/OMS PRPLT QTY indicators as ~67%.

But in SSU it shows 54%. Is maybe due to we're not actually separating the fuel from the oxidizer?

 

[Urwumpe]

We could also just calculate let the fuel quantity less wrong as the Space Shuttle. We have perfect measurements currently, while the Shuttle uses approximations. The fuel quantity that is indicated should always be a bit conservatively calculated, pretty much like in a good car fuel level indicator.

EDIT: 1% of propellant mass should be 130 lb. 80 lb oxidizer, 50 lb fuel. Means we have about 1500 lb too much in the tanks, can it be we have RCS propellant still in the total mass?

 

[SiameseCat]

IIRC, the aft tanks include both OMS and RCS propellant.

 

[Donamy]

Is it being used during ascent ?

 

[DaveS]

IIRC, the aft tanks include both OMS and RCS propellant.

Someone have a list of which propellant resource is which in the scenario files?

 

[Urwumpe]

IIRC, the aft tanks include both OMS and RCS propellant.

We should change this, the OMS does only maximal contribute 1000 lb of 13000 lb per pod to the RCS.

 

[SiameseCat]

We don't have OMS-to-RCS interconnect implemented yet, which is why we originally combined all the tanks. If we're changing the tank setup, we should also split the OMS tanks into left and right tanks.

Personally, I'd prefer to leave the tanks alone for the moment. For one thing, it's still too easy to use up all the RCS fuel. This is partly because the DAP wastes some fuel, and because we can't deselect thrusters the way the real shuttle does.

 

[DaveS]

Personally, I'd prefer to leave the tanks alone for the moment. For one thing, it's still too easy to use up all the RCS fuel. This is partly because the DAP wastes some fuel, and because we can't deselect thrusters the way the real shuttle does.

The reason for the DAP wastage is a very tight deadband. I believe that the default deadband for the primary jets is 0.5° which is very tight. I believe this should be relaxed to 2°s.

---------- Post added at 07:54 PM ---------- Previous post was at 07:50 PM ----------

Just checked the STS-133 Post-Insertion C/L and it initially lists a deadband of 3.5°s, then increases it to 5.0°s at 55 minutes.

 

[DaveS]

Fixed several issues with the STS-107 de-orbit scenario. It now includes all of the STS-107 payloads(SpaceHab, FREESTAR and the EDO kit). It also fixes the too short de-orbit burn burn time. DAP is now in AUTO on scenario start.

 

[DaveS]

Could attitude values (ITEMS 24-26) in MM303 be changed so that when you enter MM303 after the de-orbit burn that the orbiter begins the maneuver to the entry attitude?

 

[SiameseCat]

Yes and no. Allowing ITEMS 24-26 to be changed (or setting them automatically when appropriate) is simple, but these are LVLH angles; they should be inertial angles. To fix this issue, we'll need to add [ame="http://www.orbithangar.com/searchid.php?ID=3825"]KOST[/ame] to find the shuttle's position/velocity at EI-5.

 

[DaveS]

Yes and no. Allowing ITEMS 24-26 to be changed (or setting them automatically when appropriate) is simple, but these are LVLH angles; they should be inertial angles. To fix this issue, we'll need to add KOST to find the shuttle's position/velocity at EI-5.

Will adding KOST also enable the Hp/Ha values to be displayed? And we're missing ITEMs 36-38(FWD RCS DUMP) and 39-40(SURF DRIVE).

Also TTP/TTA needs to be changed so it matches this description:

REI/TXX. Orbiter range in nautical miles from 400k feet to the landing site is shown next to REI in OPS3. Time-to-next-apsis (for OPS1 and 2) or Time-to-400k feet for OPS3 is provided, in minutes and seconds, next to TXX. In OPS1 and 2, time to apogee (TTA) or time to perigee (TTP), whichever is closer, is displayed unless apogee and perigee differ by less than 5 nm. In this case, the title becomes TTC (Time to Circularize) and the time field is blanked. During OPS3, TXX becomes TFF (Time-to-400k feet). In MM303, REI and TFF are recomputed whenever the state vector is updated by ground or HSD entry. If guidance does not converge following a LOAD, these fields will be zeroed (OPS3).

---------- Post added at 05:20 AM ---------- Previous post was at 02:00 AM ----------

One thing I have noticed is that the speedbrake doesn't open to 81% during entry as it should. According to the Entry FDF and the SCOM, this happen at Vrel = 10k fps.

 

[SiameseCat]

KOST might help with the TTP/TTA values and Hp/Ha values. We can get this information from Orbiter, but KOST might make it easier to get consistent values. Orbiter provides instantaneous elements, which change over time due to non-spherical gravity.

 

[DaveS]

KOST might help with the TTP/TTA values and Hp/Ha values. We can get this information from Orbiter, but KOST might make it easier to get consistent values. Orbiter provides instantaneous elements, which change over time due to non-spherical gravity.

True, but some like me do not use non-spherical gravity sources, so instantaneous elements are correct.