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

[Urwumpe]

Are you implementing Electrical systems?:thumbup:

Later. Some basic things are already existing there, but what he means are the 1 Mbit/s serial data busses (very similar to MIL-STD-1553) called Shuttle Bus, which connect the various MDMs and bigger subsystems to the GPCs.

What could be interesting about the electrical systems -for the bigger relays and switches, we have the specifications, including how fast they react. :lol:

 

[Gingin]

Wow nice
So you are planning on which busses specifically ?
Flight critical, payload, Ldb ?

Very nice to see all the nice coming stuff, great work

 

[Urwumpe]

Wow nice
So you are planning on which busses specifically ?
Flight critical, payload, Ldb ?

Very nice to see all the nice coming stuff, great work

Not specifically - I focus on having the C++ components to do all Shuttle busses and the simpler serial data buses used to connect subsystems to the MDMs.

Implementing and connecting the subsystems to the MDMs or writing the software to use the buses is second priority for me... first I'll finish the basic infrastructure. One of the tougher aspects right now is that it is the second time I try multi-threading in Orbiter. :lol:

 

[Gingin]

Ah ok I see, not specifically bus with GPC interaction, but the whole stuff behind and MDM connection to systems.

That's a hell of a project :thumbup:

I was wondering, is it possible to have some updates of what you have added in the SSU 5 , and what you are planning to do? ( if it's not secret of course )

 

[Urwumpe]

I was wondering, is it possible to have some updates of what you have added in the SSU 5 , and what you are planning to do? ( if it's not secret of course )

Mostly I plan to have a SSU 5. :lol:

Seriously though: This is team effort, everyone has his own pet topic he likes to push forward and everyone also does some of the necessary work that nobody really likes.

Personally, I would like to find the time getting EVA capability back into SSU for SSU 5. But right now, I can't even tell when I will have all bugs ironed out in the new GPC model.

 

[Gingin]

Ahah

New GPC model? Very interesting.
More DPS pages and Major Function? Or deep re writing of the system behind?

 

[Urwumpe]

More DPS pages and Major Function? Or deep re writing of the system behind?

The latter in first place, but once I have this done, we can also resume adding more display formats.

Right now, we sort of ignore the GPCs and other hardware and simply run the software. We have no memory configuration, no tape drive, essentially everything that influences the runtime behavior is missing.

Design goal right now is switching to a partition model. A partition as in computing - multiple GPCs running the same software are treated as if they are one big computer. Additionally, I am using multi-threading now, so the GPC software can be written like it is described in the STS software documentation, without caring about Orbiters time step model or frame rates. Just one big function, if you like to. The only thing that really synchronizes with Orbiters simulation is the Virtual IOP. If you pause Orbiter, the GPC software can run for a few microseconds before stopping at an IO operation.

The GPCs are then just "execution resources" for the partition.

Another factor for rewriting the core DPS there: We can have a better BFS then.

 

[GLS]

Another factor for rewriting the core DPS there: We can have a better BFS then.

Fixed.

 

[Urwumpe]

Fixed.

Sorry. :lol: I wanted to be diplomatic there.

 

[Gingin]

Ahah

Ok thanks for the info.
So it's quite a deep GPC rewritting you re on :thumbup:
Is it like almost emulation of the GPC soft?

 

[Urwumpe]

Is it like almost emulation of the GPC soft?

No. Not even slightly. I replicate some HAL/S high-level language features which connect directly to the FCOS of PASS. That is really all. Also I plan reproducing the display macros of HAL/S in C++ for easier writing of display software.

There are some attempts at emulation at times, but we lack information about the AP-101S there and we gain little accuracy there. We just don't need to fake the register contents then for one OPS 0 display.

And on the other hand - native C++ implementation of the software should be way faster even than just-in-time compiled AP-101S machine code.

And BTW: We can already enjoy enough low-level programming with the VirtualIOP then.

 

[Gingin]

It looks like a nice plan

What is exaclty VirtualIOP?

 

[Urwumpe]

It looks like a nice plan

What is exaclty VirtualIOP?

Each GPC has an Input/Output processor (IOP), which is essentially a special computer that can communicate with the Shuttle busses.

Since we are reducing the GPCs to a single partition in the usual case, we don't need four IOPs for example, but one virtual IOP for the whole partition, that behaves like a single IOP for the software, but maps to the actual IOP hardware for talking to the busses.

More joy: There is actually even a tiny virtual CPU layer around. But you never talk to it directly, it is hidden in the FCOS implementation. We just need it for implementing the BFS, because the BFS has no FCOS.

 

[GLS]

Time to make decisions without data (a.k.a. most days in SSU :lol:

Any objections if I consider the "post-liftoff water" portion of the SSWS to be only the water being sprayed onto the pad surface, around the SRB holes? (and the water inside the flame holes would be the "pre-liftoff water")

Well... it looks like the SLC-6 SSWS valves all feed into one pipe (instead of 2 at LC39) which then feeds the launch mount, which means there is not "post-liftoff water". :shrug:

 

[Urwumpe]

Little SSU work here thanks to a lot of official paperwork...

But I wonder the following: Is the optimization for a partition oriented DPS really needed, if we have multithreading? A lot of the work is about hiding the right amount of hardware from the software and abstract the FCOS properly.

Now, would we allow five GPCs executing the software parallel, we would have to solve the full synchronization issues between the GPCs and more CPU load, but the FCOS abstraction could be done simpler. Debugging the actual PASS software would be more difficult, but the DPS rewrite could be done faster.

 

[GLS]

Little SSU work here thanks to a lot of official paperwork...

But I wonder the following: Is the optimization for a partition oriented DPS really needed, if we have multithreading? A lot of the work is about hiding the right amount of hardware from the software and abstract the FCOS properly.

Now, would we allow five GPCs executing the software parallel, we would have to solve the full synchronization issues between the GPCs and more CPU load, but the FCOS abstraction could be done simpler. Debugging the actual PASS software would be more difficult, but the DPS rewrite could be done faster.

So, the options are:
1) multithreaded implementation of 1 GPC emulating 4 (or 5) GPCs or,
2) multithreaded implementation of 4 individual PASS GPCs and 1 BFS GPC.

As the graphics are by far and away the limiting factor (at least here), I'm not against running all 5 GPCs (I'd go down that road). If multithreading can be implemented without issues when it comes to talking with Orbiter, I'd say it makes option 2 even more appealing, as it won't cost much more.

 

[Urwumpe]

As the graphics are by far and away the limiting factor (at least here), I'm not against running all 5 GPCs (I'd go down that road). If multithreading can be implemented without issues when it comes to talking with Orbiter, I'd say it makes option 2 even more appealing, as it won't cost much more.

Well, I expect it to be a bit more troublesome later since we then have multiple times the same process running at the same time. This can make programming software for it a lot harder, but we would also get a bit more time for this part of the development. Especially, we would need to include the SYNC SVC for GNC.

But then, it could also make the result more realistic - the GPC fault voting matrix could actually do something.

 

[GLS]

Just a heads-up, I added the 3 launch pad Firex systems (that I know of) (see manual for instructions), but currently the particle streams "appear out of nowhere" as some pipes are missing/wrong. The directions are probably also not perfect, but they will have to do until the new pads are done. Same goes for the SLC-6 SSWS.

 

[DaveS]

How close are we to being able to implement tanking procedures into the countdown? AFAIK, it's a mostly automated deal run by two separate sequencers (one for the LH2 side and one for the LOX side).

Here's two documents that should be helpful in implementing that:
Computational Model of the Chilldown and Propellant Loading of the Space Shuttle External Tank.pdf (2007)
STS_ETMPS_LOADING.pdf (1983)

 

[Urwumpe]

How close are we to being able to implement tanking procedures into the countdown? AFAIK, it's a mostly automated deal run by two separate sequencers (one for the LH2 side and one for the LOX side).

Here's two documents that should be helpful in implementing that:
Computational Model of the Chilldown and Propellant Loading of the Space Shuttle External Tank.pdf (2007)
STS_ETMPS_LOADING.pdf (1983)

Well, can this be implemented without a thermal model of the ET?

Do we need to add valves to MLP or launch complex? What about SLC-6 there, can we stay compatible to it?

Generally, I think we are not far away there, but I would not give this feature a very high priority right now, we have other missing things that the player will notice more easily. But maybe this feature can be implemented when the final touches of the DPS are getting done.