Tiny_Bob
Addon Developer
indeed i do
Project Space Shuttle Vessel
- Thread starter GLS
- Start date
Tiny_Bob
Addon Developer
GLS
Well-known member
So I guess I should add a note about this in the manual...
Tim13
Active member
- Joined
- Apr 22, 2018
- Messages
- 155
- Reaction score
- 28
- Points
- 28
Quick question. I'm trying to find the launch window for STS-49, Endeavors first launch. I found that the window supposedly opened at 19:06 EDT, and the launch was delayed 34 minutes, with a lift off at 19:40 EDT.
I thought this was an instantaneous launch window, but maybe not?
Does anyone know the actual launch window? I have searched high and low, but no joy.
I thought this was an instantaneous launch window, but maybe not?
Does anyone know the actual launch window? I have searched high and low, but no joy.
Tim13
Active member
- Joined
- Apr 22, 2018
- Messages
- 155
- Reaction score
- 28
- Points
- 28
GLS
Well-known member
7 May: 7:06-7:52 pm EDT, and also 7:53-7:55 pm EDT (these final 3 minutes would probably target a rendezvous at a different time)
AFAIK the Shuttle never had instantaneous windows, as it could steer laterally going up hill (wait for the next SSV version...), so it could tolerate launching outside the in-plane time, but paying a performance penalty. For the ISS inclination it was about 5 minutes on either side of the in-plane time, for 28.45º it was (if I remember correctly) about 20-30 minutes on either side of the in-plane time.
Tiny_Bob
Addon Developer
For the ODS capture ring, where is the docking port location-wise on the ring (IE the mating face or somewhere else)? Using SSV with the most recent BetterISS version and the capture ring goes deep into the PMA before docking.
GLS
Well-known member
From the manual:
Could there be a mix-up with IDS ports (or whatever they are called... the new ports in-front of the PMAs)?
Tiny_Bob
Addon Developer
Tiny_Bob
Addon Developer
ive also started working some on this mission. i got a mission file all setup and i have started working on the payloads.
GLS
Well-known member
So, Spring update!
v2.0 status: well, first a bit of background to help understand why this is progressing so slowly. It might come as a surprise to some (it did to me), but the operating system of GPCs wasn't designed to fly and control the vehicle. It was designed for input/output, i.e., present displays and have the user interact with them via keyboard. And for that they invented the "control segment", which is a "special" program that calls a display up, and then just waits for user inputs. There are 2 types of control segments: OPS and SPEC, which are the 2 types of displays with user input (DISPs are display-only, I'm not sure if they existed from the beginning, or if they just added later as a cheap display without the need for a control segment program).
The control segments currently running are listed in an array with 5 entries called MACT (MCDS Applications Control Table, if I remember correctly). The first one is for the OPS 0 control segment, which always runs in the background, and calls for the GPC MEMORY display. The second one is used for the major function control segment (G1, G2, G3, S2...), and when it is running it "hides" the OPS 0 display. The last 3 MACTs are for the SPEC control segments, thus the PASS can only have 3 SPECs up at any given time. It seems there is also a limit of system SPECs in a common set, but I'm not there yet.
So, how do the GPCs control the vehicle? When the OPS control segments start, they launch another program (an executive), which then runs the tasks we usually associate with the GPCs. I'm not exactly sure how things run in the GNC side, just one executive, or 3, for tasks or just I/O, but the SM has an executive with a neat table of tasks, and it calls them in the prescribed order and rates.
The SPEC control segments also launch another program, which gathers and processes data which is then shown in the associated display. For example SPEC 23, has a program behind that calculates and writes the selected RCS pod data into variables which are then displayed (there is only screen space to show one pod at a time). When the user selects a different RCS pod, that program then switches to calculating and outputting the corresponding data.
When a SPEC is replaced with another, or "resumed", the control segment is terminated, and in the cleanup it requests the termination of the program it launched, thus freeing resources. For the OPS control segments things can be are a bit more complex, with Major Function overlays, data saving for the next OPS, etc.
Wanting to have this "back program" for SPEC 23, is how I got into this boat...
So now, the actual status update: after much hair pulling trying to understand things, in the last few weeks I got code running to start control segments, beginning with the OPS 0 control segment and the 2 system SPECs. The documentation of that logic that is far from perfect (i.e., some variables are set but never read, and others are read but never set, the text says one thing but the diagram shows another, typos everywhere
), and it describes the ALT system, which had a severe diet for the orbital flights, so even this "simple" version without the major functions, although still far from done and perfect, but already a good first win! I'm also able to show a DISP display, but I still can't resume to the display below. There are also questions to answer about display numbers: the documentation implies that "display 0" means "no display", and the OPS 0 control segment calls display 1 "GPC MEMORY"... but later they added a SPEC 1, and it would make sense for it to call display 1, but that is already taken... was the GPC MEMORY display relabeled "display 0", or does the DPS UTILITY display have another id? BTW: what exactly is shown at the top left of the displays: control segment id, display id, or something else? That is another example of variables that don't seem to be written anywhere . Maybe this display id thing is irrelevant as the user actually calls control segments and not displays, but it would be nice to settle these questions now to avoid re-labelling in the future.
There is still a bit of work to be done in describing the control segments, their internal flow, and especially the termination part, and also navigating the major modes in the OPS control segments (the mode is a subdivision inside the OPS control segment). My idea is to exercise as much of the control segment logic as I can with the system control segments, before introducing the major function stuff. Once this control segment business is working, I can plug-in the existing GNC and SM modules into the appropriate control segments, and we should be left with a better GPC software base, that should make it possible to have the Ku-band antenna controlled from the GNC GPC via the SM GPC, PAM and RMS controlled from the SM GPC.
For the next version, I've been thinking about my proposal to improve the payload attachment handling (https://www.orbiter-forum.com/threads/space-shuttle-vessel.37856/post-633617), and there is a fundamental flaw in it: the other parent must be attached to SSV. E.g., using the RMS to remove something out of a pallet in the PLB would work, very likely even with the SSRMS, but it would not work with the MMU+sat combo: the sat would be attached to one side only, and the other would still be free. I think the only way past these limitations is to improve the attachment logic in Orbiter to behave more like a "super-vessel", but allowing motion between the vessels, so RMSs and such can still work.
In better news, thanks to @indy91 the next version will have orbital plane targetting capability during ascent. There are a few limitations (missing good FCS, maintaining backwards compatibility), but one can now target a plane with VERY good results, leaving just a small correction to be made during rendezvous, resulting in a much cheaper OMS propellant bill. Also, "doglegs" like on STS-36 are now possible, but with a sharp performance drop. Going up hill, the inclination difference and distance to the target plane are shown on the A/E PFD.
Unless someone has an idea on how this attachment limitation could be overcome on the SSV side, I'll probably make a release sooner rather than later.
v2.0 status: well, first a bit of background to help understand why this is progressing so slowly. It might come as a surprise to some (it did to me), but the operating system of GPCs wasn't designed to fly and control the vehicle. It was designed for input/output, i.e., present displays and have the user interact with them via keyboard. And for that they invented the "control segment", which is a "special" program that calls a display up, and then just waits for user inputs. There are 2 types of control segments: OPS and SPEC, which are the 2 types of displays with user input (DISPs are display-only, I'm not sure if they existed from the beginning, or if they just added later as a cheap display without the need for a control segment program).
The control segments currently running are listed in an array with 5 entries called MACT (MCDS Applications Control Table, if I remember correctly). The first one is for the OPS 0 control segment, which always runs in the background, and calls for the GPC MEMORY display. The second one is used for the major function control segment (G1, G2, G3, S2...), and when it is running it "hides" the OPS 0 display. The last 3 MACTs are for the SPEC control segments, thus the PASS can only have 3 SPECs up at any given time. It seems there is also a limit of system SPECs in a common set, but I'm not there yet.
So, how do the GPCs control the vehicle? When the OPS control segments start, they launch another program (an executive), which then runs the tasks we usually associate with the GPCs. I'm not exactly sure how things run in the GNC side, just one executive, or 3, for tasks or just I/O, but the SM has an executive with a neat table of tasks, and it calls them in the prescribed order and rates.
The SPEC control segments also launch another program, which gathers and processes data which is then shown in the associated display. For example SPEC 23, has a program behind that calculates and writes the selected RCS pod data into variables which are then displayed (there is only screen space to show one pod at a time). When the user selects a different RCS pod, that program then switches to calculating and outputting the corresponding data.
When a SPEC is replaced with another, or "resumed", the control segment is terminated, and in the cleanup it requests the termination of the program it launched, thus freeing resources. For the OPS control segments things can be are a bit more complex, with Major Function overlays, data saving for the next OPS, etc.
Wanting to have this "back program" for SPEC 23, is how I got into this boat...
So now, the actual status update: after much hair pulling trying to understand things, in the last few weeks I got code running to start control segments, beginning with the OPS 0 control segment and the 2 system SPECs. The documentation of that logic that is far from perfect (i.e., some variables are set but never read, and others are read but never set, the text says one thing but the diagram shows another, typos everywhere
), and it describes the ALT system, which had a severe diet for the orbital flights, so even this "simple" version without the major functions, although still far from done and perfect, but already a good first win! I'm also able to show a DISP display, but I still can't resume to the display below. There are also questions to answer about display numbers: the documentation implies that "display 0" means "no display", and the OPS 0 control segment calls display 1 "GPC MEMORY"... but later they added a SPEC 1, and it would make sense for it to call display 1, but that is already taken... was the GPC MEMORY display relabeled "display 0", or does the DPS UTILITY display have another id? BTW: what exactly is shown at the top left of the displays: control segment id, display id, or something else? That is another example of variables that don't seem to be written anywhere . Maybe this display id thing is irrelevant as the user actually calls control segments and not displays, but it would be nice to settle these questions now to avoid re-labelling in the future.There is still a bit of work to be done in describing the control segments, their internal flow, and especially the termination part, and also navigating the major modes in the OPS control segments (the mode is a subdivision inside the OPS control segment). My idea is to exercise as much of the control segment logic as I can with the system control segments, before introducing the major function stuff. Once this control segment business is working, I can plug-in the existing GNC and SM modules into the appropriate control segments, and we should be left with a better GPC software base, that should make it possible to have the Ku-band antenna controlled from the GNC GPC via the SM GPC, PAM and RMS controlled from the SM GPC.
For the next version, I've been thinking about my proposal to improve the payload attachment handling (https://www.orbiter-forum.com/threads/space-shuttle-vessel.37856/post-633617), and there is a fundamental flaw in it: the other parent must be attached to SSV. E.g., using the RMS to remove something out of a pallet in the PLB would work, very likely even with the SSRMS, but it would not work with the MMU+sat combo: the sat would be attached to one side only, and the other would still be free. I think the only way past these limitations is to improve the attachment logic in Orbiter to behave more like a "super-vessel", but allowing motion between the vessels, so RMSs and such can still work.
In better news, thanks to @indy91 the next version will have orbital plane targetting capability during ascent. There are a few limitations (missing good FCS, maintaining backwards compatibility), but one can now target a plane with VERY good results, leaving just a small correction to be made during rendezvous, resulting in a much cheaper OMS propellant bill. Also, "doglegs" like on STS-36 are now possible, but with a sharp performance drop. Going up hill, the inclination difference and distance to the target plane are shown on the A/E PFD.
Unless someone has an idea on how this attachment limitation could be overcome on the SSV side, I'll probably make a release sooner rather than later.
Tiny_Bob
Addon Developer
Looking at the OI-7 CRT Reference Summary from '85, it has both SPECs and DISPs judging by the display identification (The XXXX/XXX/XXX line in the top left corner, not sure what it is actually called) having the spots for both SPECs and DISPs. OI-7 is the earliest we have that I can find.
GLS
Well-known member
Nah, when I said "from the begining" I meant the begining of the software development, in the early 70s. Enterprise had at least one DISP: 51, a.k.a. "FAULT", later changed to DISP 99.
Tiny_Bob
Addon Developer
GLS
Well-known member
Oh boy...
That is likely a custom mount, as it is not listed in the regular list, and actually does no align with the PLIDs. I have yet no idea how I would support that.
Tim13
Active member
- Joined
- Apr 22, 2018
- Messages
- 155
- Reaction score
- 28
- Points
- 28
Well.....I'm not actually working on a scenario. At the risk of sounding ancient, I've seen 4 shuttle launches in person total, but the Endeavour launch is the one that myself and my brother were lucky enough to get out to the non-VIP viewing area for, but was fuzzy on the timing of that launch. The more I thought about it, the more it was driving me up a wall when I couldn't find the details. I knew the launch was delayed, and it lifted off just before the close of the window, but just couldn't remember. My brother had a nice camera with him, and he's been looking for the pics he took that day.
Tim13
Active member
- Joined
- Apr 22, 2018
- Messages
- 155
- Reaction score
- 28
- Points
- 28
I'd like to set up a Orbiter 2024 instance with the bare minimum of addons, that will only run SSV and FDO MFD. Aside from the usual cloud texture upgrade, and surface texture upgrades, what else is needed? Do I need any addon KSC scenery? Is there a preferred ISS addon for SSV?
