Project Space Shuttle Vessel

[Tim13]

Sure, whatever works best for you. It's still easy to make a mistake with the MCT (e.g. changing an input in a wrong way and then not being sure what the value was before) and having files saved as backup can be helpful. Saving is optional though, just re-calculating the maneuver sequence before each maneuver is something I would not call optional.

Thanks that clears things up for me. And I heartily agree, that re-calculating before each burn is an absolute must for an accurate PAD.

 

[GLS]

View attachment 49014
Not sure if this would be better off in the payloads thread, but it seems there was a 3rd type of guide for the PRLAs that was super short to not hit the RMS. This shot is from STS-8. Not sure how much this was used and if it might just be better to not have the guides on that latch to avoid making something that was used once.

Yeah, I'm fairly certain that those guides were made specifically for STS-8 when the PFTA moved from STS-11 (where it was going to be a bit forward), and so I ignored those...

 

[DaveS]

While on the subject of payloads: How are you planning to to handle Spacelab? I just wonder because the Spacelab tunnel used its own custom bridge rail panels for the trunnion pins. Currently there's no way to specify this.

 

[GLS]

While on the subject of payloads: How are you planning to to handle Spacelab? I just wonder because the Spacelab tunnel used its own custom bridge rail panels for the trunnion pins. Currently there's no way to specify this.

That would be a lot of configuration work for that "edge case" alone... I'm not saying I'll never do it, but I think it is a better investment to spend time developing the configuration for the GAS canisters.
For now, that SpaceLab bridge can be "cheated" in to place by having the tunnel only held by the keel latch, and having the bridge mesh as part of the trunnion.

 

[Tim13]

@GLS Curiosity question, not a pester either, as I know you're basically a one man show doing God's work. Will the hydraulic flight surface test that occurs just under 4 minutes to go in the launch countdown be in version two of the SSV? Would be cool to see. I always jump out and watch the gimbal check, just because it looks like the orbiter comes alive, and is getting ready to stretch its legs.

 

[GLS]

@GLS Curiosity question, not a pester either, as I know you're basically a one man show doing God's work. Will the hydraulic flight surface test that occurs just under 4 minutes to go in the launch countdown be in version two of the SSV? Would be cool to see. I always jump out and watch the gimbal check, just because it looks like the orbiter comes alive, and is getting ready to stretch its legs.

Hmm, not planning on it just yet... it was commanded by the LPS, and currently there is no LDB or software modules to handle that... but it will be much easier after v2.0.

 

[Tim13]

Curiosity question for anyone who might know. I'm playing around with an ISS rendezvous scenario, where using good historical TLE data, and historical launch time, the rINC is pretty stout; about 0.53 degrees. I'm guessing IRL yaw steering would have negated much of that. My question is what was the typical rINC on insertion for an ISS mission, and what was the largest ever?

 

[GLS]

where using good historical TLE data, and historical launch time

Well, there are 2 factors in Orbiter that make those things^^^ not necesarily good enough.
First is the time: Orbiter uses TBD, and the Shuttle used GMT/UTC, and they are not the same, and the difference between them changed over time. Then there is the shape of the Earth in Orbiter being spherical, which means that the launch pad is not where the real one was. So, launching "on-time" (which actually is the wrong time), will put the target in the wrong place, plus the launch is from the wrong location, which means things won't perform as well as they did in reality.
So, that is the general picture, but unless things add up in the wrong way, you should still be able to get to MECO with 0 delta-Inc, which will set you up well for rendezvous.
What you are seeing might be related to the setting for spherical-gravity. Does this setting match between Orbiter and FDO MFD? Where, and when, are you seeing those 0.53º?

 

[indy91]

Curiosity question for anyone who might know. I'm playing around with an ISS rendezvous scenario, where using good historical TLE data, and historical launch time, the rINC is pretty stout; about 0.53 degrees. I'm guessing IRL yaw steering would have negated much of that. My question is what was the typical rINC on insertion for an ISS mission, and what was the largest ever?

When using non-spherical gravity this sort of RInc after insertion can be completely normal. Both Shuttle and target are affected by nodal regression (longitude of the ascending node changing over time), but this effect is different at higher vs. lower altitude. So the Shuttle often had to have a different longitude of the ascending node at insertion than its target so that by the time of rendezvous the two orbital planes have aligned themselves due to orbital mechanics. This is mostly a function of phase angle because the Shuttle has to spend more time in a much lower orbit when it has to catch up to the target a lot. 0.53 degrees would be pretty normal for maybe 240 degrees of phase angle.

 

[Tim13]

Well, there are 2 factors in Orbiter that make those things^^^ not necesarily good enough.
First is the time: Orbiter uses TBD, and the Shuttle used GMT/UTC, and they are not the same, and the difference between them changed over time. Then there is the shape of the Earth in Orbiter being spherical, which means that the launch pad is not where the real one was. So, launching "on-time" (which actually is the wrong time), will put the target in the wrong place, plus the launch is from the wrong location, which means things won't perform as well as they did in reality.
So, that is the general picture, but unless things add up in the wrong way, you should still be able to get to MECO with 0 delta-Inc, which will set you up well for rendezvous.
What you are seeing might be related to the setting for spherical-gravity. Does this setting match between Orbiter and FDO MFD? Where, and when, are you seeing those 0.53º?

Thanks for the info! It's a STS-101 scenario I'm playing around with. I just checked, and I have spherical gravity selected for both the sim and the FDOMFD. I did use historical TLE's for the scenario/mission creation, and I'm using the historical launch time. I'm not using a huge amount of propellent to get to the ISS, but it does put me at the lower end....about 37% remaining. I guess I just assumed that every shuttle launch to the ISS or MIR inserted pre-OMS-1/2 within hundredths or thousandths of a degree rINC, and not tenths of a degree.

 

[Tim13]

When using non-spherical gravity this sort of RInc after insertion can be completely normal. Both Shuttle and target are affected by nodal regression (longitude of the ascending node changing over time), but this effect is different at higher vs. lower altitude. So the Shuttle often had to have a different longitude of the ascending node at insertion than its target so that by the time of rendezvous the two orbital planes have aligned themselves due to orbital mechanics. This is mostly a function of phase angle because the Shuttle has to spend more time in a much lower orbit when it has to catch up to the target a lot. 0.53 degrees would be pretty normal for maybe 240 degrees of phase angle.

Thanks for explaining that. I do have one follow up question. When I set up the STS-101 FDO mission file, I didn't understand which generic plan to use. I looked at them, compared them to known good scenarios/missions, and picked PlanD. After recently looking at the plans again, I think my phase angle after insertion isn't correct for PlanD, and should be one of the other generic plans. Would having the wrong generic plan in the FDO MFD mission folder cause any kind of issue? Going from memory, I thiiiiiink my initial phase angle at OMS-2 is around 80 degrees.

 

[indy91]

Thanks for the info! It's a STS-101 scenario I'm playing around with. I just checked, and I have spherical gravity selected for both the sim and the FDOMFD. I did use historical TLE's for the scenario/mission creation, and I'm using the historical launch time. I'm not using a huge amount of propellent to get to the ISS, but it does put me at the lower end....about 37% remaining. I guess I just assumed that every shuttle launch to the ISS or MIR inserted pre-OMS-1/2 within hundredths or thousandths of a degree rINC, and not tenths of a degree.

Yeah there is a problem with spherical gravity. Because of the required difference in LAN at insertion the optimum launch time is also different between spherical and non-spherical gravity. In an extreme case you would not even be able to use the historical launch time together with a state vector from a TLE, too much yaw steering required during ascent. Even when it is possible to use both options with the same same launch time, the mission file and/or scenario would have to be set up slightly different. So I think the general idea now (I believe @GLS agrees) is to use non-spherical gravity for all missions. By this point it is supported well enough in SSV and with tools like the FDO MFD. Spherical gravity also remains supported by both in the mean time.

Thanks for explaining that. I do have one follow up question. When I set up the STS-101 FDO mission file, I didn't understand which generic plan to use. I looked at them, compared them to known good scenarios/missions, and picked PlanD. After recently looking at the plans again, I think my phase angle after insertion isn't correct for PlanD, and should be one of the other generic plans. Would having the wrong generic plan in the FDO MFD mission folder cause any kind of issue? Going from memory, I thiiiiiink my initial phase angle at OMS-2 is around 80 degrees.

Well two possible issues, you might get some retrograde maneuvers, which is a waste of propellant, or worse, you would have to dip down into the atmosphere to make a rendezvous plan work. The exact range of phase angles for a specific plan will also not be universal, it depends on the altitude of the target vehicle.

 

[Tim13]

Yeah there is a problem with spherical gravity. Because of the required difference in LAN at insertion the optimum launch time is also different between spherical and non-spherical gravity. In an extreme case you would not even be able to use the historical launch time together with a state vector from a TLE, too much yaw steering required during ascent. Even when it is possible to use both options with the same same launch time, the mission file and/or scenario would have to be set up slightly different. So I think the general idea now (I believe @GLS agrees) is to use non-spherical gravity for all missions. By this point it is supported well enough in SSV and with tools like the FDO MFD. Spherical gravity also remains supported by both in the mean time.



Well two possible issues, you might get some retrograde maneuvers, which is a waste of propellant, or worse, you would have to dip down into the atmosphere to make a rendezvous plan work. The exact range of phase angles for a specific plan will also not be universal, it depends on the altitude of the target vehicle.

Oh OK. I thought we were supposed to only use spherical gravity. I'll play around with changing both to non-spherical gravity. Thanks.

 

[craf7y24]

Hi, everyone! First of all wanna say thanks to GLS, and the devs worked on SSV predecessor, SSU. I've been following developement like for 15 years . I always wanted to see a ultimative Space Shuttle in Orbiter.
I don't know GLS opinion on LLMs, but feeding Opus 4.7, 4.8 with subsystems workbooks can give some what of legit results.
I did a local fork and somewhat of FCS implementation, FCS channels, bypasses, ATVC, ASA, force-fights.
A test failuresubsystem module which can define things failed or to fail in .scn, here's a scr of test one, bypass on SERVO of CTR engine on Pitch, and ATVC power fail on 4.
Resulting to going for OVERRIDE on FCS 1, and 2.


Another one is somewhat of TAL guidance (selection, variable IY steering, targetting M24 - RTGO 2800, no dumps yet (seems that's gonna be another branch for DPS/OMS/RCS).


Pure vibecoding experiments lol, I won't send a PR (unless there's a demand for that, but I can do upload a fork to GH for somewhat of review or tests, lol).

 

[GLS]

That's a lot to unpack!

Hi, everyone! First of all wanna say thanks to GLS, and the devs worked on SSV predecessor, SSU. I've been following developement like for 15 years . I always wanted to see a ultimative Space Shuttle in Orbiter.

Thanks!

I don't know GLS opinion on LLMs, but feeding Opus 4.7, 4.8 with subsystems workbooks can give some what of legit results.

Meh...
I never "fed" the "online monsters", but I played with offline models with... hmm... mixed results (yes, tiny models compared to what is available in the interwebs). Still, after chewing the SCOM, replying that the SSMEs have 3.3Mlbf of thrust doesn't get my confidence up. Plus, it would be hopeless with a 1980s doc, which such poor scanning that no OCR can make it readable. I think another issue is diagrams and schematics... how well will it chew those?
I'm sure it is good enough to help in (very) limited tasks (math, physics, structure/organization), but I don't think it will produce a complete subsystem easily, with the required detail of commands and sensors, etc.
Still...

I did a local fork and somewhat of FCS implementation, FCS channels, bypasses, ATVC, ASA, force-fights.

..., I wouldn't mind taking a look at the ASAs, ATVCs, (hyd actuators too?), as those are not yet being commanded via the FC busses, but "directly" from the software, so I consider those candidates for improvement in the short term.

A test failuresubsystem module which can define things failed or to fail in .scn, here's a scr of test one, bypass on SERVO of CTR engine on Pitch, and ATVC power fail on 4.

Failures would be nice to have, but: a) needs to be thought thru, and, b) needs "good enough" subsystems in order for something to fail properly.

Another one is somewhat of TAL guidance (selection, variable IY steering, targetting M24 - RTGO 2800, no dumps yet (seems that's gonna be another branch for DPS/OMS/RCS).

Aborts I want to leave for v3.0, because the stack will need to be attached differently, and I'd also like to get a better countdown, etc.
As for the dumps, I fully expect they will be possible in v2.0, both ascent OMS dumps as well as RCS dumps prior to entry. The DPS branch is currently the main focus, which started as a need for "a bit better" displays for the OMS/RCS work, and then became a monster.

Pure vibecoding experiments lol, I won't send a PR (unless there's a demand for that, but I can do upload a fork to GH for somewhat of review or tests, lol).

Dirty word!
Like I said above, I wouldn't mind taking a look, so a fork would work.

 

[DaveS]

..., I wouldn't mind taking a look at the ASAs, ATVCs, (hyd actuators too?), as those are not yet being commanded via the FC busses, but "directly" from the software, so I consider those candidates for improvement in the short term.

When is improvements to GNC and APU/hydraulic systems planned for? Would like to have a fully working ADI and given that the APU/hydraulic system is by far the oldest system in SSV (it dates back to the original Space Shuttle Deluxe in 2007) I think it needs some attention.

 

[GLS]

When is improvements to GNC and APU/hydraulic systems planned for? Would like to have a fully working ADI and given that the APU/hydraulic system is by far the oldest system in SSV (it dates back to the original Space Shuttle Deluxe in 2007) I think it needs some attention.

The N in GNC is not on the horizon: not simple and needs IMU and other stuff.
For the G and C, the orbit part of it should be done for v2.0 to use the RCS properly. Plus, with the reorganization of the data flow, the ADI will at least do more than now, but probably it will do everything. For the ascent part, it won't change much until v3.0.
The APU/HYD part... right now my main issue is the calculation of the quantities for display, which I explained sometime ago. Other than that, it needs actuators and flows, and pressure from the aerosurfaces to "feel the air" and limit motion during high-q situations.

 

[craf7y24]

That's a lot to unpack!


Thanks!



Meh...
I never "fed" the "online monsters", but I played with offline models with... hmm... mixed results (yes, tiny models compared to what is available in the interwebs). Still, after chewing the SCOM, replying that the SSMEs have 3.3Mlbf of thrust doesn't get my confidence up. Plus, it would be hopeless with a 1980s doc, which such poor scanning that no OCR can make it readable. I think another issue is diagrams and schematics... how well will it chew those?
I'm sure it is good enough to help in (very) limited tasks (math, physics, structure/organization), but I don't think it will produce a complete subsystem easily, with the required detail of commands and sensors, etc.
Still...



..., I wouldn't mind taking a look at the ASAs, ATVCs, (hyd actuators too?), as those are not yet being commanded via the FC busses, but "directly" from the software, so I consider those candidates for improvement in the short term.



Failures would be nice to have, but: a) needs to be thought thru, and, b) needs "good enough" subsystems in order for something to fail properly.



Aborts I want to leave for v3.0, because the stack will need to be attached differently, and I'd also like to get a better countdown, etc.
As for the dumps, I fully expect they will be possible in v2.0, both ascent OMS dumps as well as RCS dumps prior to entry. The DPS branch is currently the main focus, which started as a need for "a bit better" displays for the OMS/RCS work, and then became a monster.



Dirty word!
Like I said above, I wouldn't mind taking a look, so a fork would work.

here you go:

GitHub - maximqaxd/SSV at dps-rework

Space Shuttle Vessel. Contribute to maximqaxd/SSV development by creating an account on GitHub.

github.com

The irony that i named the branch because first I attempted to separete model to 5 GPCs, you will see by commit history Commits are pretty messy, because coauthored by AI, and i actually needed to create a new branch for every new subsystem i was working on, but i didn't expected a good results in short-time term, you can see by commit history that TAL was done in one day, and it is really flyable from ABORT pb to the ground.


Summary from Opus, what's been done to FCS->MDM->FC wiring:
Here's the full FCS↔MDM↔FC-bus wiring in SSV, verified against the code.

## FC bus strings (4)
Each string = one FF (Flight-critical Forward) + one FA (Flight-critical Aft) MDM, commanded by its GPC:

| String | FF (addr) | FA (addr) | Commander |
|--------|-----------|-----------|-----------|
| 1 | FF1 (25) | FA1 (19) | GPC 1 |
| 2 | FF2 (26) | FA2 (20) | GPC 2 |
| 3 | FF3 (27) | FA3 (21) | GPC 3 |
| 4 | FF4 (28) | FA4 (22) | GPC 4 |

FCS effector commands/feedback go through the FA MDMs; FCS sensors (RGA rates, accelerometers, ADTA) come in through the FF MDMs. Each RS GPC commands only its own string's FA MDM (RSM fcStringMask); the 4 redundant commands OR at the hardware — so GPC1→FA1→ASA channel 1, GPC2→FA2→ch 2, … (matches the MDM Equipment-Lost chart, FA*n*→FCS CH n).

## Aerosurface command (GPC → FA MDM AOD → ASA → actuator)
1. Aero_Act_SOP computes each surface command, encodes deg→volts (AOD_KV: elevon/rudder 0.1 V/deg, speedbrake 0.05) into COMPOOL SCP_FAn_IOM4_CHm_DATA — one channel per surface, per string.
2. SimpleFCOS_IO_GNC::output() sends them to each string's FA MDM IOM4 (AOD), CH0–5, gated by CommandsString.
3. SimpleMDM_FAn drives dopIOM4_HI[0..5] → bundle AEROSURFACE_FAn (CH0=LOB, LIB, RIB, ROB elevons, CH4=rudder, CH5=speedbrake).
4. AeroSurfaces reads dipCh[surf][string] from the four AEROSURFACE_FA1..4 bundles, decodes volts→deg = each ASA channel command, and force-sums the 4 channels at the ram. (Body flap is still the legacy single-channel path.)

## Aerosurface feedback (RVDT → FA MDM AIS → GPC)
AeroSurfaces drives dopFB[surf] → AEROSURFACE_FB (ram-position RVDT) → each SimpleMDM_FAn reads it via IOM6 (AIS) CH0–5 → SCP_FAn_IOM6_CHm_DATA → SimpleFCOS_IO_GNC::input() → the PFB SOPs (Elevon/Rudder/Speedbrake) do a 4-channel mid-value-select RM → selected position.

## SSME / SRB TVC (ATVC)
MPS_ATVC_CMD_SOP / SRB_ATVC_CMD_SOP encode gimbal commands into FA IOM4 AOD — SSME CH9–14, SRB CH15–18 → SimpleMDM_FAn → bundle ATVC_FAn → gnc::ATVC decodes + force-sums the 4 strings → drives the SSME/SRB hydraulic actuators (MPS_TVC::UpdateActuator).

## OMS TVC
OMS_TVC_Command_SOP → FA IOM4 CH7/8 (L/R pitch/yaw) → OMS_TVC; feedback via FA IOM14 (AIS) CH14/15.

## Failure propagation

• FA MDM power — MDM_Power bundle (FA1–4 = ch 4–7) → AeroSurfaces drops an unpowered string's ASA channel from the force-sum (single-MDM loss tolerated; surface held by remaining strings).
• Commfault — SCP_COMMFAULT_WORD_1 bits 12–15 = FA1–4 (0–3 = FF1–4) gate each MDM's I/O and trip the FCS-channel down-arrows / annunciation.

So end to end: GPC (Aero_Act/ATVC SOP) → COMPOOL FAn_IOM4 → FCOS per-string send → FA*n* MDM AOD → AEROSURFACE_FAn/ATVC_FAn bundle → ASA/ATVC channel → 4-channel force-sum → actuator, with RVDT feedback returning through FA*n* IOM6 AIS to the PFB-SOP MVS. The FF MDMs feed the sensor side of the loop.

 

[Tim13]

What is this called? Anybody have any tips how it's used when rendezvousing? I've managed to meet the ISS at what seems like a reasonable distance and rate of closure, but I'm not sure how to visually get from there, to station keeping. I see in videos this is used, but I'm not sure how. I looked in the SSV manual, but was unable to find info on it.

 

[GLS]

View attachment 49153

What is this called? Anybody have any tips how it's used when rendezvousing? I've managed to meet the ISS at what seems like a reasonable distance and rate of closure, but I'm not sure how to visually get from there, to station keeping. I see in videos this is used, but I'm not sure how. I looked in the SSV manual, but was unable to find info on it.

The title at the top says it all: it displays the Ku-Band antenna rates (in the EL/AZ coordinates), as it tracks a target, so you can tell which direction the target is going.
It shakes too much currently, but it is still usable. An improvement is on the todo list.