SSU Development Thread (3.0 to 4.0)

[GLS]

GLS: How far along are with the Ku band system? I'm looking forward to having a new system to learn.

It's going to take a while . I'm currently re-doing the boom deploy/stow stuff using the new info from the electrical diagram. Then I need to organize things in EA-1 and DA. It did the stow properly a few days ago, but things weren't in the proper places. Panel A2 has the 7-disp done, but it's still missing the other part for the rates. Panel A1U is still missing the talkbacks.
From tomorrow SSU is no longer "the only show in town", so progress is going to slow down. I'm thinking of having a "test" version committed sometime in the future, with just deploy/stow and makeshift manual slew parts working so that the "baseline system" can be tested.
Then I'll add the radar part, which will take some work, as to have the correct detection, or not, of a target at X distance, one has to take into account the power emitted (in the direction of the target), distance to the target and signal reflection on the target, which will have to simplified to a "standard" reflection coefficient but still using the target size (provided by Orbiter). Let's hope there's enough info to do it like that.

 

[DaveS]

Here's some documents on the Ku band RR I have found on NTRS:

Development of Ku-band rendezvous radar tracking and acquisition simulation programs

Ku-Band rendezvous radar performance computer simulation model

Shuttle orbiter Ku-band radar/communications system design evaluation

Shuttle orbiter Ku-band radar/communications system design evaluation. Deliverable test equipment evaluation

KU-Band rendezvous radar performance computer simulation model

 

[Urwumpe]

It's going to take a while . I'm currently re-doing the boom deploy/stow stuff using the new info from the electrical diagram. Then I need to organize things in EA-1 and DA. It did the stow properly a few days ago, but things weren't in the proper places. Panel A2 has the 7-disp done, but it's still missing the other part for the rates. Panel A1U is still missing the talkbacks.
From tomorrow SSU is no longer "the only show in town", so progress is going to slow down. I'm thinking of having a "test" version committed sometime in the future, with just deploy/stow and makeshift manual slew parts working so that the "baseline system" can be tested.
Then I'll add the radar part, which will take some work, as to have the correct detection, or not, of a target at X distance, one has to take into account the power emitted (in the direction of the target), distance to the target and signal reflection on the target, which will have to simplified to a "standard" reflection coefficient but still using the target size (provided by Orbiter). Let's hope there's enough info to do it like that.

No problem, my semester also starts next week, but I am confident that I can still do some progress here (Because "Algorithms and Data Structures" and "Databases" are just done a second time in my life to get a better grade for the final exams, only "business law" will be some real effort)


I am still sorting through the DPS schematics here, some stuff is really interesting, some other stuff is sadly still missing there (for example the official list of format command words and not the 4.0 version of my reconstruction). Some more reference material about the DEU would really be nice.

The CRT schematic was really interesting. I thought it just uses a grid template to draw letters, numbers and symbols inside the tube. Wrong. A character symbol generator creates them as line art which is then fed through a full analog projection system, which calculates the deflection and intensity signals to draw them, including translations and rotations.

Right now, I only know the register sizes and available options that the DEU electronics supported to be set for each drawing command.

Also, the schematics confirm at least that the interface between DEU and GPC did not change between the ALT tests and the schematics, the data structures are still the same.

---------- Post added at 06:22 PM ---------- Previous post was at 02:07 PM ----------

Interesting information found:

The drawing "13 EMDM 1" contains a table with the IO module configuration for each type of EMDM, including the OI MDMs.

---------- Post added at 08:47 PM ---------- Previous post was at 06:22 PM ----------

Started to write a pdfTex file about what concept I have in mind for the DPS changes. This way I can also concentrate the research results in a single PDF file for reference.

 

[Donamy]

How do you clear the reach limit error, on the RMS ?

 

[GLS]

How do you clear the reach limit error, on the RMS ?

That should probably be removed... in the meantime just hit Ctrl+1 twice, and it will clear the debug output line.

 

[Urwumpe]

Does somebody have already access to AIAA2008-7693?

http://arc.aiaa.org/doi/abs/10.2514/6.2008-7693

It reads like it might be interesting for our current work.

 

[GLS]

Does somebody have already access to AIAA2008-7693?

http://arc.aiaa.org/doi/abs/10.2514/6.2008-7693

It reads like it might be interesting for our current work.

I don't.
BTW: these last posts should be in the dev thread, right?

 

[Urwumpe]

I don't.
BTW: these last posts should be in the dev thread, right?

We ARE in the dev thread. :tiphat:

 

[asdad]

GLS : Can you fix Payloadbay door ? because when i open Payloadbay door is become delay

 

[Urwumpe]

GLS : Can you fix Payloadbay door ? because when i open Payloadbay door is become delay

That is no bug, that is a feature. The real Shuttle behaves similar, since the various hooks and latches of the payload bay doors, which keep them closed during launch and reentry, have to be opened first.

 

[GLS]

GLS : Can you fix Payloadbay door ? because when i open Payloadbay door is become delay

That is no bug, that is a feature. The real Shuttle behaves similar, since the various hooks and latches of the payload bay doors, which keep them closed during launch and reentry, have to be opened first.

Just to add to what Urwumpe said: you can see the hooks opening/closing if you look thru the aft windows.

A small update on the (lack of) progress of the Ku band antenna: the panels are pretty much done and the "data flow" between the various classes is +/- established. The work remaining now is the EA-1 microprocessor code, that is neatly divided into functions (duh), but coming up with a system to choose what runs when, respecting the requirements, is the hard part.
I have a "mini-vacation" for the next 3 days or so, so I'll try to finish "part 1" of this (stow, deploy and man slew). "Part 2" (radar) will be done.... eventually.

 

[Urwumpe]

I hope that this weekend will finally allow some real progress towards the partition DPS model.

The first milestone there for me is getting the MDM behavior final (bite, status words, TACAN/RA modules, SIO). Based on that, I have then various ways to implement test scenarios.

One rather unpolished idea right now is to include a "Test program" keybinding into SSU, which allows us to execute numbered test sequences from HDD. Each test sequence could then be in the most primitive way a simple sequence of MDM commands (as the GPC would send), the replies of the MDM would be written into a result file. A good extension to this would be adding sequence control instructions (like wait x seconds) or structuring the tests, for example by describing the format of the replies in a human readable form.

---------- Post added 10-10-15 at 08:40 AM ---------- Previous post was 10-09-15 at 12:49 PM ----------

Thanks to amalahama, who provided a copy of the article about the bearing displays, I can now work with solid information about the MEDS modifications to the DEU rendering.

Essentially, for the bearing displays, two new drawing instructions had been added (that number was already known before), and two other instructions got modified. Important, and something that I would never have had to courage to guess: This set of changes also added the first 32 bit format control word to the flight software. All other such control words are just 16 bit words.

The first new FCW draws a static map of America, Europe and Africa.
A second 32 bit FCW allows defining landing site data to be drawn on the map. Since the labels would need collision detection (so they don't overlap) and it was not sure if the GPCs could handle this with their limited performance, the placement of the labels is calculated in the MEDS.

A modification of the select intensity instruction allows selecting all colours from the MEDS color palette.

Another modification (But the article does not say which old FCW was affected) allowed new characters to be used, which had not been in the DEU character set. I suspect it only added a new flag to one of the control registers.

Now I just have to get to that point again, first I will finish the general IO system, since the IDP interface also requires it.

Also we can then think about a way to include different flight software versions into SSU. Since we prefer a rather open architecture that could also be used for hypothetical shuttle configurations, I believe that a single string or number to describe the shuttle software is not enough (it would only work for historic software configurations and non-standard FSW would then have to be defined by us, instead of letting the SSU user have the final word). I have no final solution there yet, my current abstract model goes into the direction of using a list of software modules to choose from to assemble the FSW, with the actual software modules being written in C++ for performance.

 

[DaveS]

How about an status update? On my side, I took a break as I was seriously getting burnt out but now I'm back and I have completed some structural modifications to the IAA Support Structure. These were necessary as I tracked down the real position of the IAA itself relative to the structure.

 

[GLS]

On my end, I can't wait to pick up work again on the antenna, the MPS state save, the panel mesh separation and new lights/talkbacks, the upper stages.... But sadly that probably will not happen before January or February. :facepalm:

 

[Urwumpe]

How about an status update? On my side, I took a break as I was seriously getting burnt out but now I'm back and I have completed some structural modifications to the IAA Support Structure. These were necessary as I tracked down the real position of the IAA itself relative to the structure.

Similar here, the server software at work needed 6 emergency fixes in 8 weeks, luckily it seems to be over now and back to regular pace.

TODO:

1. Finish MDM code
2. port IDP rendering to DEU feature control words
3. Port existing software to new rendering

Still undecided about the user interface to the rendering. The most "native" way would be creating binary images of all the displays, for developing displays, it would be easier to have a human-readable format, that can be edited quickly. Also a symbolic listing for getting memory locations defined easier would be a good infrastructure. I think it would be good to develop some command line tools for this before doing #2.

 

[Donamy]

On my end, I can't wait to pick up work again on the antenna, the MPS state save, the panel mesh separation and new lights/talkbacks, the upper stages.... But sadly that probably will not happen before January or February. :facepalm:

I could help with seperating the panel meshes.

 

[GLS]

I could help with seperating the panel meshes.

IMO, that won't happen before the summer, probably even later, but there will be work for everybody don't worry :lol:.

 

[Urwumpe]

IMO, that won't happen before the summer, probably even later, but there will be work for everybody don't worry :lol:.

I can also do some work for that in the mean time, I should have a few days until summer. :lol:

 

[Urwumpe]

About how the real shuttle software is organized, there is a great simple example in the programming manual for HAL/S. I think it explains pretty well already, how the people who wrote the Space Shuttle software thought and how they solved problems in their software:

 

[GLS]

Just found this pearl that shows the FWC SRBs for STS 62-A.

Looks like we have to do some painting.