Project Space Shuttle Vessel

[Tim13]

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.

So it's called the line of site rates display....didn't think it would be that easy coming from a government agency.

So how is it used? Do you put the DAP in lvlh alt modes then use rcs translation? Assuming top and bottom is prograde and retrograde, or is that the z axis?

 

[GLS]

So it's called the line of site rates display....didn't think it would be that easy coming from a government agency.

So how is it used? Do you put the DAP in lvlh alt modes then use rcs translation? Assuming top and bottom is prograde and retrograde, or is that the z axis?

This is the EL/AZ coordinate system, so looking at that display is like looking up thru the overhead windows.


E.g., if the AZ needle is to the left, it means the target is moving towards the left, not where it is, but just the direction of relative motion.

As for usage... I'm not sure it had much use. AFAIK, it is the only way to find out where the target is moving towards while approaching during the night, but the system is so good that this probably used just to confirm that the rates are low, i.e., the relative motion is mostly radial.

 

[Tim13]

I need some tips. Help me save myself from pulling up the default docking MFD and cheating.

I get to the MC4 burn, and all is well. Testing out the results of the burn and just monitoring to see what happens, I'll end up around 500 feet below the ISS, and less than 1.0 on the R based on the values shown in SPEC 33. Then of course, I start diverging, try to correct, and things go south from there.

I'm struggling with the visual portion. Station keeping at this point is eluding me. Visually fine tuning my orbit to be in the same orbit as the ISS is a mystery right now.

Any advice is welcome, no matter how obvious it may seem to you, it may turn on the light switch for me.

 

[GLS]

I need some tips. Help me save myself from pulling up the default docking MFD and cheating.

I get to the MC4 burn, and all is well. Testing out the results of the burn and just monitoring to see what happens, I'll end up around 500 feet below the ISS, and less than 1.0 on the R based on the values shown in SPEC 33. Then of course, I start diverging, try to correct, and things go south from there.

I'm struggling with the visual portion. Station keeping at this point is eluding me. Visually fine tuning my orbit to be in the same orbit as the ISS is a mystery right now.

Any advice is welcome, no matter how obvious it may seem to you, it may turn on the light switch for me.

I think the Rendezvous checklist has a page or 2 with the procedures following MC-4: RPM, TORVA, etc.
Not having anyone else to help, I find it easier to bypass the UNIV PTR display and put the DAP in B, LVLH, VERN, and translation PULSE, and that keeps the attitude in relation to the ISS (which should be in LVLH) and gives fine translational control (0.1fps, I think). For now focus on the basics and bypass the RPM and proceed to the TORVA.
Put the centerline camera view in one TV, which is visible from the aft pilot station. Take your time, it isn't supposed to be like the Apollo 13 movie, with thrusters firing all over the place, the trajectory is designed to have the orbital mechanics help and to save prop. When you get to the V-bar, go full zoom in on the centerline camera, to see the target and got a decent alignment for far out, and then bring it in (don't forget to power the APDS).

 

[Go For PDI]

I need some tips. Help me save myself from pulling up the default docking MFD and cheating.

I get to the MC4 burn, and all is well. Testing out the results of the burn and just monitoring to see what happens, I'll end up around 500 feet below the ISS, and less than 1.0 on the R based on the values shown in SPEC 33. Then of course, I start diverging, try to correct, and things go south from there.

I'm struggling with the visual portion. Station keeping at this point is eluding me. Visually fine tuning my orbit to be in the same orbit as the ISS is a mystery right now.

Any advice is welcome, no matter how obvious it may seem to you, it may turn on the light switch for me.

One thing I have found (and the Shuttle Crew Operations Manual actually does mention this) is that it's easy to forget about range rate while focusing on the COAS/crosspointer. Especially since you are approaching from below and the orbits "want" to diverge. You have to keep thrusting at the thing to sustain a decent closing rate. Other than that, take it slow and steady. Follow the closing rates specified in the checklist (lock the Ku antenna on and put the display in range/rate mode) and keep it centered in the COAS while you slowly close in. TORVA is pretty easy if you just let UNIV PTG handle the rotation, and translate to keep the target centered and closing. Then you just keep on easing in. Hope that helps!

 

[Tim13]

One thing I have found (and the Shuttle Crew Operations Manual actually does mention this) is that it's easy to forget about range rate while focusing on the COAS/crosspointer. Especially since you are approaching from below and the orbits "want" to diverge. You have to keep thrusting at the thing to sustain a decent closing rate. Other than that, take it slow and steady. Follow the closing rates specified in the checklist (lock the Ku antenna on and put the display in range/rate mode) and keep it centered in the COAS while you slowly close in. TORVA is pretty easy if you just let UNIV PTG handle the rotation, and translate to keep the target centered and closing. Then you just keep on easing in. Hope that helps!

Thanks for that tip. I’m going to add it to my SSV/FDO tips and tricks document, which is just a mish mash of words of wistom I’ve been collecting over time. Appreciate it.

 

[Tim13]

I recently had a person DM me ask me a couple things, so I thought I'd drop some of my response here, because it got me thinking about some stuff.

"What I’m finding with the FDOMFD is that it requires a fair amount of trial and error, but unfortunately, for trial and error to be effective, you need to have a very good understanding of what the burns are, and especially what the secondary constraints are. Speaking of secondary constraints, you need to know when they can be deleted, or have to be deleted. Along with that, you need to be able to decide if a burn can be removed if it’s not needed, or if another burn needs to be added. Essentially, the FDOMFD gives you a ton of info, and then it’s up to you to decide how that info is used, or in some cases ignored.

So what I started working on over a month ago, are two documents. One is a condensed version of the STS-126 OMP walk through in the FDOMFD user manual. I’ve taken the 20 pages in the FDO manual that cover the walk through, and boiled it down to an easily digestible 5 pages, broken down by burns. Then I took the 5 page condensed version, and turned it into an even more condensed checklist style document that you can graduate to once you know what you’re doing with the condensed document. So essentially, a person needs to really study the FDO manual, and fail over and over in the SSV. Once concepts are learned, moving to the condensed version of the walk through can be done, and once everything is really well learned from the condensed version, the checklist version that contains no real explanations other than the sequence of events can be used.

But….here’s the problem. The walk through in the FDO manual won’t translate to every space shuttle rendezvous mission to ISS, MIR, or Hubble. That walk through is specific to STS-126. I’ve been trying to apply my two documents to STS-101 for the past month, but with little success. Sometimes it works, sometimes not.

I’m starting to think that what’s actually needed is for a package of launch scenarios to the ISS, MIR, and HST, that are individualized for each historic mission; custom SSV mission.json file, SSV scenario.scn file, and FDOMFD mission.txt file. Actually, a dual package would be better, one mission pack that’s just the shuttle, with no payload, so you don’t have to download and install anything other than the SSV, and can just practice rendezvous procedures, and another mission package with the historical payloads, for those that want to advance to the next level.

My goal is to eventually get my documents to the point that they can be used by new users, to lower the learning curve, lower the bar to entry, and open up the amazing SSV + FDOMFD to more people. There are tons of people that just want to run some rendezvous missions, but don’t want to put in 3 months of study, and research to almost get there. I’ve been hitting Orbiter/SSV/FDO pretty hard the past couple months, and I’m getting burned out. So I’m actually going to pull back a bit, take a little break from SSV and FDO, and let things ruminate. I’m going to lick my wounds, head back to flight sim land, and enjoy the experience of flying that I actually know how to do….LOL."

 

[indy91]

I recently had a person DM me ask me a couple things, so I thought I'd drop some of my response here, because it got me thinking about some stuff.

"What I’m finding with the FDOMFD is that it requires a fair amount of trial and error, but unfortunately, for trial and error to be effective, you need to have a very good understanding of what the burns are, and especially what the secondary constraints are. Speaking of secondary constraints, you need to know when they can be deleted, or have to be deleted. Along with that, you need to be able to decide if a burn can be removed if it’s not needed, or if another burn needs to be added. Essentially, the FDOMFD gives you a ton of info, and then it’s up to you to decide how that info is used, or in some cases ignored.

So what I started working on over a month ago, are two documents. One is a condensed version of the STS-126 OMP walk through in the FDOMFD user manual. I’ve taken the 20 pages in the FDO manual that cover the walk through, and boiled it down to an easily digestible 5 pages, broken down by burns. Then I took the 5 page condensed version, and turned it into an even more condensed checklist style document that you can graduate to once you know what you’re doing with the condensed document. So essentially, a person needs to really study the FDO manual, and fail over and over in the SSV. Once concepts are learned, moving to the condensed version of the walk through can be done, and once everything is really well learned from the condensed version, the checklist version that contains no real explanations other than the sequence of events can be used.

But….here’s the problem. The walk through in the FDO manual won’t translate to every space shuttle rendezvous mission to ISS, MIR, or Hubble. That walk through is specific to STS-126. I’ve been trying to apply my two documents to STS-101 for the past month, but with little success. Sometimes it works, sometimes not.

I’m starting to think that what’s actually needed is for a package of launch scenarios to the ISS, MIR, and HST, that are individualized for each historic mission; custom SSV mission.json file, SSV scenario.scn file, and FDOMFD mission.txt file. Actually, a dual package would be better, one mission pack that’s just the shuttle, with no payload, so you don’t have to download and install anything other than the SSV, and can just practice rendezvous procedures, and another mission package with the historical payloads, for those that want to advance to the next level.

My goal is to eventually get my documents to the point that they can be used by new users, to lower the learning curve, lower the bar to entry, and open up the amazing SSV + FDOMFD to more people. There are tons of people that just want to run some rendezvous missions, but don’t want to put in 3 months of study, and research to almost get there. I’ve been hitting Orbiter/SSV/FDO pretty hard the past couple months, and I’m getting burned out. So I’m actually going to pull back a bit, take a little break from SSV and FDO, and let things ruminate. I’m going to lick my wounds, head back to flight sim land, and enjoy the experience of flying that I actually know how to do….LOL."

As it turns out, when trying to implement a tool faithfully that the real Shuttle FDOs used, what we ended up with is something that requires a level of orbital mechanics knowledge of a real Shuttle FDO

But I have also been thinking about this topic. We should really start a collection of mission specific data for the FDO MFD. It's not just difficult to come up with a Maneuver Constraints Table for a new mission, it's also work intensive enough that it would be a shame if this is something multiple people start doing for the same mission. What I have been struggling with is establishing some "guidelines" for this. Like, what data would we actually be collecting and in what format.

-It would be for the actual launch times, not planned launch times?
-Should the MCT be the very initial version for a mission, so without any Time of Ignition values already fixed?! Or should it come with two MCTs, one version that has already done some work on fixing the lighting and TI DVZ etc; I believe this was partially done before launch already in reality. But this modified MCT might then not be generally applicable; it might only be correct for one specific launch time and target vehicle state vector and if we ever update that then this second MCT is already not general enough anymore.
-Non-spherical gravity assumed to be enabled?
-Assumed launch time in UTC or TDB?
-Additional data to collect would be: Target state vectors for T-9min and T-31sec that go together with the FDO MFD data? Also, a bunch of basic notes on how the MCT should be changed from maneuver to maneuver on this specific mission.

A bunch of decisions like that to do before a project like this would be started, otherwise it becomes a bit of a mess. It would probably also make sense to start with STS-135 and work backwards. The FDO Console Handbook that we have access to (which is really the better guide than what I wrote in the FDO MFD manual) was written with the procedures of the last few missions in mind. As I had to experience when trying to figure out some of the earliest Shuttle rendezvous together with @Tiny_Bob , there were quite a few differences in procedures and FDO techniques compared to what we can read in the FDO Console Handbook from the 2000s.

 

[GLS]

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.

So, this took a while to look over... I'm critiquing AI and I'll be honest, so I guess I'm toast when it takes over.

Let's start with the bad.
Some stuff is, IMO, implemented in a way that is not "sustainable" e.g., modules with PASS and BFS code? Nop, way too messy. If tomorrow I want to implement different versions of the PASS, then it becomes impossible to handle, even for AI.
Another good one is adding the sWriteInhibit switch in the DiscOutPorts for bus masking, instead if doing the actual masking in the GPC...

(not bad, just lack of context) Everything display-related is pretty much ancient history now, same for interfacing program modules with FindSoftware(), as those areas moved forward quite a bit in the GPC_IDP_interface branch.
Related, the number of STS() and CreateBundle() calls in the GPC software should be going down, not up. Any new stuff needs to to have its I/O via the buses and not those less-than-ideal implementations.

Overall, I think the big issue is that it builds on things that aren't right (but/because it doesn't know), so the result is not as organized as it could/should be (yeah, I could also comment more ). It also seems oriented to make features, and not replicate the inner workings of something. While this might not matter or even be good (because it will use less resources) when the internals of something don't matter, but it is, for the most part, bad in the context of this project.




Now the good/not so bad.
I am very interested in moving more I/O to the MDMs, so I was really looking forward to what was done in this area. The almighty AI turned the 16-port IOM AOD card into 19 ports, which is not "NASA approved", and then wired the signals to the wrong channels... I want this, but it must be made properly.

Given the context of the work done, having a better I/O on the Aerosurfaces, NWS and ATVC commands and positions is probably within reach (OMS and RCS are already being handled, and I'm currently fixing my past errors in commanding MPS valves, that won't work with the new architecture).
The ASA and ATVC boxes are needed (all of them), and they would (for now) just be the interface between the MDMs and the actuators, which are (for now) contained in the AeroSurface and MPS_TVC classes. An ATVC exists already, which provides a rough template of the target. 4 of those are now needed, and the command signal mixing moved to the MPS_TVC.
We should leave the dP, actuator bypass and override business for later. Only the hardware part would be needed, and the software should just have the I/O switched from DiscreteBundle to MDMs.

A PR with this work would have to be for the v2 branch, where I have the new MDMs, which create the signal bundles with standard names, so one just needs to have the subsystem connect to the right signals.


First I need to finish my current DPS work, but after that I could take a bare-bones BFS that just listens to the busses, and extracts data for display in DISP 18 and also for the APU/HYD quantities. I don't think there is much info on the internals of the BFS, so this could be a good use for our future overlords.


Bonus quick update! I've done lots of touch up work on most GNC modules, and am now moving the commanding of the MPS valves to the MDMs as that was too wrong to continue as it was. The entry and landing are back to a working condition, and the 304->305 transition now happens via a control segment event, as I'm 99.9% sure it did. The ascent still needs the current MPS valve work, plus some rework of the LPS interface hacks. The orbit part I might leave only half-functional for now, as that is the work area of the OMS/RCS branch.
I've also been working the aft floor panels for the PRSD switches... 2 down, 174 to go... ok, its only actually like 10 to go.

 

[Tim13]

As it turns out, when trying to implement a tool faithfully that the real Shuttle FDOs used, what we ended up with is something that requires a level of orbital mechanics knowledge of a real Shuttle FDO

I laughed out loud...literally...when I read this. That's pretty much how I feel about it.

But I have also been thinking about this topic. We should really start a collection of mission specific data for the FDO MFD. It's not just difficult to come up with a Maneuver Constraints Table for a new mission, it's also work intensive enough that it would be a shame if this is something multiple people start doing for the same mission. What I have been struggling with is establishing some "guidelines" for this. Like, what data would we actually be collecting and in what format.

-It would be for the actual launch times, not planned launch times?
-Should the MCT be the very initial version for a mission, so without any Time of Ignition values already fixed?! Or should it come with two MCTs, one version that has already done some work on fixing the lighting and TI DVZ etc; I believe this was partially done before launch already in reality. But this modified MCT might then not be generally applicable; it might only be correct for one specific launch time and target vehicle state vector and if we ever update that then this second MCT is already not general enough anymore.
-Non-spherical gravity assumed to be enabled?
-Assumed launch time in UTC or TDB?
-Additional data to collect would be: Target state vectors for T-9min and T-31sec that go together with the FDO MFD data? Also, a bunch of basic notes on how the MCT should be changed from maneuver to maneuver on this specific mission.

Yeah, lots of possibilities. Just with my very rudimentary knowledge, I'd think actual launch time to take advantage of historic TLE's.

Good question about the MCT. In a perfect world, both missions would be included. A version with some work done already, to show the basic flight plan for the mission and ensure success, and an initial version with no TIG's, but all the required maneuvers in the MCT, to give more to do for the mission.

Non-spherical gravity seems to work fine, and would IMO be a nice touch...as real as it gets so to speak.

Launch time UTC/TDB. I don't know enough about the advantages or pitfalls of both, so I'd have no opine on that.

The last part about time, I might even go further back than T-9min, maybe T-3:00 hours to give people the option to run the ingress/handover checklists, or to just time accelerate closer to T-9min.

Now basic notes, I've got..... Part of my job requires publishing notes in official documents. It's a passion of mine to write my notes in a way that anyone can come behind me, and know without question what each sentence or phrase is referencing. I have this weird obsession about technical writing, and how to make it accessible and understandable to a new, or inexperienced reader.

A bunch of decisions like that to do before a project like this would be started, otherwise it becomes a bit of a mess. It would probably also make sense to start with STS-135 and work backwards. The FDO Console Handbook that we have access to (which is really the better guide than what I wrote in the FDO MFD manual) was written with the procedures of the last few missions in mind. As I had to experience when trying to figure out some of the earliest Shuttle rendezvous together with @Tiny_Bob , there were quite a few differences in procedures and FDO techniques compared to what we can read in the FDO Console Handbook from the 2000s.

I think the space shuttle is such a loved classic piece of hardware, that many people want to fly it in the sim. I'd love to lower the bar, and give the most people the best chance to be successful flying the ISS, MIR, and HST rendezvous missions with the SSV. Working through the burns and maneuvers using the onboard systems, instead of the "cheater" way with the OG shuttle fleet, is so enjoyable, and so satisfying, it's hard to put in nerd words. Because of the inherent complexity of what this is simulating, I think mimicking NASA's process of heavy pre-planning is the way to go, and creating a "launch package" for each of these rendezvous missions that is repeatable with high confidence, would be a good step to opening up this absolutely amazing combination of SSV+FDO to a wider audience.

 

[GLS]

Launch time UTC/TDB. I don't know enough about the advantages or pitfalls of both, so I'd have no opine on that.

Well, Orbiter uses TDB because of the orbital mechanics and that is not going to change. We got used to treating what is displayed as UTC/GMT, but when we go deeper, there is an ~84s difference, and that makes a difference.
I'm thinking the best solution is to isolate the time in SSV from Orbiter, and just use it for the time increments, and keep time internaly as GMT. Users would have to look at the GPC display or the clock on panels O3 or A4 to get the actual GMT, and not the time Orbiter display.

The last part about time, I might even go further back than T-9min, maybe T-3:00 hours to give people the option to run the ingress/handover checklists, or to just time accelerate closer to T-9min.

That needs work, both on the ground side to manage the countdown, and also in the GPCs (which should be easier now), but I want to handle those together with the ascent and aborts for v3.0.

 

[indy91]

Well, Orbiter uses TDB because of the orbital mechanics and that is not going to change. We got used to treating what is displayed as UTC/GMT, but when we go deeper, there is an ~84s difference, and that makes a difference.
I'm thinking the best solution is to isolate the time in SSV from Orbiter, and just use it for the time increments, and keep time internaly as GMT. Users would have to look at the GPC display or the clock on panels O3 or A4 to get the actual GMT, and not the time Orbiter display.

Should be easy to add this to the FDO MFD. A mission specific constant that can be set on the config page. Just like the 64.18 value in this real screen from the FDO Console Handbook:



We would keep using zero for this value until SSV has been changed in the same way.

 

[GLS]

Should be easy to add this to the FDO MFD. A mission specific constant that can be set on the config page. Just like the 64.18 value in this real screen from the FDO Console Handbook:

View attachment 49391

We would keep using zero for this value until SSV has been changed in the same way.

The offset would be calculated in the Mission Editor when the user defines the T0 (in GMT), and from that I can work what MJD that is for the scenario, based on the leap seconds table. The resulting offset can easily be shown in there, so it can be used in FDO MFD if needed.