Project Space Shuttle Vessel

[GLS]

So, the feature is still very basic and mostly hidden under the hood.

Hmm, basic... yes, under the hood... no, it currently gets the data from the PLB doors, runs the SSB module to generate commands to the MCAs and display data, so that part is very "advanced". The other SM parts (APU and WSB quantity calculations, parameter monitoring, RMS, antenna, upper stages) are not done yet. They were mostly possible before the v2 rework going on, but it should be easier with the new architecture.

Well, it would be nice if the key has a function, since it plays a major role in the first minutes after OMS-2.

To do what? There is only one GNC GPC. In the near term, only if the BFS is really needed (for SM during ascent and landing), will that key become useful.

I want to just mess with the PRSD right now, but I think, since a lot of thermodynamics is already done once by then, implementing a part of the ECLSS might be an low-hanging fruit. Creating a metabolic simulation of the crew could be another task then.

I think a "dummy" fuel cell, initially inside the PRSD, to use the reactants would be enough to exercise and validate the system.

I think the SM GPC gets most of the data from the active PCMMU and the OI subsystem. But don't ask me how in detail, its a subsystem almost completely hidden from the crew and with very little anomalies known, if any. There are five special IP buses, one for each GPC, that connect only to the two PCMMUs. Maybe its enough for the first shot at it to have a "dummy PCMMU" class that simply permits polling the needed data.

There is no PCMMU, and I don't have one planned for the near future. For now the IO MDMs are wired into one of the GPC busses (forgot which one), and the SM GPC talks directly to them.

 

[DaveS]

To do what? There is only one GNC GPC. In the near term, only if the BFS is really needed (for SM during ascent and landing), will that key become useful.

So no Post-Insertion CONFIG GPCs FOR OPS 2?

 

[dennis.krenz]

So no Post-Insertion CONFIG GPCs FOR OPS 2?

Yes, that is what I hoped for. After all, its the first memory config change in every flight. But its not the first time you have to skip a step in the checklist because its not yet implemented. Also, once this gets into implementing the EPS, there has to be at least separate consumers of electricity, even if the behavior on top "virtualizes" the hardware.

Also I am not sure if the R4 switches work or if there should be a master alarm if you shutdown the MPS after the venting is complete.

 

[DaveS]

Yes, that is what I hoped for. After all, its the first memory config change in every flight. But its not the first time you have to skip a step in the checklist because its not yet implemented. Also, once this gets into implementing the EPS, there has to be at least separate consumers of electricity, even if the behavior on top "virtualizes" the hardware.

Also I am not sure if the R4 switches work or if there should be a master alarm if you shutdown the MPS after the venting is complete.

I don't think there is as the checklists are very good at calling out when to expect MA's as part of the procedure (see MPS ISOL and APU/HYD SHUTDN in the Ascent checklist). And none of the R4 switches are implemented at all.

 

[GLS]

So no Post-Insertion CONFIG GPCs FOR OPS 2?

Yes, that is what I hoped for. After all, its the first memory config change in every flight. But its not the first time you have to skip a step in the checklist because its not yet implemented.

There are only 2 GPCs: 1 with GNC and 2 with SM, and that is fixed. This means some procedures don't work/aren't needed right now. The hardware and software aren't isolated enough yet to pick which MF to run, and if it were, I can't think of having a RS without heavily synchronized threads... and that means the GPCs would no longer be able to ask Orbiter for altitude, speed, etc, so they would need to do navigation for real, which means having IMU, AA, GPS/TACAN, MLS, etc, which isn't an easy or quick topic.
So the current path is to improve the software, by organizing (i.,e., correcting) the data flow between modules, and limit the "call Orbiter" cheats to the modules that produce the navigation data (ATT PROC, NAVDAD, etc), which should make it easier to introduce navigation later on. A good chunk of this is done, and will mean that v2.0 will have more and better data available. Later the cheats can be replaced with actual subsystem data + calculations, thus eventually isolating the GPCs from Orbiter. Then moving the GPCs to threads becomes easier (still need to handle time acceleration changes somehow), and then having a RS. At this point, replacing this "internal" GPC simulation with something external should be possible. There is a long way to go, but it is moving in that direction.
Like I mentioned previously, the only question mark for v2.0 is: SM during ascent and entry important enough to require making a simple BFS? I still don't have an answer to that, and probably won't have for sometime.
So I'm trying to open doors for the future, while keeping things progressing in the present. I understand the frustration of "bah, so it won't be 100% done yet", but this v2.0 work is already a huge step forward. E.g., the new data flow (plus new modules) allows the HSI will work as it should during entry/landing, controlled by the mode switch. It's only half done yet (and I'll probably only finish it in the oms/rcs branch), but ADI will have the 3 modes working. All trajectory displays will have I-Loads, so lots of lines, labels, scales will be configurable per mission (no automatic configuration yet though). Plus all the internal changes that will be invisible to the user, but will allow more features in the near term.

Also I am not sure if the R4 switches work or if there should be a master alarm if you shutdown the MPS after the venting is complete.

One thing needed for the PRSD is the hardware C&W, which is done. You just need to plug in the sensor data to the ports, feed them with the correct volts and you will get a MA when a parameter go out of the set limts, which are configurable on panel R13U.

 

[dennis.krenz]

There are only 2 GPCs: 1 with GNC and 2 with SM, and that is fixed. This means some procedures don't work/aren't needed right now. The hardware and software aren't isolated enough yet to pick which MF to run, and if it were, I can't think of having a RS without heavily synchronized threads... and that means the GPCs would no longer be able to ask Orbiter for altitude, speed, etc, so they would need to do navigation for real, which means having IMU, AA, GPS/TACAN, MLS, etc, which isn't an easy or quick topic.

In the "real one" there are synchronization calls in the software, so the identical software always waits at the same point to query the same data. So, if you look at the things top to bottom, it would be just like there is one software running on up to 4 computers. So, you could just make one software/memory configuration object and assign it to n GPCs, which by themselves do nothing at all except consuming electricity and produce heat. The tricky part would be the edge cases: What happens if you terminate a GPC with the switch on O6 from all buses, that controls one bus? If I am not mistaken, such a situation would result in a loss of data for all listening GPCs, since no GPC would assume automatic control until you edit the bus assignments in OPS/SPEC 0.

Also, could you make the default SM GPC by now GPC 3? It would feel more real since GPC 1 & 2 run GNC and 4 is freeze dried.

Like I mentioned previously, the only question mark for v2.0 is: SM during ascent and entry important enough to require making a simple BFS? I still don't have an answer to that, and probably won't have for sometime.

Right now... not really urgent. Not enough subsystems and no failures to require looking at it. But on the other hand: it would be really nice having it around when testing things and it adds to the realism of the simulation, since we could at least have the user interface operate right. Also it reads the parameters in a more direct in simpler way, without limit checking or similar features. With SM alone, I could "realistically" only expect to check the vitals of the PRDS in orbit, not during other phases, when only BFS is available to read at least a small subset of the SM data with the SYS SUMM pages. The GNC SYS SUMM display doesn't provide it.

But for testing things, there would also be many missing PASS displays high on our wishlist. Maybe not as high as the BFS though.

One alternative would be leaving the BFS for somebody else to make a PR for it. You could then limit yourself to controling things as skeptical maintainer and could maintain full sovereignty over your fork of SSU. (which wouldn't make sense to revive anyway at this point). You could then focus on your own priorities.

So I'm trying to open doors for the future, while keeping things progressing in the present. I understand the frustration of "bah, so it won't be 100% done yet", but this v2.0 work is already a huge step forward. E.g., the new data flow (plus new modules) allows the HSI will work as it should during entry/landing, controlled by the mode switch. It's only half done yet (and I'll probably only finish it in the oms/rcs branch), but ADI will have the 3 modes working. All trajectory displays will have I-Loads, so lots of lines, labels, scales will be configurable per mission (no automatic configuration yet though). Plus all the internal changes that will be invisible to the user, but will allow more features in the near term.

Could you add a "default I-Load" for the ANTENNA SPEC? right now it displays a blank rectangle where the limit envelope for the Ku band antenna should be. The "vertex" list for the polyline is documented somewhere.

 

[GLS]

In the "real one" there are synchronization calls in the software, so the identical software always waits at the same point to query the same data. So, if you look at the things top to bottom, it would be just like there is one software running on up to 4 computers. So, you could just make one software/memory configuration object and assign it to n GPCs, which by themselves do nothing at all except consuming electricity and produce heat.

I think that would end up too bloated with the handling of the 4-in-1 (plus all the failures one might think of).

The tricky part would be the edge cases: What happens if you terminate a GPC with the switch on O6 from all buses, that controls one bus? If I am not mistaken, such a situation would result in a loss of data for all listening GPCs, since no GPC would assume automatic control until you edit the bus assignments in OPS/SPEC 0.

Yep, but I'm not sure if the RS wouldn't take over DK-1 automatically. There is some provision for that at the start of the GPC... anyway, if a crew was stupid enough to do that, they would have have to go BFS.

Also, could you make the default SM GPC by now GPC 3? It would feel more real since GPC 1 & 2 run GNC and 4 is freeze dried.

The SM is 2 since it should up... why change now? I don't think that changing the number will make running 2 GPCs instead of 5 less of a hack.

Right now... not really urgent. Not enough subsystems and no failures to require looking at it. But on the other hand: it would be really nice having it around when testing things and it adds to the realism of the simulation, since we could at least have the user interface operate right. Also it reads the parameters in a more direct in simpler way, without limit checking or similar features. With SM alone, I could "realistically" only expect to check the vitals of the PRDS in orbit, not during other phases, when only BFS is available to read at least a small subset of the SM data with the SYS SUMM pages. The GNC SYS SUMM display doesn't provide it.

But for testing things, there would also be many missing PASS displays high on our wishlist. Maybe not as high as the BFS though.

One alternative would be leaving the BFS for somebody else to make a PR for it. You could then limit yourself to controling things as skeptical maintainer and could maintain full sovereignty over your fork of SSU. (which wouldn't make sense to revive anyway at this point). You could then focus on your own priorities.

A bit of history behind my current interest on the BFS. The original computer concept would have the PASS GPCs running 2 major functions simultaneously, so you would have the computers do GNC to fly the vehicle and SM to check for system issues and perform calculations, not associated with GNC. Sometime in the late 70s this concept fell victim to the lack of memory and CPU power, and so the SM tasks were "offloaded" to the BFS, simplifying the PASS to only run a single MF at a time. During ascent and entry, when the PASS is exclusively working the GNC, the BFS is handling the display (in the CRT) of the MPS He dP/dt, and also the APU and WSB quantity calculations for display, initially in the panels, and later in the APU/HYD MEDS display. Only in orbit does the PASS, thru the SM GPC, perform those quantity calculations.
Now, currently in SSV those quantity calculations are performed in the subsystem, and maybe that can remain so for sometime. But in the v2.0 branch, the BFS displays are gone, so no more He dP/dt, which one can argue isn't that important for now. So maybe there isn't much in favor of the BFS for now, and there is of course the dificulty in making it, with all the "leaching" on the busses to know what is going on.
Thus my lack of "yes" or "no" decision on this, which can easily be interpreted as "not yet".

Could you add a "default I-Load" for the ANTENNA SPEC? right now it displays a blank rectangle where the limit envelope for the Ku band antenna should be. The "vertex" list for the polyline is documented somewhere.

In the trunk, that display currently does nothing, so I'm not loosing time over it there. In the v2.0 branch, it is all draw with the exact coordinates.

 

[dennis.krenz]

Well, we can discuss how to get some kind of internal interfaces for letting somebody write a clean PR there, that doesn't result in more work for the same feature in the future. Or we talk about hacks. I can wait for a time when things are at least less of a hack and at least have a clear path to a clean code base in a future milestone release.

All I really want is getting to the end of the post-insertion checklist without lots of oddities. Its great that ascent works almost flawless, but its really in orbit at this point and not yet the beginning of the actual mission.

 

[GLS]

Well, we can discuss how to get some kind of internal interfaces for letting somebody write a clean PR there, that doesn't result in more work for the same feature in the future. Or we talk about hacks. I can wait for a time when things are at least less of a hack and at least have a clear path to a clean code base in a future milestone release.

The Hardware C&W interface is defined, so nothing there to worry about.
On the DPS side, the interface is with the MDMs, and they are there. There might not be information on which MDM card and channel each signal goes into, but there is plenty of free space for now. The path inside the DPS isn't final yet, but that is irrelevant for now. The data requests should be a line of code per MDM card, and the displays can be added to show the data. Later I'll just have to replace the displays with the new versions, the data is the same. Software C&W... I know it had tables up the wazoo, but I have no data on them.
Panels: R1 is there, so you can play with the heaters of the basic 3 tanks, while I work the aft panels for the other tanks.

One base condition: if this, or something else, is to be made for a minor version release (v1.x), then backwards compatibility must be maintained, so an existing scenario/mission can't CTD because some parameter is missing. A major version release (v2.0 or v3.0) is the place to make structural changes, so in those anything goes. The only compatibility in there will be the conversion of "old" mission files to the new version.

All I really want is getting to the end of the post-insertion checklist without lots of oddities. Its great that ascent works almost flawless, but its really in orbit at this point and not yet the beginning of the actual mission.

I'm not chasing checklist items, I want the systems to work. That way, things work as they should, both with the correct actions and without them.
The DPS is one of several systems that are still incomplete, so it doesn't behave as it should.

 

[dennis.krenz]

I'm not chasing checklist items, I want the systems to work. That way, things work as they should, both with the correct actions and without them.
The DPS is one of several systems that are still incomplete, so it doesn't behave as it should.

I also tried seeing things in that direction and it really made me mad. I am not sure if it can really work in a way that can be played.

 

[Banshii59]

I think a good thing to do at this point is to pull up one of the videos @Geoair2 has posted a couple pages back, and watch what they're doing with the MM's and the FDO data. It takes a little drunk monkey button pushing initially on your own to kind of learn the process needed in the particular phase of flight you're in. Now that you've explored the checklists some, try reviewing those checklists while seeing what's being done in the videos, and things will start to make more sense....at least it did for me. Not much hands on help from me, but more encouragement, and some insight in a learning process that's worked for me.

Yes, I agree about gettting to know the systems. I have accomplished all the basics of the launch, OMS burns, using the Shuttle FDO MFD program and I've solved a lot of my own issues through trial and error, and observations key to a successful flight. I read through the SSV manual completely. I have a good understanding of the working o tthe RMS, PLBD, deployments. Before I can go any further. My latest "challenge" has been trying to figure out why the FDO deorbit burns are calculated an hour early. My MET time and my TIG time are synced to the second, my FDO config are correct with proper TLO/ DLO info. I use the proper REV info. I input the info correctly. TIG/MET time 03/14:39 on the 67 orb for KSC. Its 158DL which is a descend 3 min after sunrise. Here is how it's entered on my OPS 301 screen: As you can see, the info is correctly entered, the time is synced, The FDO did it's job and the result is that I am at least an hour behind from reaching the landing site. The map with ground track has my shuttle a "track" over from where it should be for the approach to the HAC and I have racked my brain to come up with a solution for this latest. I'm not ignorant concerning aviation issues, I am a licensed pilot but I become a little hesitant about reaching out. I love this sim and all the bells and whistles that came with it. I am new, I can read, and I only ask when other options have been exhausted. If you want to assist, I wouldn't mind. I have certainly taken a healthy, realistic approach to this software and my. ever growing daily, capabilities to get better and assist someone else down the road.

 

[GLS]

Here is how it's entered on my OPS 301 screen: As you can see, the info is correctly entered, the time is synced, The FDO did it's job and the result is that I am at least an hour behind from reaching the landing site.

I'm not understanding... if you deorbit with that data, you'll be 1 hour late.... in relation to what?
From TIG until landing it should be about 1 hour or so, and FDO MFD will show both TIG and time of landing (give or take a couple of minutes) in one of the displays... are you saying that using one of those TIGs, you don't get to the runway at the corresponding landing time?

 

[Banshii59]

I'm not understanding... if you deorbit with that data, you'll be 1 hour late.... in relation to what?
From TIG until landing it should be about 1 hour or so, and FDO MFD will show both TIG and time of landing (give or take a couple of minutes) in one of the displays... are you saying that using one of those TIGs, you don't get to the runway at the corresponding landing time?

With the data calculated by the FDO, I input all the info it needs from rev to start/end and it calculates for the closest Xrange i've chosen. When I put the info into the Deorbit page. (I think I added a screenshot to illustrate that the info was correctly entered) After the burn, I enter the OPS 303 and let that run down to about 3-5 min. Then I enter OPS 304. At this point everything starts to look good but then the yellow graphic illustrating my shuttle is veering of the grid and I get red alerts. I also notice the angles were off , instead of being on a path of 2-3 degreees vector, it has 167 in a flashing red box. Afterward, I checked the map and it explains the discrepancy with my ship on the other track. which eventually leads to the landing strip but not for another hour. I ran some dry runs of the FDO landing scenarios and timed an approx burn etc, and they all came up short of the KSC. I used various targets in the FDO config, same thing. I've tried adding time to the burn, that was not a solution My MET/ TIG times are synced as well the FDO config for DLO/TLO. I 've thought of everything I know. until the deorbit, everything on the mission is easy, but there is a discrepancy somewhere and I can't seem to find it. So to answer your question, yes, I am not making the landing site on the TIG provided. I'm at least an hour early on the burn.

 

[indy91]

Sadly the screenshot is not quite large enough to actually see the numbers in the MFD and Shuttle display. Almost, but not quite.

I would say the most likely discrepancies would be the launch day or launch time in the FDO MFD or a mismatch between the selected landing site in the FDO MFD versus the site selected in SPEC 50.

 

[Banshii59]

I'm not understanding... if you deorbit with that data, you'll be 1 hour late.... in relation to what?
From TIG until landing it should be about 1 hour or so, and FDO MFD will show both TIG and time of landing (give or take a couple of minutes) in one of the displays... are you saying that using one of those TIGs, you don't get to the runway at the corresponding landing time?

Here are some screenshots to help you get a better understanding. I simply put the info thats calculated in and this is the result.The burn occurs a least 30 min earlier as illustrated, the 304 page shows everything. This is crazy, I know. Is there something I missed?

 

[GLS]

I would say the most likely discrepancies would be the launch day or launch time in the FDO MFD

The year 2000 was a leap year, so that extra day might be messing up things somewhere...

@Banshii59 can you confirm that this is the STS-101 mission, and the launch was on 19 May, and that the day-of-year (go to panel O3 above the pilot, and select GMT) is 140?

Sadly the screenshot is not quite large enough to actually see the numbers in the MFD and Shuttle display. Almost, but not quite.

I think the forum is shrinking the images...
@Banshii59 you could upload the images to https://postimages.org/ (or another host of your preference), and that should keep the original size.

 

[Banshii59]

The year 2000 was a leap year, so that extra day might be messing up things somewhere...

@Banshii59 can you confirm that this is the STS-101 mission, and the launch was on 19 May, and that the day-of-year (go to panel O3 above the pilot, and select GMT) is 140?



I think the forum is shrinking the images...
@Banshii59 you could upload the images to https://postimages.org/ (or another host of your preference), and that should keep the original size.

Yes, this the mission currently is confirmed on 19 May 2000 L/O 10:11:10, unfortunately, the issue has happened in the STS -107 as well. I chose this solution since it was the only one that didn't give me Convergence issues Fixed or Free. the 3rd picture is the burn exe. Here is where this happens way to early, at least an hour from where I should be. Also notice it is not on the track leading to the KSC in the map view. Then there is the OPS 304 that simply disintigrates. Hopefully you have 4 images on the link provided. Thank you for your assist.

https://i.postimg.cc/brT6V2FN/Miission-confirm.png

https://i.postimg.cc/q731VF5R/TGT-Solution.png

https://i.postimg.cc/CL858HXK/Burntime.png

https://i.postimg.cc/SQB8HspC/OPS-304-PRO.png

https://i.postimg.cc/Dw2Jg8t6/Time-stamp.png

 

[indy91]

Ah I see the problem. I guess that is not made clear enough, but the "day" input on the Config page of the FDO MFD needs the day of year, not day of the month.

 

[GLS]

Ah I see the problem. I guess that is not made clear enough, but the "day" input on the Config page of the FDO MFD needs the day of year, not day of the month.

Yep, was about to post that.
In STS-101 the day should be 140. Again, the current day of the year is shown on panel O3.

 

[indy91]

Yep, was about to post that.
In STS-101 the day should be 140. Again, the current day of the year is shown on panel O3.

I'll clarify it in the MFD and in the manual. Just an unlucky case I guess, usually one can just leave the year/day blank and the MFD will automatically use the current day as launch day, but if the first attempt at using the MFD is with an on-orbit scenario and you have to manually input the day then this can easily happen if one doesn't realize the day-of-year thing.