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

Status
Not open for further replies.

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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

New member
Joined
Sep 20, 2009
Messages
22
Reaction score
0
Points
1
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!
 
Last edited:

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I just wanted check in here, how are things progressing on the code front? I'm ready for whatever you'll send my way.
 
  • Like
Reactions: STS

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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....
 
  • Like
Reactions: STS

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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/ft2 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/ft2 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.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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/ft2. 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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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/ft2. 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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Well, its open-loop guidance at this point, we should just have a new pitch table there.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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.
 
Status
Not open for further replies.
Top