SSU Development Thread (2.0 to 3.0)

[Urwumpe]

I don't see any problems with the star trackers on my end. Did a lot of looking at the front and only found this little issue.

I also saw this, but I thought its just Z-Buffer madness because of the air data probes. Possibly the animation references are wrong, AFAIR, we modell the ADPs deployed in the mesh.

 

[Donamy]

Can you write a summary list of what has to get fixed? Or even file these as tickets? After all, that's why I make those nightly builds.

I redownloaded your nightly build from your #1636 post. Now I'm getting the old mesh from months ago.

 

[Urwumpe]

I redownloaded your nightly build from your #1636 post. Now I'm getting the old mesh from months ago.

The version changed, the new nightly is revision R2216.

http://orbiter-forum.com/showthread.php?p=510640&postcount=1724

http://sourceforge.net/projects/shu...eultra/2.1/SSU_v2.1r2216-nightly.zip/download

 

[Donamy]

The version changed, the new nightly is revision R2216.

http://orbiter-forum.com/showthread.php?p=510640&postcount=1724

http://sourceforge.net/projects/shu...eultra/2.1/SSU_v2.1r2216-nightly.zip/download

:facepalm:You didn't post a new link, so I assumed it replaced the one at #1636.

As Roseanne Rosannadanna used to say "... never mind."

 

[Urwumpe]

:facepalm:You didn't post a new link, so I assumed it replaced the one at #1636.

As Roseanne Rosannadanna used to say "... never mind."

You are right, that was very unprofessional from my side. I'll use a new thread for nightly build announcements in the future.

 

[Donamy]

I'm a happy camper now.

 

[Donamy]

I wasn't quite sure where to ask this, in lieu of the new threads.

Should I put the UARS payload on OH per usual ? And what should be included ?

 

[Urwumpe]

I wasn't quite sure where to ask this, in lieu of the new threads.

Should I put the UARS payload on OH per usual ? And what should be included ?

Right now you can simply put it on OH, you should just make sure that you wait for release until SSU 2.1 is publicly available too. Don't ask me about any legalese there, I would already be happy with a reference, where to get SSU in the manual.

Should we get to payload communications, there might be some requests from our side... or we simply offer you the chance to use a "SSUGenericVessel" module to update your payload with an SSU compatible internal model.

Should you want to donate the payload into the SSU project, we should again decide what the quality standards for reference payloads in our own project should be. At least documentation-wise.

EDIT: What I really recommend you is to provide some checklists for SSU for deploying your payload, the player might like it.

 

[Donamy]

Right now you can simply put it on OH, you should just make sure that you wait for release until SSU 2.1 is publicly available too. Don't ask me about any legalese there, I would already be happy with a reference, where to get SSU in the manual.

Should we get to payload communications, there might be some requests from our side... or we simply offer you the chance to use a "SSUGenericVessel" module to update your payload with an SSU compatible internal model.

Should you want to donate the payload into the SSU project, we should again decide what the quality standards for reference payloads in our own project should be. At least documentation-wise.

How about listing it as a testing payload for SSU ?

 

[GLS]

Right now you can simply put it on OH, you should just make sure that you wait for release until SSU 2.1 is publicly available too. Don't ask me about any legalese there, I would already be happy with a reference, where to get SSU in the manual.

Should we get to payload communications, there might be some requests from our side... or we simply offer you the chance to use a "SSUGenericVessel" module to update your payload with an SSU compatible internal model.

Should you want to donate the payload into the SSU project, we should again decide what the quality standards for reference payloads in our own project should be. At least documentation-wise.

EDIT: What I really recommend you is to provide some checklists for SSU for deploying your payload, the player might like it.

Question: wasn't this going to be SSU 3.0?

Also, we need someone familiarized with the RMS to improve the manual with as in addition to the 8 key there's the CRTL+Backspace and CRTL+Enter keys...

 

[Urwumpe]

How about listing it as a testing payload for SSU ?

Well, I don't like it to be a test payload right now, because it would make the test conditions around the nightly builds more complex than necessary.

If you want it to be used as officially supported testing payload, I would recommend including it into the project and taking project responsibility for it (="The SSU team guarantees that it works with SSU"). But that's a team decision then - and it would take some amount of independence from you.

---------- Post added at 02:52 PM ---------- Previous post was at 02:48 PM ----------

Question: wasn't this going to be SSU 3.0?

That was the long-term plan, but so far, all tickets had been assigned to unknown or the 2.1 milestone, so I kept it as 2.1 in the nightlys.

But I would not call the current improvements a major version increment anyway.

 

[GLS]

That was the long-term plan, but so far, all tickets had been assigned to unknown or the 2.1 milestone, so I kept it as 2.1 in the nightlys.

But I would not call the current improvements a major version increment anyway.

I would. We might not have added something big that changes the users experience, but there were LOTS of changes made over the last +18 months and todays SSU is pretty incompatible (scenario/mission file/mesh/texture wise) with SSU 2.0, so I'd call it 3.0.

 

[Urwumpe]

I would. We might not have added something big that changes the users experience, but there were LOTS of changes made over the last +18 months and todays SSU is pretty incompatible (scenario/mission file/mesh/texture wise) with SSU 2.0, so I'd call it 3.0.

Yes, but I would increase major versions if there is really a large new feature having its premiere for the user. Yes, I know that this is something we can discuss. I don't want to make SSU for the SSU developers, that's my different focus there.


But to prevent such version discussions in the future, that was also why I want to make a requirement workshop on Sunday, so we can plan what goes into the next milestones towards 3.0 and file the tickets for the features.

---------- Post added at 05:08 PM ---------- Previous post was at 03:15 PM ----------

GLS: I see you doing some small improvements to the DPS model, can you keep the work there minimal? (I am watching you with my smartphone :ninja

I design a new DPS model and a way to create the DPS implementation without control from the Atlantis class right now, so we can essentially test new DPS code by enabling it in SpaceShuttleUltra.cfg (Like by writing "DPSModel = simple") there.

I don't want to start any implementation there before the release, only fixing bugs in DPS as they are discovered now.

As next phase then, after abstracting the DPS model away from Atlantis, I wanted to resume work on a "partition-oriented DPS implementation" , as sketched out some months before - instead of having individual software running independent of GPC or memory configuration, GPCs sharing the same memory configuration and common/redundant set could form an abstract partition, which is then the focus of the implementation.

This way, the SM and PL functions could return again properly and the OPS 0 would be possible to access. And we could also implement the BFS in that framework without problems.

But that would also mean that the current "legacy" model would have to be abstracted from the hardware, in the simplest case by a single central class acting as proxy.

 

[GLS]

GLS: I see you doing some small improvements to the DPS model, can you keep the work there minimal? (I am watching you with my smartphone :ninja

I design a new DPS model and a way to create the DPS implementation without control from the Atlantis class right now, so we can essentially test new DPS code by enabling it in SpaceShuttleUltra.cfg (Like by writing "DPSModel = simple") there.

I don't want to start any implementation there before the release, only fixing bugs in DPS as they are discovered now.

As next phase then, after abstracting the DPS model away from Atlantis, I wanted to resume work on a "partition-oriented DPS implementation" , as sketched out some months before - instead of having individual software running independent of GPC or memory configuration, GPCs sharing the same memory configuration and common/redundant set could form an abstract partition, which is then the focus of the implementation.

This way, the SM and PL functions could return again properly and the OPS 0 would be possible to access. And we could also implement the BFS in that framework without problems.

But that would also mean that the current "legacy" model would have to be abstracted from the hardware, in the simplest case by a single central class acting as proxy.

You need to tell me when I did what, as sometimes I don't know what I did the day before :lol:. If you are referring to the changes to the pointers I did today, I didn't change anything inside the DPS, I only removed the FindSoftware calls from functions that were called every time step (CRTMFD data and pad stuff) and moved it to the constructor. It's faster and cleaner this way.
BTW: this all came from the post in the nightly thread about the sound not stopping on a pad abort. I now did a few more changes to fix that, and to also stop the SRB smoke in SLC-6 and rainbirds in the MLP when aborting. Can I commit this, or do I throw it away?
I was thinking about looking into getting the IDP/CRT power switches working, but it can wait. Can I (try) to improve the Ascent Traj display predictors?

I have a little question about the new architecture: there was talk some time ago of just having one instance of SW running, instead of 4, to improve performance. I'm fine with that, but when in orbit there are GPCs on SM and others on GNC... maybe I'm not fully understanding the SM/GNC thing, but that will require more than 1 GPC running, right?

 

[Urwumpe]

BTW: this all came from the post in the nightly thread about the sound not stopping on a pad abort. I now did a few more changes to fix that, and to also stop the SRB smoke in SLC-6 and rainbirds in the MLP when aborting. Can I commit this, or do I throw it away?
I was thinking about looking into getting the IDP/CRT power switches working, but it can wait. Can I (try) to improve the Ascent Traj display predictors?

You don't need to ask me for permission for doing bug fixes. This DPS one was just a optimization. No big one, but before you start implementing new features, I thought it is better to communicate first than to be surprised later.

I have a little question about the new architecture: there was talk some time ago of just having one instance of SW running, instead of 4, to improve performance. I'm fine with that, but when in orbit there are GPCs on SM and others on GNC... maybe I'm not fully understanding the SM/GNC thing, but that will require more than 1 GPC running, right?

Yes. And no. I want to focus on the software partitions of the DPS. This means, computers running the same software together are simulated as one big virtual computer (the partition). So, when there are 4 computers running PASS GNC 102 and one BFS computer, there will be two partitions that are simulated in SSU. These computers don't have four CPUs and four times as much memory, but when one is simulated to fail, the partition would still continue to run almost as before, only the IO channels would require action. The GPCs would continue to exist as subsystem, but instead of running the software, they are just producing "execution resources", that the partitions use.


What I want to get to as well as using the asynchronous I/O via MDMs and IOPs for the software. The current software can't do that, but later, having a "virtual IOP" in the partition would mean that you simply say which data set of a subsystem you need updated. Since most software in the real shuttle operates pretty much the same style of "Update data, process, send data to subsystems", its pretty easy to use patterns for declaring such software.

Without such a virtual IOP, getting the BFS working would be hard.

---------- Post added at 07:32 PM ---------- Previous post was at 06:47 PM ----------

I have a new DPS ticket here:

https://sourceforge.net/p/shuttleultra/tickets/111/

I have not assigned the bug to the current milestone yet, can we do it in the coming days or should it better wait?

---------- Post added at 07:54 PM ---------- Previous post was at 07:32 PM ----------

Are the ASCENT TRAJ 1 and ASCENT TRAJ 2 displays that we show really the PASS versions? They look like the BFS display formats and often even lack PASS indications, like "Pc<50" before SRB separation.

---------- Post added at 08:01 PM ---------- Previous post was at 07:54 PM ----------

Self-answer after some research:

ASCENT TRAJ was the display used by PASS for both first and second stage. ASCENT TRAJ 1 and 2 were the respective BFS displays for first and second stage. Starting with the OI-32 software version (STS-120), PASS used similar displays to the BFS and were also called ASCENT TRAJ 1 and 2.

The old ASCENT TRAJ display was designed mainly to assist RTLS aborts and wasn't very useful for nominal ascents.

The newer PASS Ascent Traj displays were collectively known as 6X Traj (or XXXXXX TRAJ) since the XXXXXX could be changed from ASCENT to an abort name. RTLS TRAJ was significantly different than ASCENT TRAJ. The newer displays were an attempt to implement some of what had been planned with CAU display work.

 

[GLS]

I have a new DPS ticket here:

https://sourceforge.net/p/shuttleultra/tickets/111/

I have not assigned the bug to the current milestone yet, can we do it in the coming days or should it better wait?

This works fine here. Ticket #110 on the other hand, I can reproduce. Could it be related to this in Atlantis::clbkLoadVC?

InactiveMDUs.insert(vc::MDUID_PLT1);
InactiveMDUs.insert(vc::MDUID_PLT2);

Are the ASCENT TRAJ 1 and ASCENT TRAJ 2 displays that we show really the PASS versions? They look like the BFS display formats and often even lack PASS indications, like "Pc<50" before SRB separation.

---------- Post added at 08:01 PM ---------- Previous post was at 07:54 PM ----------

Self-answer after some research:

The old pre OI-32 function is commented out next to the new ones, for future use.

 

[Urwumpe]

But that answer, as good as it sounds, seems to be wrong. The DPS Dictionary on my external HDD is Revision K, Page Change Notice 7 - which is the one that applies too all final flights of the shuttle (including OI-32).

No such changes, the XXXXXX TRAJ is still the PASS display and the TRAJ 1 and TRAJ 2 remain BFS only.

---------- Post added at 08:22 PM ---------- Previous post was at 08:19 PM ----------

This works fine here. Ticket #110 on the other hand, I can reproduce. Could it be related to this in Atlantis::clbkLoadVC?

InactiveMDUs.insert(vc::MDUID_PLT1);
InactiveMDUs.insert(vc::MDUID_PLT2);

Thats possible. but the MDUID_PLT1 and MDUID_PLT2 identify the two pilot MDU displays, those work out fine.

 

[DaveS]

But that answer, as good as it sounds, seems to be wrong. The DPS Dictionary on my external HDD is Revision K, Page Change Notice 7 - which is the one that applies too all final flights of the shuttle.

No such changes, the XXXXXX TRAJ is still the PASS display and the TRAJ 1 and TRAJ 2 remain BFS only.

Well, I think it's better to refer to the SCOM which is for OI-33. Appendix B has all of the DPS displays for OI-33.

 

[GLS]

But that answer, as good as it sounds, seems to be wrong. The DPS Dictionary on my external HDD is Revision K, Page Change Notice 7 - which is the one that applies too all final flights of the shuttle.

No such changes, the XXXXXX TRAJ is still the PASS display and the TRAJ 1 and TRAJ 2 remain BFS only.

I don't think so. If you read those files as I much as I do, you would find LOTS of errors. Plus there are documents that say those PASS displays were upgraded as well as video.

BTW: you MDU scenario change was kind of a downgrade. The launch scenarios were fine (I had the orbit MFD on CRT3 just to help the user and also as we don't have the enough stuff to show), and now I checked the STS-107 launch and there are MDUs off...

---------- Post added at 07:32 PM ---------- Previous post was at 07:29 PM ----------

Thats possible. but the MDUID_PLT1 and MDUID_PLT2 identify the two pilot MDU displays, those work out fine.

That was just an example for one VC position. On each VC position some MDUs seem to be disabled (don't know why).

 

[Urwumpe]

Well, I think it's better to refer to the SCOM which is for OI-33. Appendix B has all of the DPS displays for OI-33.

Here it shows the same displays you mean for OI-32. Which is quite strange, since the final page change of the DPS Dictionary is from 2008.

OI-33 added the SPEC 54 BEARING displays to it (Described in Appendix E), not the modified PASS XXXXXX TRAJ displays - but the dictionary is from Mar 2008, the SCOM from December 2008, the SCOM is at least the newer file of both.



---------- Post added at 08:40 PM ---------- Previous post was at 08:37 PM ----------

I had removed the non-SSU displays and powered those off, that would have been showing displays that we don't have yet.

That was just an example for one VC position. On each VC position some MDUs seem to be disabled (don't know why).

We disabled MDUs for performance reasons, only those should be active, that can be seen.