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

Status
Not open for further replies.
Found some nice short article in the 1977 tech briefs about how the Shuttle displays are generated:

Shuttle Avionics Visual Display

SAV-O support system helps to develop displays.

The SAV-D system is composed of a display description language (DDL) and its language processor. The language provides for the description of displays in terms of static and variable references for text, special symbols, lines, and circles. Graphic displays have previously been hand-coded, using macro capabilities supplied by the manufacturer. SAV-D permits the use of a high-order English-like language to describe complete displays with increased speed and ease of coding, debugging, and modification. It also allows one to specify static and variable attributes, such as location, flash, dash, character size, and intensity. With direct communication of computers via CRT terminals and the general use of graphic displays becoming widespread, a system such as SAV-D should find many commercial applications. Although SAV-D was adapted specifically for Shuttle displays, its principles and logic could be modified for other equipment. In conjunction with appropriate CRT's, SAV-D could be used directly to develop, test, and generate end-use graphics.
The SAV-D DDL simplifies the construction of displays for the display unit (DU) CRT's used on the Space Shuttle vehicle. The language processor translates a display description written in DDL to an object program that, when executed by the display electronics unit (DEU), produces the desired display.
The object program consists of a sequence of binary format control words (FCW's) and a control interface block (CIS). The FCW's are DEU instructions for display generation. The CIS contains information required to update the generated FCW's with values that are functions of dynamic data available at the time the FCW's are loaded or being executed in the DEU memory. Inputs to the SAV-D language processor are a source program written in DDL and an optional DEU character-set reassignment file . The source program may contain two types of DDL statements. Normal SAV-D statements permit the programer to describe a display symbolically, without concern for the instruction set available on the DEU. Symbolic FCW statements permit direct programing of the hardware by providing a facility to express FCW's to be executed by the DEU. SAV-D assigns a CRT symbol and symbol name to each hexadecimal DEU code . The programer may override these assignments, either selectively or completely, by supplying his own reassignments . The reassignment consists of a symbol name and single character code representation (if one exists) for each hexadecimal DEU code to be reassigned.
The language processor outputs an executable object program, directives for real-time modification of the program, and listings that help to resolve problems with unsatisfactory displays. The object program is loaded in the DEU memory, is updated with real-time values, and is executed to produce the desired display. The DEU in the Space Shuttle system interfaces the ISM AP101 with the Multifunctional CRT Display System (MCDS).
The SAV-D program is written in FORTRAN IV for execution in the batch mode and has been implemented on an ISM 370 1165 with a central memory requirement of approximately 500K (decimal) of 8-bit bytes.
This program was written by Arthur A. Yoshimura of Rockwell International Corp. for Johnson Space Center. For further information, Circle E on the COSMIC Request Card. MSC-16591

NASA Tech Briefs, Summer 1977

The information about the DEU capabilities fit to the FCOS software specification, I suspect SAV-D really entered use later. Maybe having something similar could also help us in that department.
 
I have spent the last days working the SSUWorkbench so it can do some "basic" stuff like load/edit/save scenarios and mission files... it's still +/- far away, but the ball is rolling.
The idea that I have to get the load/edit/save done is to have a "Mission" object that contains the mission data (duh!), it is loaded from the files (or saved to) by another class that handles all the file parsing and IO, and also the window controls that allow editing of the data in the "Mission" object. Now, I'm a bit lost in this last part: connecting the "Mission" to the controls. Should it all be binded (still learning how to do it) or should there be another class to interface them?

BTW: where did the save icons come from? We are missing the open icon, so we should get a matching par.
 
Now, I'm a bit lost in this last part: connecting the "Mission" to the controls. Should it all be binded (still learning how to do it) or should there be another class to interface them?

As far as I can tell, binding suitable data models to the views makes most sense there. Those can still delegate to other entities.
 
I'm adding new RHC/THC logic*, but I have a doubt about the switch RM process(es): is there one "big" process that deals with all the switches that are monitored by the GPCs, or are there "small" processes dedicated to a set of switches? I think there are "small" processes, but then I see references to a "GNC SW RM", which sounds big....


*) if all goes well, I'll put it to work first in the Ascent DAP (say hello to manual RTLSs!), and then the other DAPs should be switched to the new stuff.
 
I'm adding new RHC/THC logic*, but I have a doubt about the switch RM process(es): is there one "big" process that deals with all the switches that are monitored by the GPCs, or are there "small" processes dedicated to a set of switches? I think there are "small" processes, but then I see references to a "GNC SW RM", which sounds big....


*) if all goes well, I'll put it to work first in the Ascent DAP (say hello to manual RTLSs!), and then the other DAPs should be switched to the new stuff.

Relatively small processes, from what I can tell. GNC SW RM is responsible for the switches referenced by the GNC major function, but not for switches used by other major functions or by the DPS itself.

But the processes can't be too small, because the PASS only allows a limited number of processes at a time (32 if I remember correctly per PASS GPC).
 
Last edited:
Relatively processes, from what I can tell. GNC SW RM is responsible for the switches referenced by the GNC major function, but not for switches used by other major functions or by the DPS itself.

But the processes can't be too small, because the PASS only allows a limited number of processes at a time (32 if I remember correctly per PASS GPC).

For the RHC and THC there would be 4 processes then: 1 RM and 1 SOP for each.
 
For the RHC and THC there would be 4 processes then: 1 RM and 1 SOP for each.

Possibly yes, I am not sure if all three pairs are done by the same SOP and RM processes, which should be possible.
 
So, after weeks pulling my hair out over the redundancy management stuff I gave it up for now... :( I still don't have the full picture of how the signals are made available in the GPCs and how they can fail in there, to use the (small) knowledge I have about RM. There are 2 new displays that show the signals from RHCs and THCs, but the channel deselection capability is not used.
So for now the RHC RM just assumes all is good and just passes the signals to the RHC SOP, where they are available for use by the DAPs.
To prove that this new setup works I did a few changes to the AscentGuidance (now AscentDAP, although I find very little references to this name... I'm using it to serve as an umbrella to the ascent stuff and later to the PRTLS stuff), and separated guidance from the command output, so now we have CSS control available during ascent! Did an RTLS "by hand" to test it... the crew had to bailout over the Gulf of Mexico as I clearly did the PPA too early. :lol:
I also "cleaned the house" on the panel F2/F4 FCS switches, that for some reason we were assuming were smart when in fact they are dumb. The FCS status is now saved by the DAPs and not by the switches.
I still have to finish the THC code, the Aft RHC and THC axis stuff and a few more things before committing the changes, but it's not that far away now.

---------- Post added at 04:13 PM ---------- Previous post was at 04:09 PM ----------


I had that for sometime and already did the math to get the (approximate) RGB numbers and that's what we are using for a while now. The only thing missing is the blue background of the screens... I'll look into that sometime in the future.
 
You do know that a single switch in the cockpit represents actually three switches in electrical circuits and results in three bits in a 16 bit data word from a MDM?

EDIT: BTW, the "Ascent DAP" is actually just another flavor of PEG, at least in the early design documents. I doubt there is anything with the symbol name "ASCENTDAP" in HAL/S. It is like all guidance in the STS, not a single program, but rather a software suite of multiple parallel processes running behind a OPS display application process.
 
Last edited:
You do know that a single switch in the cockpit represents actually three switches in electrical circuits and results in three bits in a 16 bit data word from a MDM?

Yes, I know the switches have either 2 or 3 contacts, and they go into a MDM at the port type "whatever" (I don't remember), and it's read by the GPCs. The RHC signals connect into a different port type for A/D conversion. What I don't know is how the GPCs can detect that an A/D signal failed just by looking at it, without comparison with others. Are the GPCs waiting a signal between -100 and +100, and is it possible that the MDMs send +104.7, and that's how the failure is detected? That is what is messing up my understanding of the RM logic. The rest is lots of thick logic but it all makes sense. I still haven't looked in detail at how the "switch RM" works, so it might be possible to do the THC RM (it uses the same logic as the switches).
Anyway, it's not critical as we don't have failures yet, I just wanted to get ahead.
 
Playing with the THC and its mess of axis, I'm finding that we need to set in stone what each key press means in relation to the THC "stick" movement. IMO the relationships should be this:
(numkey/stick movement)
9/in
6/out

2/down
8/up

1/left
3/right


This arrangement uses the relative key positions the same way as the THC movements, which produced translations in the chosen direction.
In practice, the post ET sep +X translation, for example, would now be done pressing the numkey 9 instead of 6.... press the forward key to go forward. Yes it's a change, but it makes sense when taking into account what the real THC was and how it was used. I'll even make a diagram for the manual depicting what key to press to move the THC (or the RHC) this or that way.

Any complaints about this? (especially from joystick users... if there are any THC-like joysticks out there)
 
Yes, I know the switches have either 2 or 3 contacts, and they go into a MDM at the port type "whatever" (I don't remember), and it's read by the GPCs.

Not port type... card type DIL (discrete input low voltage). Module x, channel y then. I think the RHC and THC are also the few places where the AID (analog input, differential voltage) is used, because you need to represent negative values there. The difference between two analog lines is then turned into a 10 bit signed integer. (and some bits status data about the A/D-converter)

Please tell me I have not forgotten finishing the MDM implementation again. I remember seeing the diagrams for the EMDMs and realizing the GPC view of them is not the whole truth....
 
Not port type... card type DIL (discrete input low voltage). Module x, channel y then. I think the RHC and THC are also the few places where the AID (analog input, differential voltage) is used, because you need to represent negative values there. The difference between two analog lines is then turned into a 10 bit signed integer. (and some bits status data about the A/D-converter)

Please tell me I have not forgotten finishing the MDM implementation again. I remember seeing the diagrams for the EMDMs and realizing the GPC view of them is not the whole truth....

The THC is just like 6 switches (with 3 contacts each) so it connects like a switch. The RHC is one wire only, per signal (with 9 signals in total), with a voltage between -15v and +15v, so it's not that AID but the other type that only uses one wire and compares it to 0v (I don't remember the name and don't want to look it up right now).
Currently I'm using -1v to +1v for the RHCs, and 0v or +1v for the THCs. When we get the MDMs running we'll set the correct voltages and square away the details.
 
The THC is just like 6 switches (with 3 contacts each) so it connects like a switch. The RHC is one wire only, per signal (with 9 signals in total), with a voltage between -15v and +15v, so it's not that AID but the other type that only uses one wire and compares it to 0v (I don't remember the name and don't want to look it up right now).
Currently I'm using -1v to +1v for the RHCs, and 0v or +1v for the THCs. When we get the MDMs running we'll set the correct voltages and square away the details.

I'll take a look there. After all, the MDMs exist for making our developers lives easier. I just can't tell that any GPC model will be done soon.

Which compilers are in use right now? Can I already use C++11 standard or do I need to care for compatibility?
 
I'll take a look there. After all, the MDMs exist for making our developers lives easier. I just can't tell that any GPC model will be done soon.
Please do that work in the beta branch, as to not delay even further the 4.0 release with new stuff that needs time to be tested before releasing.

Which compilers are in use right now? Can I already use C++11 standard or do I need to care for compatibility?
I'm using vs2013 but I still have vs2010, which I'm just keeping for the trunk (SSU 4.0). As soon as that's out the door and the beta branch becomes the trunk, I'll uninstall it.
 
I'm using vs2013 but I still have vs2010, which I'm just keeping for the trunk (SSU 4.0). As soon as that's out the door and the beta branch becomes the trunk, I'll uninstall it.

Yes, I would recommend it, that we are at least working on the same standard there. We should also write it into the docs.

For the rest of visual studio madness, we could also transition to CMake, which can generate Visual Studio project files for any version found on the PC.
 
I just committed the RHC and THC upgrades. Here's the promised diagram with the key usage:
RHC_THC_keys.png

Now it's really "move the stick in the direction you want to go".
The THC is fully updated and the old code has been deleted, but the "new" RHC is only used by the AscentDAP. The OrbitDAP and AerojetDAP are still using the "old" RHC data (a ticket has been created for that).
Also, as I corrected the implementation of the FCS mode PBIs, I added the LT MODE "test" to MM801, so we can turn them on and off.
BTW: please be careful with CSS during ascent... :lol:
 
No all we need is a true THC.
 
Status
Not open for further replies.
Back
Top