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

[Urwumpe]

I've created a branch for this work... feel free to use your new password.
I think we could start with getting the EIUs using the new system, as it has a lot of back-and-forth, and if it does the job there it should work for the rest.

Sorry, I am out of development for the next weeks. First of all, because I have a damn full schedule this month because of the first birthsday of my son. And finally because of artistic disagreements. :shrug:

 

[GLS]

Sorry, I am out of development for the next weeks. First of all, because I have a damn full schedule this month because of the first birthsday of my son. And finally because of artistic disagreements. :shrug:

Yes, my idea is far from perfect or final, but what other options are there? IMO it's either this or stagnation.

 

[Urwumpe]

Yes, my idea is far from perfect or final, but what other options are there? IMO it's either this or stagnation.

Just do what you think is right. I just remember that my design choices had been rejected lately, so I am the very last person you should consult there.

 

[GLS]

The SimpleShuttleBus as arrived!
Currently only one command to the EIUs is using it, but it works. Next I have to finish the subsystem-to-GPC data flow and also work on "what is done when" on GPC IO.
One thing I'm not sure how to handle is the HUDs having the same address as 2 DDUs. That and the diagrams only have bits 1-28, but it should be 32, right?

 

[Urwumpe]

One thing I'm not sure how to handle is the HUDs having the same address as 2 DDUs. That and the diagrams only have bits 1-28, but it should be 32, right?

No, 28 bits is right. Only 16 bits are payload. I'll show you.

Also I can get you some DDU information that way.

---------- Post added at 21:20 ---------- Previous post was at 21:13 ----------

See here:

 

[GLS]

No, 28 bits is right. Only 16 bits are payload.

Hmm, as it started in bit 1 I assumed not everything was being shown... :facepalm:

So I guess I'll have to use 2 structure (one for command words and another for data words). In the end it probably will add padding to 32b but we won't see it.

Those pages come from the SODB right? I'll have to check that after dinner (I've been using the info on the giant diagrams DaveS uploaded).

 

[Urwumpe]

Hmm, as it started in bit 1 I assumed not everything was being shown... :facepalm:

So I guess I'll have to use 2 structure (one for command words and another for data words). In the end it probably will add padding to 32b but we won't see it.

My plan was to ignore this detail on the bus level. Not sure if we really need it. Having a union of CW and CDW structs might work out (would take 4 bytes anyway), but would be a lot of invisible encoding/decoding for a small number of special use cases.

For example, the important data in the CW could also be transmitted as parameters of a function call, the payload data could be an array of shorts or a stream object (With calls like: write to stream, read from stream).

Those pages come from the SODB right? I'll have to check that after dinner (I've been using the info on the giant diagrams DaveS uploaded).

Yes.

 

[GLS]

I think I've finished the SimpleShuttleBus, and got the EIU/SSME SOP use it fully. There are (still) some hacks in there, but hopefully one day they will be gone.
I think I'm also going to switch the MEC/MEC SOP to the new stuff, before I merge (not decided where to... probably OrbitersimBeta) and start the HUD. Not sure if I should also get a MDM working... should be the same as far as the bus is concerned, so it probably can wait. :shrug: (btw: just noticed that the ATVC and ASA commands are sent via MDM)

 

[GLS]

Any futher info on HUD "bus traffic"? It seems there are tons of stuff missing there (or they have different names), so I'm going to add a HUD message 3 and send in there the needed data. :shrug:

Also, the data will be converted to unsigned short in the GPC as we can't send floats in 16b and the table only uses 1 word for each parameter. That probably explains the visible "wobble" in the HUD symbols in the videos. Anyway, somethings we can mutiply by 10 (NZ for example has to be this way) to preserve a decimal place.

 

[Urwumpe]

Any futher info on HUD "bus traffic"? It seems there are tons of stuff missing there (or they have different names), so I'm going to add a HUD message 3 and send in there the needed data. :shrug:

Well, remember its of an old configuration of the Space Shuttle, so its highly likely that newer features in the HUD are not around. Also, maybe some missing features can be derived from the transmitted data.

What is missing?

 

[GLS]

Well, remember its of an old configuration of the Space Shuttle, so its highly likely that newer features in the HUD are not around. Also, maybe some missing features can be derived from the transmitted data.

What is missing?

Yeah, the document is from 1988, and I don't really know how the HUD looked in the 80s.
Judging from this (circa 1990) it looks the same as the "current" sim HUDs.
(@ 38:45)

Let's start with something simple: the roll angle of the vehicle, so it knows at which angle to tilt the pitch ladder. The only "roll" mentioned in the table is "Roll error"... is that it? Or is that related to the guidance diamond? (btw that should be fun to do :facepalm

Another is guidance mode/phase/whatever. The only way I see that being sent is via the "HUD message x control word"... but again I have no idea what goes in that word.

I don't think it's a bad idea to use the table to the extent of our knowledge, and whatever else we need we just put in the new "message 3" instead of guessing... we can always correct things later if more info emerges. :shrug:

 

[Urwumpe]

Aaaaaah... you miss the data that is NOT HUD-unique. :idea:

Remember: HUD and dedicated display system have the same bus terminal number.

 

[GLS]

Aaaaaah... you miss the data that is NOT HUD-unique. :idea:

Remember: HUD and dedicated display system have the same bus terminal number.

Now it makes sense!!!!

---------- Post added 05-16-18 at 10:10 AM ---------- Previous post was 05-15-18 at 06:10 PM ----------

The DDU displays all have a "data validity" word, which I'm going to assume has bits set to 1 when the respective data word is valid. It makes sense so the HUD knows the radar data is valid during landing. :shrug:

2 things that aren't "flowing nicely" are the NZ and the sideslip values.
There is a "vehicle acceleration" on the AMI which my info points to be total acceleration, and a "vertical acceleration" on the AVVI, which is also not what we want.
On the sideslip, we have "yaw (co)sine" on the ADI, but I'm not sure how the MCDS ADI worked during reentry. I know the MEDS one has yaw at 0 during reentry, but I've seen no info for the MCDS version.

And now some good news: the guidance diamond was actually very easy to do. Its deviation from the flight director/velocity vector is the pitch and roll errors, so the existing logic there (which was a repeat calculation of things that were already calculated (several times) in the old guidance) went away. Now, I just need to finish the new guidance to get those pitch and roll errors... :shifty:

---------- Post added at 10:18 AM ---------- Previous post was at 10:10 AM ----------

BTW guidance phase, WOW and WONG signals are also not explicit... not sure if I should put them in the HUD message control words... and then there are also GPC-to-HUD flags words... :uhh:

---------- Post added at 10:45 PM ---------- Previous post was at 10:18 AM ----------

I've left the HUD for now, as I want to get the guidance part finished so there is data to feed to the HUD.
My previous idea (which I never really liked) was to run the 3 guidance modules (entry, TAEM and A/L) inside AerojetDAP, and have it feed them data and then use their outputs to fly the vehicle. But I think having them as independent "SimpleGPCSoftware" classes, and having them interact with with the AerojetDAP is better.
The big problem is that now we can't have the AerojetDAP running before (for data input, a.k.a navigation) and then after (as it should, for flight control). The "small" problem is scenario load/save... :facepalm:
So it seems we need (at least) another new module to get the data needed for the 3 guidance modules. The info I have available has 3 User Parameter Processing modules, one for each part of the entry/landing... all doable, but still it's even more change with not that much info, so if anyone has more info please share.

 

[GLS]

The altitude "resolution" to the HUD in 16b is IMO insuficient. For the radar altitude it is more than enough, but for the "NAV-value", which feeds the HUD tape, which goes up to 400kft (don't shoot the messenger), we get about 6ft resolution if we do a quantization instead of dumping the value in (which would only give a 65kft range at 1ft resolution)... meaning the tape would start to jump a bit towards the lower altitudes.

Options: (1) ignoring the 400kft max and make it 100kft, and get a 1.5ft resolution, or (2) use the breaks in the tape to change resolution. There are 4 sections in the tape, and it would take 2b to identify them, leaving 14b for the data. We would get 18ft resolution between 400k and 100kft, 6ft between 100k and 1k, and 0.03ft below 1000 ft.

 

[Urwumpe]

What is bad about the <10ft accuracy? Its pretty good regarding the age of the shuttle.

 

[GLS]

What is bad about the <10ft accuracy? Its pretty good regarding the age of the shuttle.

The problem is that the tape would move in 10ft steps, and when the visible range is maybe 100 ft, that would make the tape jump quite a bit, instead of having a +/- fluid motion. :shrug:
I don't know how the AVVI tape was, but it would suffer from the same issue.

 

[Urwumpe]

The old AVVI tape displayed effectively from 300 Kft to 200 ft, the Radar Altimeter tape from 3000 ft to 200 ft. Also, the decoder for those tapes converted 12 bit digital values to analog for moving the tape.

 

[GLS]

The old AVVI tape displayed effectively from 300 Kft to 200 ft, the Radar Altimeter tape from 3000 ft to 200 ft. Also, the decoder for those tapes converted 12 bit digital values to analog for moving the tape.

As I suspected, there is quantization going on (not surprising with analog systems)... now, 4096 steps doesn't seem a lot... :uhh: I don't think 12b alone will work in the HUD. Could the rest (or some) of the bits be a scale id?


BTW: another spin-off from the "monolithic" AerojetDAP class is going to be the landing site table and site selection. I think they were actually 2 separate modules, but for now I think that can all live under one roof.

 

[GLS]

I think we have a small inconsistency in the runway name: the SPEC 50 display has 5 chars allocated for it, and we currently don't have a limit and some sites have 6 chars like EDW22L. As, in the case of Edwards (and others as it looks), the XYZ22R runway has a different "XYZ" name (EDT), I think the left/right char should not be used in the runway name inside the GPCs. There is a tag in our database (the first entry in each runway) that can keep the left/right stuff so it matches the checklist.

 

[DaveS]

I have checked in a new orbiter mesh that has a few changes. Mainly it is the additions of the PLB liner flight kit that was used on all IUS missions as well as the HST missions and the four PLB radiator panel retract hoses. These hoses are connected to the radiator panel inlet manifolds. There's two retract hoses per side, one for the two forward panels and one for the aft panels.

The hoses are what supply the panels with the actual Freon-21. The hoses are on a take-up reel beneath the PLB sill longerons and are automatically pulled off the reels as the PLBDs are opened and wound up when the PLBDs are closed. So these needs to be animated.