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

[DaveS]

Hi folks. Not sure if this is the proper place to be posting SSU help questions. If not, please pardon me and point me to the appropriate thread. I am using SSU 4.2 in orbiter 2010 p-1 D3D9 client. OMS2 burn in OPS 105 and 2 OMS plane change burns in OPS 202 go off without a hitch. When I am closing in on the ISS and try to execute OPS 202 rendezvous burn, the OMS engines will not light off. OMS are of course on (ARM/Press) and EXEC at -15 seconds as usual. What am I missing here? Thanks.

Weird. Did you go back to MM201 after each burn? This is required to "reset" MM202 for another burn so it doesn't get hung up on the previous burn data.

 

[Aztronut66]

Hi DaveS, thanks for the reply. I did reset MM202 by going back to MM201 then back, just as I had done between the 2 plane change burns. This is what has me puzzled. I have checked and re-checked all switch positions (ADI Attitude to INRTL, Dap to Auto/Pri/ etc.)

---------- Post added at 10:22 PM ---------- Previous post was at 02:04 PM ----------

I think I figured out the problem. Perhaps a corrupt save file? After ISS synchronization was complete, I created a "Save file" 10 orbits from intercept. I created another "Save file" 5 orbits from intercept. And another at 1 orbit from intercept. It was this "Save file" 1 orbit from intercept that seemed to be the culprit. I loaded the "Save file" that was 5 orbits from intercept and tried to execute a 202 OMS test burn and they lit off just fine. I then reloaded this "5 orbits Save file", time accelerated to 20 km from rendezvous, set up the burn and this time the OMS worked as usual. I wonder if using "Quicksave" would have made a difference :shrug: Thanks again!

 

[DaveS]

I just wanted check in here, how are things progressing on the code front? I'm ready for whatever you'll send my way.

 

[Urwumpe]

I just wanted check in here, how are things progressing on the code front? I'm ready for whatever you'll send my way.

Back at the JSON animation data for the VC for some days now, but only slow progress, I only work on it from midnight to 1 AM right now....

 

[DaveS]

Back at the JSON animation data for the VC for some days now, but only slow progress, I only work on it from midnight to 1 AM right now....

Anything preliminary you can share? Like one panel at the time?

 

[Urwumpe]

Anything preliminary you can share? Like one panel at the time?

I'll look at it, give me a moment.

 

[DaveS]

I think I have discovered a potential fatal bug with the ascent AP, which is that shortly after staging and initialization of closed loop guidance, the stack is commanded to violently pitch down leading to complete loss of control thereafter. Not sure what can be causing this.

Edit:
Just wanted to add that this occurs even on a clean install.

 

[Urwumpe]

I think I have discovered a potential fatal bug with the ascent AP, which is that shortly after staging and initialization of closed loop guidance, the stack is commanded to violently pitch down leading to complete loss of control thereafter. Not sure what can be causing this.

Edit:
Just wanted to add that this occurs even on a clean install.

Can you produce a scenario state shortly before staging where it happens?

 

[DaveS]

Can you produce a scenario state shortly before staging where it happens?

Ignore my report. It was an error on my end, it was that MaxSSMEThrust in the mission was not filled in properly. Once I corrected this, everything was fine.

 

[DaveS]

Found this interesting document on NTRS: https://ntrs.nasa.gov/api/citations/19850008605/downloads/19850008605.pdf?attachment=true
It deals with the structural loads of the shuttle during ascent and has some interesting graphs that would be handy for comparison.

 

[Urwumpe]

Not sure how to include this data in a useful way into Orbiter, is it something that should be checked real-time? Can we create such plots with a generic MFD as well?

 

[DaveS]

Not sure how to include this data in a useful way into Orbiter, is it something that should be checked real-time? Can we create such plots with a generic MFD as well?

I'm mainly thinking of the graph of dynamic pressure shown on page 5 (figure 7). Could do it as lbs/ft² vs sec graph. Orbiter already measures dynamic pressure, of course in Pascals, so it should be no problem taking the output of GetDynPressure and converting into lbs/ft² and either outputting into a csv file or we could have something like the ASCENT TRAJ 1 display with dynamic tracking but for dynamic pressure.

 

[Urwumpe]

Hmmm... I think I see some ways there. Maybe start with a special debug/test MFD for doing this in a coarse and fast way and later move the functionality into a separate application for more precise analysis.

 

[DaveS]

Maybe we could use these tables to compare our ascent AP with the actual ones?
-STS-121 Low Q ascent profile: https://spaceflightnow.com/shuttle/sts121/fdf/121ascentdata.html
-STS-115 Hi-Q ascent profile: https://spaceflightnow.com/shuttle/sts115/fdf/115ascentdata.html

 

[DaveS]

Maybe we could use these tables to compare our ascent AP with the actual ones?
-STS-121 Low Q ascent profile: https://spaceflightnow.com/shuttle/sts121/fdf/121ascentdata.html
-STS-115 Hi-Q ascent profile: https://spaceflightnow.com/shuttle/sts115/fdf/115ascentdata.html

Looking at things, it looks like we're flying a Low-Q ascent, which is hurting our performance, and leading to us consistently hitting a Max Q of around 650 lbs/ft². It is possible that whatever source we used to program the ascent AP described only a Low Q profile. STS-121 flew a Low Q profile to minimize ascent loads on the Ice/Frost Ramps on the ET as there was some concern that that they might not hold up to full Hi-Q loads without the PAL Ramps (STS-121 was the first flight without the two Protuberance Air Load ramps on the ET). After they got the ascent data back, they could fully certify the IFRs for Hi-Q loads in time for STS-115 which needed the additional performance which Hi-Q provided as it carried the heavy P3/P4 truss and its Solar Arrays.

 

[Urwumpe]

Sure, but I am not sure how well those fit to our data, since we have different wind conditions in any scenario.

Its easier to check the first 300m against data than the next 30 km.

 

[DaveS]

Looking at things, it looks like we're flying a Low-Q ascent, which is hurting our performance, and leading to us consistently hitting a Max Q of around 650 lbs/ft². It is possible that whatever source we used to program the ascent AP described only a Low Q profile.

After researching this a bit further, this is quite probable. First Hi-Q mission was STS-95 in October 1998 and was considered a Performance Enhancement. All missions prior to this used what was considered standard back then, Low Q., although it didn't have a name since there wasn't an alternative.

 

[Urwumpe]

Well, its open-loop guidance at this point, we should just have a new pitch table there.

 

[DaveS]

Found this in my document collection: https://sourceforge.net/projects/sh...borts Flight Procedures Handbook.pdf/download

 

[Urwumpe]

The vehicle actually steers off course (into the wind) out of the planned trajectory plane in order to fly out lateral acceleration errors and thus reduce aerodynamic loading. Depending on the severity of the winds, the vehicle can experience a noticeable deviation from the planned trajectory plane. Since the acceleration control biases are applied down stream of the guidance needles, deflection of the ADI error needles is a signature of this type of load relief. Because this important function isn’t included in the error needles, the crew cannot successfully fly the shuttle manually until 90 seconds after lift off.

Thats one important kind of information.