SSU Payload positioning and some bugs found

[STS]

Hello

I was trying SSU 3.0 with some payload in orbit, but I was wondering how to change the Y axis on the payload. I know that the Z axis is movable, but I didn´t find a way to change the Y. Some "old" Spacecraft3 payloads show too deep in the floor of the bay. I can edit the .ini files for the payloads, but I think there should be a better solution.

Also, some bugs found playing and "trolling" around. I was able to deploy the gear in orbit in OPS201 and also to deploy the chute with the VC buttons & switches. :lol:

Thanks for help.

 

[Urwumpe]

I can edit the .ini files for the payloads, but I think there should be a better solution.

That was the intended way for placing payloads. The flexibility in Z axis was added so the same payload can be placed into different locations of the payload bay without needing different configurations.

Also, some bugs found playing and "trolling" around. I was able to deploy the gear in orbit in OPS201 and also to deploy the chute with the VC buttons & switches. :lol:

Thanks for help.

Deploy gear with any APU running or not? If possible with APU in orbit, its clearly a bug and needs fixing. Also you could blow the nosewheel pyrotechnics that way early.

Deploying the chute should be possible... just look a bit weird. Would need to cross reference the systems manual there to be sure if there are any inhibits possible.

Gear and chute are not depending on the GPC software to get processed, contrary to other GNC related functions.

And if bugs can be confirmed, do you mind being stakeholder for the tickets so you will get asked to confirm that the issues are solved?

---------- Post added at 02:52 AM ---------- Previous post was at 02:44 AM ----------

Can confirm the first bug: Deploying landing gear is possible without hydraulics and without gravity. Without one or the other, there should be only a partial deployment by the pyrotechnics, about one second after commanding gear down. One second after commanding gear down and without hydraulic actuators reacting, the uplock release pyrotechnics are fired (backup deploy), one second after detecting that the uplock was released, the nose wheel extension boost pyrotechnic forces the nose landing gear down.

Check with Systems Handbook: No inhibits existing except a GSE inhibit which is plugged into into the electronics boxes for the pyrotechnics.



---------- Post added at 02:56 AM ---------- Previous post was at 02:52 AM ----------

Second bug also confirmed, but I would rate it at a lower priority since a "realistic" animation of a drag chute in vacuum and microgravity would be harsher.

Much more annoying is the fact, that the drag chute is not connected to the Space Shuttle after deployment, it hangs freely approximately behind the center SSME.

 

[GLS]

The drag chute doesn't stay connected because the speed is > 230 knots, and it's designed to break off :rofl:.
Seriously now, I think the landing gear PBs are disabled when in orbit by a CB somewhere, and the drag chute PBs are probably wired the same way. We don't have those, or any, CBs working (I was thinking of looking into that when the VC upgrade occurs.... hopefully still this year).
Now, if one gets all of that enabled and deploys the gear or the chute, are we expected to have the correct behavior?

 

[Urwumpe]

Now, if one gets all of that enabled and deploys the gear or the chute, are we expected to have the correct behavior?

Mandatory? Not really. But it would sure be a nice option to make SSU better. Like "Ooops, you just created three holes in your heat shield."

 

[GLS]

Mandatory? Not really. But it would sure be a nice option to make SSU better. Like "Ooops, you just created three holes in your heat shield."

That would need a failure simulation capability that can destroy the vehicle... IMO not a real priority ATM, but yes that would be cool.

STS, about your payloads being buried in the PLB, I think if the attachment coordinates for your payloads are where in the same location of the payload keel pins, it should be +/- correctly placed.

 

[STS]

Well, I found those "bugs" being a kid in the cockpit touching buttons. (But in some way knowing what I was doing). I don´t think, as GLS says, that it´s priority ATM, but I could be fixed.

About being stakeholder for the tickets, to confirm they are solved, I don´t mind.

And about the payloads, I´ll edit the ini fot them, I think that this "old" payloads I am using were made for Shuttle Fleet.

 

[Urwumpe]

And about the payloads, I´ll edit the ini fot them, I think that this "old" payloads I am using were made for Shuttle Fleet.

There could be some incompatibilities, the payload bay of SSU has for example some minor changes in the geometry compared to SF.

 

[GLS]

There could be some incompatibilities, the payload bay of SSU has for example some minor changes in the geometry compared to SF.

Looking at the manual, it could be a bit clearer about where the attachment points are located (vertically). I just wrote this addition to section 2.3

Attachments 5 thru 11 are located just below the payload bay liner, so to have a correct vertical positioning of the payload, the attachment coordinates of the payload must be in its keel pin. Attachments 12 thru 19 are located on the side wall of the payload bay, just below the sill.

... if no complains I'll add it to the manual.

---------- Post added at 04:40 PM ---------- Previous post was at 02:18 PM ----------

Done.

 

[Capt_hensley]

How did they keep track of the circuit breakers while flying a mission?

CB's can be collared and forgotten, the big white collar does not seem to bring attention to itself until a deliberate review of the CB panel is made.

On the ground CB collars are written up in the 781a aircraft maintenance forms, under a red diagonal or red X. Did the astronauts do the same?, is it on a checklist?

As for coding it I would think a if,then,else statement to check the bit would work. But where do you store the bit? Which bit's do you check? where do you store the list of bits? It could grow into a monster if your not careful.

JMTCW

 

[GLS]

I'm sure that the checklists have what CBs and switches to flip, so that when they transitoned from launch to orbt, and then from orbit to landing, the systems would be enabled or inhibited as needed.

 

[Urwumpe]

How did they keep track of the circuit breakers while flying a mission?

There are drawings of the panels in the checklists, with the switches and CBs drawn in to be checked against.

Also, what makes life a lot easier: The CBs are colour-coded, the colour of the ring on the CB tells during which phases a CB should be open or closed. It is easy to see which CB is in the wrong position that way.

Also, the telemetry of the space shuttle contains way more values than what the crew can see, it is often directly or indirectly possible to see, if a CB has not been closed or opened when needed.

CB's can be collared and forgotten, the big white collar does not seem to bring attention to itself until a deliberate review of the CB panel is made.

On the ground CB collars are written up in the 781a aircraft maintenance forms, under a red diagonal or red X. Did the astronauts do the same?, is it on a checklist?

They use a different system, but always in the checklist.

As for coding it I would think a if,then,else statement to check the bit would work. But where do you store the bit? Which bit's do you check? where do you store the list of bits? It could grow into a monster if your not careful.

The most effective way is to chain logical functions together, in OOP for example by creating objects for the CBs and connecting the input and output of them together. That is the kind of way we work right now and which will in the future only see cosmetic changes, since it works pretty well.

For example, a switch is connected by a discrete bundle (a bundle of discrete lines in electronics) with a subsystem. Now, it would be no problem extending the switch, so it has an input. The input is connected to a circuit breaker, the circuit breaker to a DC bus or a battery, etc.


The good thing about using objects is, that since the properties of the switches are known, that we can also implement more detailled behaviour into the simulation without having to completely rewrite a complex function. For example some larger load switches inside the Shuttle need a longer time before they switch power.

 

[Marg]

A bit off-topic, but related... it would be interesting to get most realistic aerodynamic parameters for space shuttle (to fill in "spacecraft.ini" type of file). Default parameters really are a bit off, because of impossibility to keep AoA at 40 degrees (max 10-15).
So - too low with too high speed...
Maybe SSU creators have any clue, which are most unaccurate params?

 

[Donamy]

If you want to change the attachment points, just add a new child attachment and name it SSU"x". That way keeping backward compatibility.

 

[Urwumpe]

A bit off-topic, but related... it would be interesting to get most realistic aerodynamic parameters for space shuttle (to fill in "spacecraft.ini" type of file). Default parameters really are a bit off, because of impossibility to keep AoA at 40 degrees (max 10-15).
So - too low with too high speed...
Maybe SSU creators have any clue, which are most unaccurate params?

Its a bit harder because SSU and spacecraftx use different mathematical models. generally, the problem begins at the fact, that you need lift params that work for subsonic glide as well as for supersonic reentry.

The real shuttle can only glide at 40° AOA when the Mach number is above 8.0, below that speed, it gets so nose heavy that its impossible to maintain that attitude. At the same time though, the lift and drag at Mach 20 are so bad, that it could not even land. It is literally a brick then, that just glides a bit better then normal bricks.

Also, the Shuttle can not go from 15° AoA to 40° AOA anyway. that is because the moment function of the shuttle has a plateau near 40°, in which it is just a tiny bit nose heavy, enough to maintain AOA with bodyflap alone. If you are below 35° AOA, the nose would drop regardless what you do. More than 45° AOA and you would flip, regardless what you try to stop it and fly engines first. it only works in a small narrow corridor of AOA.