Project Space Shuttle Vessel

[DaveS]

They still can be obtained through the Internet Archive's capture of the page: https://web.archive.org/web/2017060...nters/johnson/news/flightdatafiles/index.html

 

[EstebanDF]

Many documents here:

Índice - InfoSondas

Infosondas.com es un proyecto de PedroLeon.info y SondasEspaciales.com, dedicado a la recopilación de documentos sobre sondas espaciales, cohetes, satélites, vuelo tripulado y cualquier cosa que huela al espacio. Dado el gran tamaño de los archivos, los hemos ... Leer más

www.infosondas.com

This website is in spanish, and you'll probably need to get an account to use the "box" plugin (It's free), but once you're there:

For Space Shuttle, on the scond box called "InfoSondas.com - 2" go to:

"Vuelo Tripulado" -> "Space Shuttle"


Regards.

 

[goForTLI]

Alright guys.

I'm using the scenario editor to calculate my OMS-1 and OMS-2 burns, however I'm getting a very large DV and my final orbit is not the one I planned (160x160 nm), and I'm also getting assistance from the OMS (I believe this started to be used from STS 90 and not STS 5 LOL)

Any idea what I'm doing wrong ?

 

[GLS]

Wow! How did you get into that orbit at MECO? I know the AscentDAP is "limited", but that seems way off. That completely messes up your OMS-1, and then you might even not have enough prop for the OMS-2, let alone the rest of the mission.
For the OMS Assist and SSME Throttles? (and maybe fix the above), here are some better settings (from STS-3) for the I-Loads tab (sorry, still no "nice" UI to change these settings):


Looking further at the OMS-2 target orbit, it doesn't match what is in the Mission Editor... did you hit the Save button after Calculate?

 

[goForTLI]

Looking further at the OMS-2 target orbit, it doesn't match what is in the Mission Editor... did you hit the Save button after Calculate?

Yes I did this several times.

Wow! How did you get into that orbit at MECO?

It's a good question, basically I used the mission editor and saved the OMS-1 and OMS-2 data as per the photo I sent you, and I don't understand why I'm getting this orbit.

Remembering that I used the STS-1 mission file as a base, the only thing I changed was the orbit inclination and the value of OMS1 and OMS-2 target to 160 nm.

 

[GLS]

Looks like you are using D3D9, so the frame rate should be decent... the lower it is, the worst the AscentDAP will perform... I'll launch it to see what I get.

Anyway, one thing to be noted is that the PEG-4 targets aren't perfect, as they don't take into account orbit perturbations, so even with perfect burns the targets will likely be missed by a few NMs, but it should not be anywhere near 50NM like in the images above.
The credit for figuring all of this out, and working the math for the Ascent Target calculator, goes to @indy91.

I used the STS-1 mission file as a base

So you shouldn't have the OMS Assist (OMSASS = 1 = on, 0 = off)

 

[goForTLI]

Looks like you are using D3D9, so the frame rate should be decent... the lower it is, the worst the AscentDAP will perform... I'll launch it to see what I get.

Anyway, one thing to be noted is that the PEG-4 targets aren't perfect, as they don't take into account orbit perturbations, so even with perfect burns the targets will likely be missed by a few NMs, but it should not be anywhere near 50NM like in the images above.
The credit for figuring all of this out, and working the math for the Ascent Target calculator, goes to @indy91.



So you shouldn't have the OMS Assist (OMSASS = 1 = on, 0 = off)

I'm getting better results with PEG-7, despite having very little time to load data from OMS-1, it's an alternative that works at the moment.

 

[indy91]

The result looks a bit strange. It seems like the OMS-1 PEG-4 target transferred properly to I-load, but not the insertion targets or the OMS-2 PEG-4 targets. The OMS-2 PEG-4 values are the default ones, maybe that insertion orbit is, too, looks a lot like a direct insertion for a ground-up rendezvous. I replicated all the inputs that @goForTLI did and at least I see that the OMS-1 and OMS-2 I-load show the correct height target (PEG-4 HT) of 160 NM. So I am not really sure how this would happen.

Anyway, one thing to be noted is that the PEG-4 targets aren't perfect, as they don't take into account orbit perturbations, so even with perfect burns the targets will likely be missed by a few NMs, but it should not be anywhere near 50NM like in the images above.

Yeah there is a bit more to do there for non-spherical gravity. I'll get to it eventually. It should be at most a 8 NM error in target altitude right now.

 

[GLS]

I still haven't had time yet to run that launch.... maybe later today.

Yeah there is a bit more to do there for non-spherical gravity. I'll get to it eventually. It should be at most a 8 NM error in target altitude right now.

I'm not complaining in any way, I think it works very well, especially compared with the pre-MECO side. Again, thanks!

 

[GLS]

Finally ran those ascent targets and it seems ok on my end:
state ap/pe PEG-4
-------------------------------------
post MECO 78/+4
tgt OMS-1 155/+51 0/0/160/166
post OMS-1 155/+51
tgt OMS-2 156/+154 0/0/160/346
post OMS-2 156/+154

@goForTLI , it seems like you didn't hit the Save button after changing the parameters and/or didn't re-save the mission and, like @indy91 noted, end up with the default DI OMS targets.

Just to clarify: the Save button in the Ascent tab just transfers the calculated Ascent Targets to the I-Loads (OMS burn data) and the Legacy MECO parameters (the current implementation of the MECO targets). It doesn't actually save the mission, so changing those parameters on an existing mission, still requires the user to re-save the mission, just like if any other parameter was changed.

The user can bypass the Ascent Target calcs, and just input the OMS burn I-loads and (legacy) MECO parameters directly.... but why would anybody do that when there is this powerful tool just a few clicks away?

 

[goForTLI]

STS-41G

 

[GLS]

Another quick update!
Progress continues to be made in the display rework, with more and more parts being completed. Managed to hack a calculation of the inertial and relative velocity heading, to feed the HSI during launch, and it is neat to see the inertial velocity being "pulled" in the desired direction as the ascent progresses, something that is very visible in a high-inclination KSC launch or VAFB launch.


On the OMS/RCS side, lots of work in modules that control the interconnects and dumps. Even though the abort interconnects and dumps will not be available until aborts are implemented, having all those modules now allows me to test (via "hacking") what the OMS/RCS will have to do, in the hopes those subsystems end up capable of all that is needed. Still trying to figure out the logic to ignite the OMS, as that was handled by the MSC module, of which there isn't much info out there.


Meanwhile I've opened up a new front of development: MDM improvement. State load/save capability (so the MDM outputs are correct at the start of the sim) is the immediate objective, but I'm also correcting the I/O voltage levels, so the ever-growing signals that pass there can have the correct numbers, thus avoiding (more) problems in the future. Another objective is having the IOMs create the needed Discrete Bundles, and having the subsystems connect where they need, as opposed to having to invent more and more names for Discrete Bundles, and then having to edit the MDMs to connect new signals. This way, any new signals only require work in the subsystem (and GPC software of course). There is another MDM-related issue, this time on the GPC software, where the outputs are reset after being sent to the MDM... an assumption I made a while back that turned out to be wrong. Anyway, not sure I'll fix it in this branch, as the work above is already considerable. Also, no PROMs yet, so I/O will remain 1 word per transaction, but this new setup should make that easier.


All this will soon slow down to provide time for the v1.8 dev, a release to bridge the gap to v2.0. As promised, I'll look at improving the docking, and regardless of the success of that there are other (smaller) items that will see the light of day.

 

[Marg]

Is there only one RMS camera now (on CCTV)? because end effector's camera could be more useful than elbow's, to see grappling alignment. Also what is grappling procedure, I still tap there and there, but not sure how exactly it works (so far), I use PFTA (forward grapple) in STS-8, with latest 1.7 SSV. (BTW where is R14 panel, mentioned earlier, with CCTV switches).

 

[GLS]

Is there only one RMS camera now (on CCTV)? because end effector's camera could be more useful than elbow's, to see grappling alignment. Also what is grappling procedure, I still tap there and there, but not sure how exactly it works (so far), I use PFTA (forward grapple) in STS-8, with latest 1.7 SSV. (BTW where is R14 panel, mentioned earlier, with CCTV switches).

So, there is only one input* for RMS cameras, but (obviously) 2 cameras in the RMS, and they way this was handled was with the "Port RMS Camera" switch on panel A7U, choosing which camera was being used.
While we are one this, originally only 3 inputs were allocated for PLB cameras and 1 more for each RMS (the flown Port and the never-flown Starboard). Early on they realized that having 4 PLB cameras was very useful, so they started using the Starboard RMS input for a 4th PLB camera, and never looked back.

On the PFTA, what I usually do is take it out of the PLB with one GF, release it, quickly move the EE to the other GF and then bring it back in.
Using the forward GF, first get the correct EE attitude, which should be all 3 angles near 0, then align it with the GF using the EE camera, then just move in and using the Elbow camera check the pin is mostly in the EE.
With the End Effector Mode switch on panel A8U in Auto, just press Ctrl+Enter to grapple and Crtl+Backspace to release.
After grapple, release the PRLAs and translate up and it should come out. Opposite actions to stow.

*) don't blame me, that is the way it was

 

[Marg]

hi, I cannot open payload bay doors, hm, what can that be. I tried it the old fashioned way (R13 panel switches), is computer compulsary now?
And how it was in real life (earlier missions old way, and latest - through computer?)
Actually I had another question before this: I just looked at 51-G mission - there were 3 PAM-D + satellites, and fourth active payload is SPARTAN. but seems only 3 active payloads are supported (as suggested by A6U "rotary" payload latch switch "1-MONITOR-2-MONITOR-3").
P.S. I even imagined optional "scenario" exporter, where shuttle is in "OPF" type position with open payload bay, otherwise it is hard to check payload position. Actually it is how it started, launched, quickly to orbit, and wanted to open PB to see what is right or wrong with payloads...

 

[DaveS]

hi, I cannot open payload bay doors, hm, what can that be. I tried it the old fashioned way (R13 panel switches), is computer compulsary now?
And how it was in real life (earlier missions old way, and latest - through computer?)
Actually I had another question before this: I just looked at 51-G mission - there were 3 PAM-D + satellites, and fourth active payload is SPARTAN. but seems only 3 active payloads are supported (as suggested by A6U "rotary" payload latch switch "1-MONITOR-2-MONITOR-3").
P.S. I even imagined optional "scenario" exporter, where shuttle is in "OPF" type position with open payload bay, otherwise it is hard to check payload position. Actually it is how it started, launched, quickly to orbit, and wanted to open PB to see what is right or wrong with payloads...

Yes, following the actual procedures in the Post-Insertion/Generic De-Orbit Prep FDFs for the PLBDs are now required. OPS 202 PRO on CRT4 in SM mode to load the PL BAY DOORS software and then ITEM 1 EXEC to enable enable AC power to the MMCAs that control the door actuators and then ITEM 3 EXEC to enable AUTO MODE. Then two PL BAY DR SYS switches on R13L to ENA. Then PL BAY DR switch to OPEN until TB "OP". Then PL BAY DR to STOP, followed by the two PL BAY DR SYS to DSBL. Then on CRT4, ITEM 2 EXEC to disable AC power again and then OPS 201 PRO to mode back to SM 201 ANTENNA for further on-orbit ops.

 

[Marg]

Yes, following the actual procedures in the Post-Insertion/Generic De-Orbit Prep FDFs for the PLBDs are now required. OPS 202 PRO on CRT4 in SM mode to load the PL BAY DOORS software and then ITEM 1 EXEC to enable enable AC power to the MMCAs that control the door actuators and then ITEM 3 EXEC to enable AUTO MODE. Then two PL BAY DR SYS switches on R13L to ENA. Then PL BAY DR switch to OPEN until TB "OP". Then PL BAY DR to STOP, followed by the two PL BAY DR SYS to DSBL. Then on CRT4, ITEM 2 EXEC to disable AC power again and then OPS 201 PRO to mode back to SM 201 ANTENNA for further on-orbit ops.

Thanks, I suspected it's somewhere in MM202, but what is "in SM mode"?

 

[GLS]

Actually I had another question before this: I just looked at 51-G mission - there were 3 PAM-D + satellites, and fourth active payload is SPARTAN. but seems only 3 active payloads are supported (as suggested by A6U "rotary" payload latch switch "1-MONITOR-2-MONITOR-3").

So, eventually the PAMs will be implemented in SSV (I actually have some things already), and they will talk to the GPCs, and it will be possible to have 3 in a mission (still don't know if that was the actual limit or just what happened to be the maximum flown in the 80s). For now, they will have to be implemented as custom vessels attached to the PLB, and the user will have to control them somehow. As ASEs aren't deployed, they could/should be considered "Passive Payloads".
The "Active Payloads" are the ones that are deployed and/or retrieved, directly from the PLB, with the RMS. Although there were a few "hacks" along the way, 5 should be the maximum number of such payloads, as there are 15 latches and each payloads needs at least 3 of them, so 15 / 3 = 5 payloads. Most payloads actually need 5 latches, so that gives 3 much payloads, and that is why the switch has 3 positions.

P.S. I even imagined optional "scenario" exporter, where shuttle is in "OPF" type position with open payload bay, otherwise it is hard to check payload position. Actually it is how it started, launched, quickly to orbit, and wanted to open PB to see what is right or wrong with payloads...

It is a problem I recognized long ago, but short of implementing Orbiter inside Mission Editor, things have to be checked in Orbiter itself. I don't know the mass, size, orientation, configurations, etc of the payloads, so there isn't much I can do in Mission Editor. This OPF ideia might be interesting....

Thanks, I suspected it's somewhere in MM202, but what is "in SM mode"?

Next to the keyboard there is a Major Function switch, which controls which display is shown in the CRT/MDU.

 

[Urwumpe]

I think the OPF version is really the best solution to test and change a payload setup, since it couldn't introduce any interface incompatibilities, e.g. a mission editor using a different definition of the attachment point positions. Also, new features in SSV would be instantly available for testing in the OPF, so it also supports agile development.

Of course, a simplified 2D drawing board could also do it, especially for the COG calculations. But then the add-ons would need to be simple enough or interact with the payload editor or provide an low poly "engineering" mesh. Maybe allow a simple "doll house view", where you look on the payload bay from above and can just fit the coarse shape on the payload load bay shape and then refine COG position and other payload factors - maybe with a faux batch mode calculation like in the old days until you see the printout of the system 390 calculations.

 

[GLS]

Of course, a simplified 2D drawing board could also do it, especially for the COG calculations. But then the add-ons would need to be simple enough or interact with the payload editor or provide an low poly "engineering" mesh. Maybe allow a simple "doll house view", where you look on the payload bay from above and can just fit the coarse shape on the payload load bay shape and then refine COG position and other payload factors

I thought of drawing lines connecting the trunnions in the payload diagram, to help visualize the payload volume, but there is no way of knowing what the payload mesh is, with what offset is was loaded, or what animations it has to fold things. Same goes for the mass and c.g., which will be more important in the future.

The OPF idea is looking better and better by the minute, and I have some early ideas about what it will look like... but it still needs polishing.