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

[Urwumpe]

So I have hit a bit of a stumbling block on a planned project. The problem is that I need two DPS SM displays, namely SM 211 and SM 212. The titles are SSE OVERVIEW and SSE MECHANISMS.

Is there anything known about how they look like?

 

[DaveS]

Data can be found in this document, page 274 (6-20): https://sourceforge.net/projects/shuttleultra/files/References/CSM125.pdf/download

 

[Urwumpe]

Data can be found in this document, page 274 (6-20): https://sourceforge.net/projects/shuttleultra/files/References/CSM125.pdf/download

Ah OK... I see.

 

[Wolf]

How does one change the TV ROLL (ITEM 5) in any of the OMS MNVR displays? I've tried the normal way (ITEM 5+xxx where xxx is the desired TIG roll angle) but always get an illegal entry error. This is a bit bothersome as it is always initialized as 180 (great for non-RTHU) but should be 0 for RTHU missions.

Sorry if I step in guys but I was about to post something on the exact same subject: actually I have no problem in changing the TV ROLL value in any MM (104-105-202-302 all work for me with no "ILLEGAL ENTRY" message). I can choose a head down or head up attitude for any burn and SSU will orient itself in the desired ATT. The only thing I noticed is in MM302 the TV ROLL input gets somehow inverted:
setting ITEM5 = 0 will orient SSU heads down where as setting ITEM5=180 will orient the shuttle heads up...
Does that mean in SSU the deorbit burn attitude is already programmed by default head down (hence inputting TV ROLL 180 will roll SUU head up)?

 

[GLS]

Sorry if I step in guys but I was about to post something on the exact same subject: actually I have no problem in changing the TV ROLL value in any MM (104-105-202-302 all work for me with no "ILLEGAL ENTRY" message). I can choose a head down or head up attitude for any burn and SSU will orient itself in the desired ATT. The only thing I noticed is in MM302 the TV ROLL input gets somehow inverted:
setting ITEM5 = 0 will orient SSU heads down where as setting ITEM5=180 will orient the shuttle heads up...
Does that mean in SSU the deorbit burn attitude is already programmed by default head down (hence inputting TV ROLL 180 will roll SUU head up)?

You are not using the latest revision, are you?

---------- Post added at 07:26 PM ---------- Previous post was at 07:08 PM ----------

So I have hit a bit of a stumbling block on a planned project. The problem is that I need two DPS SM displays, namely SM 211 and SM 212. The titles are SSE OVERVIEW and SSE MECHANISMS.

The project deals with the HST service equipment, mainly the FSS and some of the equipment carriers. For the best simulation, I think it would be best to integrate at least the FSS like we have done for the IUS and Centaur. The FSS is controlled through SSPs and both these SM displays.

The DPS part will have to wait for the "new hardware", but I can do the rest. The HST FSS is the same used for the SMM, right? Then we should (try to) handle it in a way that supports both sats (and maybe some planned ones as well).

 

[DaveS]

The DPS part will have to wait for the "new hardware", but I can do the rest. The HST FSS is the same used for the SMM, right? Then we should (try to) handle it in a way that supports both sats (and maybe some planned ones as well).

Yes, although it was heavily modified for HST duties. Alot of the service hardware was modified from previous duties. The MULE was the carrier structured for the Upper Atmosphere Research Satellite (UARS) carried and deployed on STS-48. The ORUC is a Spacelab Logistics Pallet (SLP) with the appropriate protective enclosures. Same for the Rigid Array Carrier (RAC) used to carry the new rigid solar arrays on STS-109/HST-SM3B.

 

[Urwumpe]

I am sure I can take a better look at the DPS hardware/software next year, after an overdue project switch in my paid work (3.5 years red alert is enough).

If you are planning a HST service mission - who will work on getting EVA working properly? We have a great EMU mesh, but we need coding....

 

[GLS]

One thing I'd like to change is the payload retention latches logic, so we can use them in the IUS, Centaur and now the FSS. Nothing occurs to me on how to rewire that system... :facepalm:

 

[Urwumpe]

One thing I'd like to change is the payload retention latches logic, so we can use them in the IUS, Centaur and now the FSS. Nothing occurs to me on how to rewire that system... :facepalm:

I know... it was a petty hack on my end, to make the switches work properly for typical Orbiter payloads, but it was not really designed for IUS or Centaur...

For that we would need some special payload logic type, that does not release the payload into space, but permits rotation...

 

[DaveS]

I know... it was a petty hack on my end, to make the switches work properly for typical Orbiter payloads, but it was not really designed for IUS or Centaur...

For that we would need some special payload logic type, that does not release the payload into space, but permits rotation...

Well, carriers use passive latches, not active ones so they can't float off into space. We need a way to wire the A6U switches/TBs to specific latches, this is how it worked on the real orbiters.

For the IUS, the A6U switches was connected to the PRLAs on the FWD ASE frame, not the ones that are usually mounted to the bridge panels. The ROEU was hooked up the same way.

 

[GLS]

I know... it was a petty hack on my end, to make the switches work properly for typical Orbiter payloads, but it was not really designed for IUS or Centaur...

Even if you had done it that way, probably someday something would appear that would use the latches in a different way... shuttle = lego for engineers.

For that we would need some special payload logic type, that does not release the payload into space, but permits rotation...

As we have a subsystem that has the upper stage attachment, if the latches are closed it would not allow the rotation of the table. The release logic would remain the same.

---------- Post added at 08:45 PM ---------- Previous post was at 08:43 PM ----------

Well, carriers use passive latches, not active ones so they can't float off into space. We need a way to wire the A6U switches/TBs to specific latches, this is how it worked on the real orbiters.

For the IUS, the A6U switches was connected to the PRLAs on the FWD ASE frame, not the ones that are usually mounted to the bridge panels. The ROEU was hooked up the same way.

Wiring the panel is easy, IMO the problem is what to do with the rest of the existing latch logic and subsystem. The ASE/CISS would implement their own latch logic to not allow rotation if the latches are closed.

 

[DaveS]

Wiring the panel is easy, IMO the problem is what to do with the rest of the existing latch logic and subsystem. The ASE/CISS would implement their own latch logic to not allow rotation if the latches are closed.

I think that would be the best way to go. They're special cases.

 

[Urwumpe]

I think that would be the best way to go. They're special cases.

Yes - we could generalize the problem though, by offering a special "rotation possible check" API. The most portable way would be via clbkGeneric there, but also the most complicated way to use.

 

[GLS]

One more thing to consider: ASE for PAMs... I don't know if they used latches, and it should be the same logic as for the IUS and Centaur, but it's another one to consider.

 

[Urwumpe]

One more thing to consider: ASE for PAMs... I don't know if they used latches, and it should be the same logic as for the IUS and Centaur, but it's another one to consider.

Passive latches AFAIR. The PAM itself had been on a spin table.

 

[DaveS]

Passive latches AFAIR. The PAM itself had been on a spin table.

All the ASEs used passive latches. The Centaur/IUS used active latches through but not the actual CISS/ASE.

 

[GLS]

I know the ASEs where attached to the Orbiter with passive latches, and that the PAMs were attached to a spin table, but the spin table had bolts to lock it (prevent spinning)... where those also controlled from the A6 switches?

 

[DaveS]

I know the ASEs where attached to the Orbiter with passive latches, and that the PAMs were attached to a spin table, but the spin table had bolts to lock it (prevent spinning)... where those also controlled from the A6 switches?

I'm pretty sure all the PAM activities were controlled from a SSP. I found this document: https://commons.erau.edu/cgi/viewcontent.cgi?article=2439&context=space-congress-proceedings

 

[Urwumpe]

I'm pretty sure all the PAM activities were controlled from a SSP. I found this document: https://commons.erau.edu/cgi/viewcontent.cgi?article=2439&context=space-congress-proceedings

Yes, and it just made my job harder. The SSP just controls the power distribution, every PAM payload had four CRT displays of its own back then. The SM GPC controlled the deployment. :lol:

 

[Wolf]

You are not using the latest revision, are you?

I am using rev 2727 but I just did a SVN update and not sure what I have now (got a strange error message).
How can I verify what rev I have now?