SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.
A MFD would be one option there, but I would prefer using a more integrated solution there, having a MCC building-vessel that can read the mission files as well, has its own knowledge of the mission state and communicates with the player via message lines on the screen and executive packages. In C++ of course. The MFD would break immersion a bit there, and would have some UI limitations. Having a dedicated MCC vessel would allow using a bigger UI and allow more functions. For example, using the sleep phase in a flight plan for preparing the next flight day manually (instead of making too much automatic)

Yeah, that is similar how we simulate MCC-H in NASSP, which supports full missions and you don't need to use any MFD anymore, if you use that feature. Right now the MCC runs in the CSM and we only support Apollo 7+8. But once the LM will get involved, which needs its own calculations, uplinks etc. we will have to create such a MCC building vessel, too. I have always first tested the MCC-H calculations in my RTCC MFD, which gets released with NASSP, and then once they are working without problems have given MCC-H the ability to calculate the same things without user input. For SSU this could of course be combined into a MCC vessel that allows user interaction.
 
For SSU this could of course be combined into a MCC vessel that allows user interaction.

Well, theoretically, it should be possible to at least write a base mission control building class there. The problem is that NASSP and SSU have likely different communication protocols (I would use clbkGeneric for this to be a bit flexible), so reusing the same base for multiple specific mission control building-vessels (eg. 1960s UI vs 1990s UI) is not really easily.

Same for mission definitions. Writing the procedures and flight rules in a format that could be customized for Shuttle or Apollo should be the easy one though. After all, NASA is NASA and CAPCOM is still CAPCOM.
 
I rather meant that the concept of a Testing MFD + MCC-H feature without user interface could be combined into a MCC vessel for SSU that allows user interaction. I don't think it would be useful to use the NASSP MCC code for SSU. You can create your own MCC and then I plant my rendezvous calculations, some of it reused from NASSP, in it. That would work the best, I think.
 
I rather meant that the concept of a Testing MFD + MCC-H feature without user interface could be combined into a MCC vessel for SSU that allows user interaction. I don't think it would be useful to use the NASSP MCC code for SSU. You can create your own MCC and then I plant my rendezvous calculations, some of it reused from NASSP, in it. That would work the best, I think.

Well, I still have doubts about a fully automatic MCC being possible. I think some decisions will still need a player. Especially if there are significant deviations from the planned flight path.
 
Well, I still have doubts about a fully automatic MCC being possible. I think some decisions will still need a player. Especially if there are significant deviations from the planned flight path.

For sure. There has to be an initial guess for the time of the TI maneuver, for example. Or at least the user has to decide if it's going to be a FD3 or FD4 rendezvous. That also depends on the phase angle at insertion, of course. There are some other parameters that could theoretically be loaded in a mission file, like an initial guess for the number of revolutions between phasing maneuvers. Each Shuttle mission deviated a little bit with their rendezvous profile. Sometimes they had a NH maneuver before the NC4 maneuver etc. So it's hard to find 100% objective criteria that are applicable to each flight, even each flight to the ISS. We'll see. I haven't really done a lot of research for the Shuttle, most of my information are from a document called History of Space Shuttle Rendezvous.

It's the same for Apollo missions. For a mission like Apollo 7 that just coasts around in Earth orbit for 260 hours it is hard to predict exactly where the CSM will be at the end of the flight. Usually there is an about 30 minute deviation from the historical deorbit time and the time calculated by our tools. Apollo 8 on the other hand is easy to automate, at least the nominal mission. It arrives at the Moon at a specific time and most events are relative to the time of TLI, LOI, TEI or Entry Interface. But a Shuttle mission is certainly more like Apollo 7.
 
Well, the different mission profiles is one issue there, another is that we have much more different configurations of a spacecraft here. Also, for the ISS, the Shuttle profile assumes a specific ISS configuration for each mission and the joint-operations are not easy as well. A rendezvous like for Hubble is much easier.
 
Well, the different mission profiles is one issue there, another is that we have much more different configurations of a spacecraft here. Also, for the ISS, the Shuttle profile assumes a specific ISS configuration for each mission and the joint-operations are not easy as well. A rendezvous like for Hubble is much easier.

Yes, but how much of an effect does this have on the location and timing of the TI maneuver? The terminal rendezvous phase could differ between the normal ISS missions to Hubble, MIR or even early ISS, but for the most part the ground targeted phase is the same. A bunch of NC maneuvers, sometimes NH or NPC maneuvers and between the last NC maneuver and the TI maneuver some missions had 2 instead of 1 revolution. What I plan to do will set up the TI maneuver at the right place at the right time. Even for Hubble missions that seems to have been 36 minutes before sunset.

nDbTMSY.png


Here is the profile I would work on at first. Anything earlier missions did or some specific missions with more complicated procedures like STS-39 could follow later.

The user inputs and calculations for this profile would be:

-Revolutions between OMS2 and NC1. Sometimes that would be 1.5, in this picture 2 revolutions. This could probably change in the iteration if the phase angle is already small, then NC1 should happen at the apogee (relative to the target).
-NC2 happens X revolutions after NC1, is a small correction to NC1 and maybe sets up the NPC maneuver at a node. Not sure, looks like NPC doesn't happen at X or X.5 revolutions after NC2.
-NPC happens at a node, maybe a few revolutions after NC2, if necessary. Seems to be about half way between NC2 and NC3.
-NC3 is the second major phasing maneuver. The combination of NC1 and NC3 sets up the timing for TI. A user input would be the revolutions between NC1 and NC3, 9.5 in this case. But this can change in the iteration if the TI timing doesn't work out with that number.
-NH is a small correction like NC2 so that NC4 happens at the correct relative DH on the R-Bar.
-NC4 sets up the TI maneuver at the correct relative position to the target. Usually 1 sometimes 2 revolutions between NC4 and TI.
-NCC is onboard targeted. But there is also a ground solution which has to be calculated. No problem to calculate that, even the Lambert MFD I published on Orbithangar can do that.
-The other maneuvers are all targeted onboard and a ground solution would be calculated as appropiate.

I realize this is the standard profile which was often deviated from, but this should basically be valid for Hubble, MIR and ISS.
 
Last edited:
I think we need to do some changes in the creation of panels and subsystems to deal with the differences in subsystems and panels between the OVs. Currently most "stuff" is created in the constructor, way before we read the mission file, which limits customization "per mission" and/or "per vehicle".
Should we move all the subsystem and panel creation to a function and call it immediately after we load the mission file data? That way we could give subsystems the correct info from the start or load the correct panels.
 
I think we need to do some changes in the creation of panels and subsystems to deal with the differences in subsystems and panels between the OVs. Currently most "stuff" is created in the constructor, way before we read the mission file, which limits customization "per mission" and/or "per vehicle".
Should we move all the subsystem and panel creation to a function and call it immediately after we load the mission file data? That way we could give subsystems the correct info from the start or load the correct panels.

Yes.

And maybe, we should create a factory class for handling that, so the Atlantis class gets some diet.

My biggest problem there right now - I still need to get a good lifecycle state machine there for the subsystems. Theoretically, every subsystem we have can be removed and installed again (repair use case)
 
GLS , in video STS-1 say SSME ignite in T-4 second but in STS-1 scenario SSME ignite is T-6 second
 
GLS , in video STS-1 say SSME ignite in T-4 second but in STS-1 scenario SSME ignite is T-6 second



It's the same relative time to lift-off. For STS-1 lift-off occurred at T+2 seconds. Everything was shifted 6 seconds earlier for STS-2 and subsequent flights. Alot was different for STS-1 when compared to STS-2 and later countdowns. It was all a learning experience as they've never done a countdown before. They learned alot from STS-1.
 
GLS , in video STS-1 say SSME ignite in T-4 second but in STS-1 scenario SSME ignite is T-6 second

It's the same relative time to lift-off. For STS-1 lift-off occurred at T+2 seconds. Everything was shifted 6 seconds earlier for STS-2 and subsequent flights. Alot was different for STS-1 when compared to STS-2 and later countdowns. It was all a learning experience as they've never done a countdown before. They learned alot from STS-1.

As far as I know, initially they wanted T0 +/- around the time the SSMEs got to 90% to minimize the ET propellant "waste" prior to liftoff (i.e. more up mass). But when they did the FRF in February they found that the twang was much more pronounced than expected, and the loads at T0 were too big.
So, to not have to change the countdown less than 2 months before the launch, they added 2.77 seconds (if I remember well) between T0 and SRB ignition. For STS-2 the countdown was "corrected" to what we know today (but I think SSME ignition started at T-6.8s for early missions, instead of T-6.6).

EDIT: so to answer the question, yes we have it wrong... but then and again, we barely have a countdown... :(
 
Last edited:
As far as I know, initially they wanted T0 +/- around the time the SSMEs got to 90% to minimize the ET propellant "waste" prior to liftoff (i.e. more up mass). But when they did the FRF in February they found that the twang was much more pronounced than expected, and the loads at T0 were too big.
So, to not have to change the countdown less than 2 months before the launch, they added 2.77 seconds (if I remember well) between T0 and SRB ignition. For STS-2 the countdown was "corrected" to what we know today (but I think SSME ignition started at T-6.8s for early missions, instead of T-6.6).

EDIT: so to answer the question, yes we have it wrong... but then and again, we barely have a countdown... :(
Everything was shifted back 6 seconds for STS-2 Terminal Countdown (this is the period between T-9 minutes and counting and T0). For example, GO for autosequence start for STS-1 was at T-25 seconds, for STS-2 it had shifted back 6 seconds to the now familiar T-31 seconds.
 
Everything was shifted back 6 seconds for STS-2 Terminal Countdown (this is the period between T-9 minutes and counting and T0). For example, GO for autosequence start for STS-1 was at T-25 seconds, for STS-2 it had shifted back 6 seconds to the now familiar T-31 seconds.

SSME and SRB ignition weren't.
 
Urwumpe, are you doing the rotary switch corrections, or shall I do them?
Also, about the DSC and the sensors, what should the voltage range be for the sensors (assuming the will connect to the DSC via the discrete line class)? 1.5-3v? Custom?
Also, if the DSC range is 0-5v, how (and where) is OSH and OSL determined in the DSC/MDM/GPC data path?

I think I have the general PRSD architecture done (parameters for tank sets and pallets and EDO hardware) and am now "laying down the wiring" between the tanks and the panels (thus the questions above), and then only the thermodynamics will remain.
 
Urwumpe, are you doing the rotary switch corrections, or shall I do them?

If you can do them faster, do it, I'll ask you before I get into detailed coding again.

Right now, I want to prevent having to manually create Visual Studio 2015 (and later 2017) solution files. I need to update again, and I feel like this work won't stop soon... so I want to do a two step improvement there:


  1. We place the project files and compile in a different folder than the sources. (compile/msvc2015 for example)
  2. For myself and my laziness, I setup CMake to do the job of creating project files and folder structure for me. If nobody else wants to use CMake, nobody else should feel harm. I'll ask about committing the CMakeLists.txt files into our repository when its working 100%.

Also, about the DSC and the sensors, what should the voltage range be for the sensors (assuming the will connect to the DSC via the discrete line class)? 1.5-3v? Custom?

Rather custom. The input voltages for the sensors come from the DSC and are 0 to 17V AFAIR (have the printed diagrams in my apartment here in Cologne for reference). It depends on the sensor type and the converter card on the DSC.

Also, if the DSC range is 0-5v, how (and where) is OSH and OSL determined in the DSC/MDM/GPC data path?

Depends. For example, all that goes into the C&W system is directly from the DSC and you enter the data for the limits from 0 to 5V.

The MDMs convert quantities to 10 bit, but are not scaling the data (At least, it seems so). Most values that you get from the MDMs that are scaled, are read by serial IO or specialist cards (SIO for example connects the IMUs to the MDM)
 
Last edited:
If you can do them faster, do it, I'll ask you before I get into detailed coding again.
I'm just asking so we don't duplicate efforts.

Rather custom. The input voltages for the sensors come from the DSC and are 0 to 17V AFAIR (have the printed diagrams in my apartment here in Cologne for reference). It depends on the sensor type and the converter card on the DSC.
I think I'll leave the DSC for you... you seem to know more than me (I know 0 about the specifics of the shuttle DSCs), and I don't really want to steer away from the PRSD right now. I've already done a ValveManager to make valve management (time steps, scenario load/save) easier within subsystems, and that seems like a big enough "detour" right now.
 
I think I'll leave the DSC for you... you seem to know more than me (I know 0 about the specifics of the shuttle DSCs), and I don't really want to steer away from the PRSD right now. I've already done a ValveManager to make valve management (time steps, scenario load/save) easier within subsystems, and that seems like a big enough "detour" right now.

No problem, I'll include them soon. But GNC sensors first I think.
 
Just committed the "groundwork" for the PRSD! Currently it only adds mass (full tanks) as the thermodynamics will take time.

I updated the mission files with the new parameters for the SSU Workbench, and also for the PRSD tanks. The number of internal tanks can be set from 2 to 5. A parameter also exists to add the extra mass of the EDO stuff on OV-102 and 105, and then another to add the pallets.
I added the capability for OV-105 to have 2 EDO pallets installed and currently the pallet mesh is shown twice, but I'm sure the second pallet was going to be (somewhat) different as I think the fluid lines of both pallets go to the same place.

I also enabled the TAA in the STS-107 mission file, so the 107payloads mesh needs to be trimmed to remove the TAA from there. Also this could be a good time to correct the positions of the TAA, A/L and bulkhead hatch, as they don't match at the moment. Diagrams put the center of the hatches at Zo 357.9.

Also added the new rotary switch that can do multiple muxes, and got it working in panel O2.
 
Also added the new rotary switch that can do multiple muxes, and got it working in panel O2.

Did you use the suggestion of splitting contact rings from the switch?
 
Status
Not open for further replies.
Back
Top