SSU Development Thread (2.0 to 3.0)

[Urwumpe]

The math isn't concerning me (at least for now). My main concern is: "is it possible to do an ADI that looks like the one in the shuttle, using GDI?" Looks like it's possible, but there's still much work to do before that question gets a definitive answer.

Of course its possible. But letting the math be done by GPU is of course faster.

 

[GLS]

I was checking the fix SiameseCat did for ticket 78, and noticed that the yaw channel is always active. Even with the flight controller power switch off (all of them actually), if one uses the numpad 1 and 3 keys the vehicle responds. With the switch on it still responds, but the roll/yaw channel doesn't downmode to MAN, like when there's an input in pitch or roll. Is this normal?

---------- Post added at 03:10 PM ---------- Previous post was at 02:52 PM ----------

BTW: just deleted about 17MB of old meshes according to ticket 80. Actually I didn't realize how much of a chunk that was until I checked the size of the mesh folder in the SSU 2.0 distribution. That was ~138MB, so that's a 12% decrease in size!
I'll do a similar exercise for the textures in the coming days.

---------- Post added at 08:42 PM ---------- Previous post was at 03:10 PM ----------

Actually did the textures checks today: #82

 

[DaveS]

I added my own list of textures that are still in use to #82.

 

[SiameseCat]

I was checking the fix SiameseCat did for ticket 78, and noticed that the yaw channel is always active. Even with the flight controller power switch off (all of them actually), if one uses the numpad 1 and 3 keys the vehicle responds. With the switch on it still responds, but the roll/yaw channel doesn't downmode to MAN, like when there's an input in pitch or roll. Is this normal?

That's a bug; the rudder should only be manually controllable if the FLT CNTLR PWR switch in on.

 

[DaveS]

Where do we stand on getting the all the meshes in a releasable state? I'm not sure if these two are known:

Aft faces of the PLBD C/L hooks are flipped:

Gaps between interior/exterior meshes of the PLBDs:

 

[GLS]

That's a bug; the rudder should only be manually controllable if the FLT CNTLR PWR switch in on.

I thought so.
Is it necessary to create a ticket for it?

 

[Donamy]

Where do we stand on getting the all the meshes in a releasable state? I'm not sure if these two are known:

Aft faces of the PLBD C/L hooks are flipped:

Gaps between interior/exterior meshes of the PLBDs:

Can you take some pics in daylight ?

 

[DaveS]

Here you go:

 

[Donamy]

I see now, but that shouldn't hold up the release.

 

[DaveS]

I see now, but that shouldn't hold up the release.

No, just wanted to bring them up for noting. One minor change that should be in the release the remapping of the textures on EVA handrails on the PLBDs. Currently they share half of the mapping with the PLB floodlights. A move to the left should do the trick.

 

[GLS]

Could someone get me the coordinates for the 3 ADI switches in each of the F6, F8 and A6U panels, please?
And also a question: to what are those switches connected? It makes sense (to me) that they should be connected to the IDPs (the CDR one to IDP1, PLT to IDP2 and aft to IDP4), and when the MDU wants to draw the PFDs it checks with the IDP how are those switches positioned (using, temporarily, a simplex version "each MDU only talks to 1 IDP").

 

[Urwumpe]

Could someone get me the coordinates for the 3 ADI switches in each of the F6, F8 and A6U panels, please?
And also a question: to what are those switches connected?/

AFAIR to the Flight Forward MDMs, since the old ADI data is also generated by the GPCs and send to the dedicated display system via data bus.

Each ADI has a single flag labeled OFF on the left side of the display that is used to indicate whether valid GPC data is driving the ADI software. Presence of the OFF flag can be used to determine if a FC bus problem exists at the GPC driving the IDP that is hosting the ADI, and is used to help troubleshoot in DPS malfunction procedures.

 

[GLS]

AFAIR to the Flight Forward MDMs, since the old ADI data is also generated by the GPCs and send to the dedicated display system via data bus.

OK, so how will we connect the switches? Use a SimpleGPCSoftware class to get the switch data and then have the IDPs call that software? If so, should I use the existing IO_Control class, or create a new one? (with what name?)

 

[Urwumpe]

OK, so how will we connect the switches? Use a SimpleGPCSoftware class to get the switch data and then have the IDPs call that software? If so, should I use the existing IO_Control class, or create a new one? (with what name?)

Well, lets say it that way:

I want to replace the current model by something that behaves like the original. So, as highest level there will be partitions with computers being a mere resource running the same software in sync.

Instead of directly connecting software to switches, there will be a virtual IOP that acts like all IOPs of the GPCs running in the same partition. Instead of directly polling switch positions, there will be direct memory access I/O, which writes the data from MDMs directly into a virtual GPC memory of the united partition.

So, the switches should connect to a DIL (discrete input, low voltage) module in an MDM and the MDM should be connected to a data bus. The virtual IOP communicates over the bus with the MDM and gets the data of the switch positions as 16 bit word and writes it into memory. Then it wakes up the process that expected the I/O data and lets it process the switch position stored as 16-bit word in simulated GPC memory.

I would say, from what I know of the old analog cockpit, the GPC software that handles the switch position would likely also be the same software that generates the attitude data for the ADI. Something like a DDD_SOP task.


Now, as you can expect, this will all take too long to refactor into SSU before release.

I am not sure yet, what would be the best compromise between now and then for a fast implementation - maybe we should define some "coarse" interface for the software by communicating exclusively with partition memory and have a second software class for the current GPC implementation, prefixed something like "IO_", that gets the switch data the direct way as you suggest and how it was done before, but just writes the data into or from partition memory. Later, we just replace the "IO_" software by proper IO programs in the new model and need only minimal tweaks to get the bigger software tasks run as partition software instead of SimpleGPC.

 

[GLS]

Not sure I'm following you, but I think the "fast implementation" is half-done, as the IO_Control class I created exists as a sort of interface between (some) switches, (some) software and (some) outputs. This was mostly needed for the OP/GPC/CL switches. And about the central memory, we probably could do without it for now, as the software can find and talk to each other, and moving the IO out of each software class would take time and testing and delay this release even further.

 

[Urwumpe]

Not sure I'm following you, but I think the "fast implementation" is half-done, as the IO_Control class I created exists as a sort of interface between (some) switches, (some) software and (some) outputs. This was mostly needed for the OP/GPC/CL switches. And about the central memory, we probably could do without it for now, as the software can find and talk to each other, and moving the IO out of each software class would take time and testing and delay this release even further.

Sorry, but I have a strong dislike for implicit dependencies, its much better to make this explicit and as minimal as possible. The shared memory dependency would be better for keeping the code clean, otherwise we call loudly for bugs and enormous technical debt for improving the code.

 

[DaveS]

ADI switch pos:

CDR side(PLT is mirror X axis):
ADI Mode switch: 0.633, 2.045, 14.7004
Error switch: 0.5921, 2.0469, 14.7009
Rate switch: 0.5627, 2.0463, 14.7008

 

[GLS]

Sorry, but I have a strong dislike for implicit dependencies, its much better to make this explicit and as minimal as possible. The shared memory dependency would be better for keeping the code clean, otherwise we call loudly for bugs and enormous technical debt for improving the code.

I'm not thinking about changing any software classes so they use the current IO_Control class (or something like it), I'm just saying we can use the IO_Class to get the position of these ADI switches.
The more I think about it, the less necessary it seems to have the "intermediate version" (at least for this release). After we get this version out the door, we should do those changes, either with or without that "intermediate version".

 

[Urwumpe]

I'm not thinking about changing any software classes so they use the current IO_Control class (or something like it), I'm just saying we can use the IO_Class to get the position of these ADI switches.
The more I think about it, the less necessary it seems to have the "intermediate version" (at least for this release). After we get this version out the door, we should do those changes, either with or without that "intermediate version".

Well, as you think, but the more we add to the current release, the more the refactoring will take effort.

The primary goal of the refactoring is to make the user interface of SSU follow the Crew Software Interface standards of the big one and allow following the Insertion Checklist anyway.

 

[GLS]

Well, as you think, but the more we add to the current release, the more the refactoring will take effort.

The primary goal of the refactoring is to make the user interface of SSU follow the Crew Software Interface standards of the big one and allow following the Insertion Checklist anyway.

So we're going to have to rewrite a good part of all the SimpleGPCSoftware classes for this release? (and I was thinking version 3.0 was going to happen this month :facepalm
Ok, we should then create a branch for this, right? Or are you working on it already?