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

[DaveS]

As far as the full stack aerodynamics go, here's what we got right now:
1st stage(SRB+ET+Orbiter):
SetCrossSections(_V(668.94, 676.94, 258.97));
SetRotDrag(_V(0.7, 0.1, 0.3));
SetPMI(_V(249.62, 239.97, 67.43));

2nd stage(ET+Orbiter):
SetCrossSections(_V(303.91, 422.33, 153.51));
SetRotDrag(_V(0.7, 0.1, 0.3));
SetPMI(_V(131.82, 131.49, 59.28));

And I really think that we should focus on getting the basic SSV (Space Shuttle Vehicle, the "stack name" for the fully assembled vehicle) done first. We have a viable roadmap, let's stick to it.

 

[DaveS]

I'm running some basic integration checks on a fully assembled stack mesh using orbitersdk's shipedit tool, and while the X and Z axes mostly check out, the Y axis is very off.

 

[DaveS]

I updated the cross-section and PMI parameters with the ones I got from the shipedit runs and they made practically no difference SRB impact points whatsoever. This tells me that our problem is elsewhere.

 

[DaveS]

I'm fixing up the various exterior lights of the orbiter and I need a bit of help. I found this on the pointing of the PLB flood lights:

"six lights mounted outside cargo bay envelope. 135° conical beam pointed within approx. 5° of normal to cargo bay centerline". Can someone translate that into a usable set of vectors?

 

[Urwumpe]

I'm fixing up the various exterior lights of the orbiter and I need a bit of help. I found this on the pointing of the PLB flood lights:

"six lights mounted outside cargo bay envelope. 135° conical beam pointed within approx. 5° of normal to cargo bay centerline". Can someone translate that into a usable set of vectors?

Well, for the vectors, its pretty much saying you this: The direction of each spot light is maximal 5° away from the normal of the payload bay centerline (+y). each spotlight has an opening angle of 135/2° in orbiter.

 

[DaveS]

Well, for the vectors, its pretty much saying you this: The direction of each spot light is maximal 5° away from the normal of the payload bay centerline (+y). each spotlight has an opening angle of 135/2° in orbiter.

So that would translate into direction of -0.707107, -0.707107, 0(45°)?

 

[DaveS]

I'm just trying to make sense of it when compared to the actual locations of the lights.

 

[Urwumpe]

I'm just trying to make sense of it when compared to the actual locations of the lights.

Well, it is no position, just a direction of the light cone. Not sure if the goal was really achieved in engineering, but I am sure it can't be far away from the 5° criteria.

 

[DaveS]

Something we definitely need to add in 5.0 is better logging of errors, especially RSLS cut-offs. I've created a STS-73 mission file+launch scenario but every time I try it, it results in an RSLS Hold at T-27 seconds with no explanation for what system caused the Hold flag to be set, making troubleshooting a very tiresome endeavor.

 

[Urwumpe]

Something we definitely need to add in 5.0 is better logging of errors, especially RSLS cut-offs. I've created a STS-73 mission file+launch scenario but every time I try it, it results in an RSLS Hold at T-27 seconds with no explanation for what system caused the Hold flag to be set, making troubleshooting a very tiresome endeavor.

Can be done. I already started looking at the sources again, now that I am free of any exams, but it will take some time to get up to velocity. Also I want to have some dev time for another project.

Would some simple debug log to be activated by a config file flag be good enough for you?

 

[DaveS]

Would some simple debug log to be activated by a config file flag be good enough for you?

Yes, that would be sufficient. This repeated RSLS Hold problem is perplexing as I used the SSU Workbench to generate the mission file and scenario. It has worked nicely in the past, but now for whatever reason it has generated either an incorrectly configured scenario and/or mission file. I haven't changed anything in the code for it other than to the RMS elbow camera orientation for launch.

 

[Urwumpe]

Damn, is the RSLS code a hell of a spagetti code nightmare. I think I will put it high into the priorities for refactoring when switching towards a new DPS.

I currently work on letting it write into the default log file when it aborts a launch, maybe this already helps you.

 

[DaveS]

Damn, is the RSLS code a hell of a spagetti code nightmare. I think I will put it high into the priorities for refactoring when switching towards a new DPS.

I currently work on letting it write into the default log file when it aborts a launch, maybe this already helps you.

That will help plenty as long as it reports the system out of spec at the time of the Hold flag set. This was something available to the GLS console operators as soon as HOLD/ABORT flag was set in the software. Extended information was available through PC-GOAL which was essentially an Instrumentation/Subsystem Lead (ISL) program designed to supplement the GLS as it was only able to provide limited information as it had to interface with the old orbiter GPCs. PC-GOAL was as its name suggests a modern PC (back in late 90's) program that was able to interface more completely with all the instrumentation on the vehicle as as the pad.

The GLS could only provide slightly more information than the error log of the orbiter DPS.

 

[Urwumpe]

Do you know where the original documentation for the RSLS software was?

That will help plenty as long as it reports the system out of spec at the time of the Hold flag set. This was something available to the GLS console operators as soon as HOLD/ABORT flag was set in the software. Extended information was available through PC-GOAL which was essentially an Instrumentation/Subsystem Lead (ISL) program designed to supplement the GLS as it was only able to provide limited information as it had to interface with the old orbiter GPCs. PC-GOAL was as its name suggests a modern PC (back in late 90's) program that was able to interface more completely with all the instrumentation on the vehicle as as the pad.

The GLS could only provide slightly more information than the error log of the orbiter DPS.

PC-GOAL is just a runtime environment for the Ground Operations Aerospace Language, a specialist programming language used at NASA. Originally it ran on a IBM 370.

Not sure if we really need this one or could provide a similar function with other programming languages today. GOAL was a product of the early days of computing.

 

[Urwumpe]

Some information is already written there into Orbiter.log, did you check this?

 

[DaveS]

Some information is already written there into Orbiter.log, did you check this?

Yes but it's very bare bones. All it says for me is that the HOLD flag is set and not much more. It doesn't say why.

This is what is in Orbiter.log concerning the RSLS hold:

000006.291: LCC: RS Countdown Hold Flag is on
000006.291: LCC: LPS Go For Auto Seq Start Hold
000006.291: LCC: Cutoff

The rest is just the normal systems loading logging.

 

[Urwumpe]

Yes, but that is already a good point to start. No other information before those lines from the LCC?

 

[DaveS]

Yes, but that is already a good point to start. No other information before those lines from the LCC?

None.

 

[Urwumpe]

None.

OK, I will expend this a little.

 

[DaveS]

Possible bug: There's something wrong with playing of the SSME sound files. Before I file an official ticket I'd like confirmation that the issue isn't on my side. The problem is that sometimes only the ignition sound plays and sometimes none of them play. I don't have any problems playing them back outside of Orbiter.