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

[STS]

Hello guys,
Just checking status. Are we blocked somewhere? What actions are required to unblock (if we are blocked)? In sort, how can I help?

 

[Urwumpe]

Just checking in here, how is the JSON work coming along?

Only slowly right now - final final exams are in a month, that is currently priority zero for me.

 

[DaveS]

Only slowly right now - final final exams are in a month, that is currently priority zero for me.

Anything to try out yet, even if it is only one or two panels?

 

[Urwumpe]

Anything to try out yet, even if it is only one or two panels?

I try'll try to come up with some examples soon. Maybe until Saturday, but I can't promise it. My paid workhours got reduced to mere 10h/week now, but I can't yet claim to be bored...

One thing about what I did so far: It will turn into a major overhaul of the VC core API - I decided that its easier to make JSON the new standard and turn the old C++ definitions into a legacy API until it is no longer needed. The alternative approaches all turned out to be more effort to ensure a robust panel definition.

Now, I can make the VC components themselves understand JSON and delegate the knowledge of the needed attributes to them, instead of needing to create a huge and unmaintainable factory class for turning JSON into panels.

The old C++ methods for defining the panels can then just be kept for the panels we did not yet migrate, all that will be necessary for a while will be keeping variables for each switch in a panel to make connecting the switches to discrete bundles easier. Maybe those can even be dropped as well, when there is a good way to define this in JSON as well.

And the standard structure for a VC component will be like that :

"Name of component" : {
"class" : "AnyClassName", //Name of the VC component class. Eg, StdSwitch2
"crew": {},  //Support data for player help or implementing AI crew
"animation": {},  //Data needed for defining the animations
"input" : {}  //Data for defining VC event areas
}, ....

 

[STS]

Could this JSON change be used in the future for the cockpit version? (Non Glass Cockpit/Glass Cockpit)


Don´t know if this is intended to allow that configuration.

 

[Urwumpe]

Could this JSON change be used in the future for the cockpit version? (Non Glass Cockpit/Glass Cockpit)


Don´t know if this is intended to allow that configuration.

Sure, it can get used as base there. It has to support the variable panels of the Shuttle anyway, like the tiny differences between the orbiters or different payload configurations. The main difference would be having to support different VC components and use different ways to generate the necessary panel configuration or change it during ground turn around. Everything else can be mapped to what we already have.



And we would need the meshes for that. And before that, the many bugs in the current meshes should get fixed.



And I think supporting the original cockpit is mandatory if we take the historic dimension of the Shuttle serious - but it is low priority as long as the final cockpit is not working completely yet.

 

[DaveS]

The original cockpit was called the Multifunctional CRT Display System (MCDS). The glass cockpit (Multifunctional Electronic Display System, MEDS) was just step 1 of the Cockpit Avionics Upgrade (CAU) which have seen everything modernized, including the emulated DPS displays to take advantage of the enhanced capabilities of MEDS.

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20070018256.pdf
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110011488.pdf

 

[Urwumpe]

The original cockpit was called the Multifunctional CRT Display System (MCDS). The glass cockpit (Multifunctional Electronic Display System, MEDS) was just step 1 of the Cockpit Avionics Upgrade (CAU) which have seen everything modernized, including the emulated DPS displays to take advantage of the enhanced capabilities of MEDS.

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20070018256.pdf
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110011488.pdf

I know - but sadly, CAU ended in a very early phase of development, including those displays would have been nice, but there is not much finished at NASA, the ideas went to Orion.


Still, I would like to eventually have the MCDS cockpit and build Space Station Freedom... and fly to the moon from there.... The early 80s has so many great dreams with the Shuttle, it would be a shame to not keep on dreaming...

 

[DaveS]

NBTW, we seem to have MaxQ earlier and slightly lower than it should be.

80.879794 (SpaceShuttleUltra) {STS-101} [KPI] :   48.9 s MAXQ = 673.3 lb/ft^2

Just testing the idea there. A proper implementation could likely consist of a list of simple event triggers that are recorded during a mission phase.

The current downtime has allowed me to check this out further, and I have discovered a few things:

• Currently we have a so called "mini-bucket" early in first stage ascent. This mini-bucket was done at T+20 seconds only if required due to hot SRBs. The GPCs took a look a current performance at that point and adjusted the throttle bucket to include a "mini-bucket" if the SRB performance was better than expected. As it stands now, we always do this "mini-bucket" even if it isn't required. You can see this "mini-bucket" by watching the SSME Pc gauges, as they reduce from 104 to 100 and then 90. Then from that point we have the main throttle bucket down to 72 and then back up to 104.
• I suspect that we loft our trajectory a bit too much, easing the Q-load on the vehicle. While there was an option to fly a "Low-Q" profile, it was hardly ever used, last time was STS-121 due to the need to lessen the loads on the ET Ice/Frost Ramps that held the GOX/GH2 pressurization lines in place. Then we have this: https://sourceforge.net/p/shuttleultra/tickets/20/

 

[Urwumpe]

What kind of data would you need to further analysing the issue?

And do we even care for SRB propellant temperature?

 

[DaveS]

What kind of data would you need to further analysing the issue?

Mainly alpha and height converted to KFt in 20 second intervals starting at T+30 seconds.

And do we even care for SRB propellant temperature?

Hot SRBs did cause the trajectory to be lofted on STS-1, which had a minimal payload complement. Only about 4 metric tons of payload.

 

[Urwumpe]

Hot SRBs did cause the trajectory to be lofted on STS-1, which had a minimal payload complement. Only about 4 metric tons of payload.

Oh, it is over 10 years away since I last did spaceflight at work, but I do know how much impact the SRB temperature has on real rocket motors.



I meant the implementation in SSU. I know that I considered adding a simple linear factor there to the burn down function some years, even if that is not quite correct. But I am not sure if something happened there then.

 

[DaveS]

Oh, it is over 10 years away since I last did spaceflight at work, but I do know how much impact the SRB temperature has on real rocket motors.



I meant the implementation in SSU. I know that I considered adding a simple linear factor there to the burn down function some years, even if that is not quite correct. But I am not sure if something happened there then.

AFAIK, nothing has changed there in a long time.

 

[Urwumpe]

AFAIK, nothing has changed there in a long time.

Then nothing unexpected, but we should make sure the SRB performance is not always hot.

Q: Do you know if there is a standard document around how NASA created the post-mission reports? Maybe we can use this for creating a HTML output from a mission, like dumping raw data files into a temporary folder and then run a CLI tool in the background to turn the data into a number of HTML documents.

 

[DaveS]

Then nothing unexpected, but we should make sure the SRB performance is not always hot.

Q: Do you know if there is a standard document around how NASA created the post-mission reports? Maybe we can use this for creating a HTML output from a mission, like dumping raw data files into a temporary folder and then run a CLI tool in the background to turn the data into a number of HTML documents.

Maybe there was, but I'm not aware of one.

 

[Urwumpe]

Maybe there was, but I'm not aware of one.

Then its up to us to find what works best for us.



Maybe we can define the necessary data by acceptance criteria, so its easier to reuse and for finding regressions.

 

[DaveS]

Just to outline the reason why I want the theta in 20 second increments starting at T+30 seconds is because that's how things are listed on the Ascent cuecard for first stage ascent. I've attached the one for STS-133. This would velcroed on the little DC Utility Power panel that's located above the forward console inbetween the CDR and PLT. It would be used in case of a GNC failure. The CDR would be flying the vehicle manually using the cuecard as the reference.

Edited to correct alpha to theta.

 

[Urwumpe]

Just to outline the reason why I want the theta in 20 second increments starting at T+30 seconds is because that's how things are listed on the Ascent cuecard for first stage ascent. I've attached the one for STS-133. This would velcroed on the little DC Utility Power panel that's located above the forward console inbetween the CDR and PLT. It would be used in case of a GNC failure. The CDR would be flying the vehicle manually using the cuecard as the reference.

Edited to correct alpha to theta.

Yeah, but we have no cue cards yet. Also for fitting to this data, there should be a first sample of the data at T+10 ... maybe a ten second interval would be better there and you just erase the lines that don't fit.

 

[DaveS]

Decided to make a few runs of STS-109(OV-102 FLT27, full OMS/RCS, HST SM3B, 20k lbs payload), a mission for which we have all the relevant figures.

Here's what I came up with along with the deltas to the historical Ascent Cuecard:

T 0:30 H 9210(delta +210) HDOT 624(delta -25)
T 0:50 H 25K(delta -1K) HDOT 912(delta -69)
T 1:10 H 46K(delta -7K) HDOT 1255(delta -166)
T 1:30 H 76K(delta -7K) HDOT 1754(delta -127)
T 1:50 H 114K(delta -7K) HDOT 2076(delta -112)

Something is clearly off as we're running 7Kft low in altitude throughout the second half of first stage flight with also being too low in HDOT. So we're definitely not flying the vehicle like we're supposed to. Right now, my main suspect is a too aggressive pitch profile, IE, we're pitching down too fast.

 

[Aztronut66]

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.