Space Shuttle Ultra 1.25 Revision B development

[Donamy]

"Failure, is not an option."

 

[Urwumpe]

"Failure, is not an option."

Not in Orbiter. Here it is optional. :lol:

 

[DaveS]

The singularities only occur when vectors a and t are either parallel or anti-parallel. Just check for that by calculating the beta angle first. If it is within its range of motion (2 to 164 deg) then you are safe to calculate the alpha angle, otherwise declare a beta-out-of-range and do not move the gimbals at all (beta and alpha).

EDIT: You may also have an issue (presumably it is a real life one) near alpha=0. Slight changes in the target direction could cause the required alpha angle to oscillate between just greater than 0 and just less than 360. I'm not sure how they handle that IRL, to stop the antenna slewing all the way around. Some sort of time delay to give the antenna a chance to lock back in before it decides to move? Also, I forgot to mention that the formula for alpha will give a result in the range -180 to +180. You will want to normalise that to 0 to 360 (the zero direction remains the same) to match the real life operation of the alpha gimbal.

Here's a document that should hopefully clear up the Ku antenna gimbal angles.

 

[DaveS]

I found another graphic re: KU band antenna gimbal angles. I'll post it tomorrow when I have finished reading the KU band workbook.

The graphic shows the various angles (elevation/azimuth) nicely WRT to the orbiter coordinate axes.

Hopefully with these graphics, we'll get the KU band system up and running in no time.

 

[DaveS]

Here's that graphic with some explanations:

 

[Urwumpe]

Am I understanding this correctly, that EA1 accepts azimuth and elevation angles, and calculates suitable alpha/beta angles?

 

[DaveS]

Am I understanding this correctly, that EA1 accepts azimuth and elevation angles, and calculates suitable alpha/beta angles?

Yes. The elevation/azimuth as displayed on A2 is derived through a trigonometric transformation of the alpha/beta gimbal angles in the EA1 microprocessor. The transformation is necessary as the DA is offset 67° from the orbiter X-axis in the deployed configuration.

Checked in the Ku band ops workbook where these graphics came from.

 

[Urwumpe]

Yes. The elevation/azimuth as displayed on A2 is derived through a trigonometric transformation of the alpha/beta gimbal angles in the EA1 microprocessor. The transformation is necessary as the DA is offset 67° from the orbiter X-axis in the deployed configuration.

Checked in the Ku band ops workbook where these graphics came from.

Yes, I remember having the formula for the transformation somewhere already. I just seek the Operational Data Handbook for information about the interface between EA1 and the PL MDMs.

Also I had the 0/0 direction wrong, thought 0/0 is forward, not upward.

 

[DaveS]

Yes, I remember having the formula for the transformation somewhere already. I just seek the Operational Data Handbook for information about the interface between EA1 and the PL MDMs.

Also I had the 0/0 direction wrong, thought 0/0 is forward, not upward.

If I'm not entirely mistaken, this photo here from STS-112/9A shows the Ku band antenna in the 0/0 position: http://spaceflight.nasa.gov/gallery/images/shuttle/sts-112/hires/iss005e16514.jpg

BTW, where is the code for the Ku band antenna deploy limit that prevents it from being deployed unless both PLBDs are open? I was thinking about changing that so that the antenna can be deployed even if only the starboard PLBD is fully open.

The reason for this change is that on STS-73 the orbiter spent most of the mission in a GG attitude with the port wing facing the VV. So they positioned the port PLBD at a 62° open angle to use it as MMOD sheild while the starboard PLBD was fully open.

They only opened the port PLBD to perform Spacelab water dumps which required the port PLBD to be fully open. After the dump was complete, the port PLBD was returned to the 62° angle.

 

[Urwumpe]

Yes, that antenna is approximately in 0/0.

BTW, where is the code for the Ku band antenna deploy limit that prevents it from being deployed unless both PLBDs are open? I was thinking about changing that so that the antenna can be deployed even if only the starboard PLBD is fully open.

The reason for this change is that on STS-73 the orbiter spent most of the mission in a GG attitude with the port wing facing the VV. So they positioned the port PLBD at a 62° open angle to use it as MMOD sheild while the starboard PLBD was fully open.

They only opened the port PLBD to perform Spacelab water dumps which required the port PLBD to be fully open. After the dump was complete, the port PLBD was returned to the 62° angle.

Not sure if we have such code, but I can look at this. Is there really an interlock or is the protection in the brains of the astronaut? Because I don't see any override switch, which would allow deploying the antenna if the interlock fails.

In the mean time, can you look how the KU hardware is connected to the PL MDMs (which kind of I/O cards)? I am sure you have better information about it, the Operational Data does not tell much about EA1 and EA2.

(I think about using the single SM GPC as test bed for my DPS concepts, so the parts we have happily working, the GNC functions, can be done in SiameseCats code... would cause less breaking for a while.)

 

[DaveS]

Not sure if we have such code, but I can look at this. Is there really an interlock or is the protection in the brains of the astronaut? Because I don't see any override switch, which would allow deploying the antenna if the interlock fails.

Well, something code-wise is preventing the antenna from deploying if the doors aren't completely open.

In the mean time, can you look how the KU hardware is connected to the PL MDMs (which kind of I/O cards)? I am sure you have better information about it, the Operational Data does not tell much about EA1 and EA2.

Well, I checked the Ku band Ops workbook over and I can't seem to find any connections between the Ku band system EAs and the PL MDMs. The only connection the Ku band system has with the PL MDMs is through the SM GPC.

BTW, I did check in the Ku band Ops workbook, so you can study it. It is in Doc\Space Shuttle Ultra\Tech Notes\KU OPS 21002.pdf

 

[Urwumpe]

Well, something code-wise is preventing the antenna from deploying if the doors aren't completely open.

Yes, I know, I am not sure though, how it is handled in the real thing. The SCOM mentions that it is locked in stowed position when the adjacent door is moving, so it only applies to the starboard door. The moving makes me feel troubled though - is the door locked from moving when the Ku Band antenna is not stowed, or is the Ku Band Antenna stowed when the door closes?

Well, I checked the Ku band Ops workbook over and I can't seem to find any connections between the Ku band system EAs and the PL MDMs. The only connection the Ku band system has with the PL MDMs is through the SM GPC.

According to the diagrams, the connections between SM GPC and GCIL is the PF1 or PF2 MDMs. Commands from the ground go from NSP1 or NSP2 via FF1 or FF3 to the GNC GPCs.

BTW, I did check in the Ku band Ops workbook, so you can study it. It is in Doc\Space Shuttle Ultra\Tech Notes\KU OPS 21002.pdf

OK, I am reading through it.

 

[DaveS]

or is the Ku Band Antenna stowed when the door closes?

The way I have seen it in KSC videos of PLBD closure in the OPF, is the port door is always closed and latched first then the Ku band antenna is stowed after which the starboard door is closed and latched.

I also found the code that is controlling this. It's line 272 in PLBayOp.cpp. Commentating that one out allows the DA to be operated independently of PLBD status.

 

[Urwumpe]

I'll do some work-arounds there this night, I think it is time that I just guess the GCIL. If I am wrong, somebody can kill me later for it.

 

[DaveS]

I'll do some work-arounds there this night, I think it is time that I just guess the GCIL. If I am wrong, somebody can kill me later for it.

For a first implementation, I think we should at least get the DA deployment and stow operations right. I don't think there's any interlocks between the KU band DA and the doors other than physical ones, IOW move the DA when the door isn't open enough and you're going to hit the radiator panel.

Same thing as with the OBSS and RMS. The only CAUTION note I can find is in the generic Orbit Ops C/L about that the OBSS MPMs needed to be stowed before deploying/stowing the DA to prevent DA/OBSS contact.

 

[Urwumpe]

For a first implementation, I think we should at least get the DA deployment and stow operations right. I don't think there's any interlocks between the KU band DA and the doors other than physical ones, IOW move the DA when the door isn't open enough and you're going to hit the radiator panel.

There are microswitches that signal that a payload bay door is fully open, it should be possible to have a interlock for the starboard door only. A simple logical operation with the input signals for the MCA would be enough to stop the deployment servo motor from operating in the deploy direction: StopDeploy = DADeployed or not PayloadBayOpen.

EDIT: But then, it would be impossible to deploy the DA if the doors don't signal open and the motors are stopped manually.

Same thing as with the OBSS and RMS. The only CAUTION note I can find is in the generic Orbit Ops C/L about that the OBSS MPMs needed to be stowed before deploying/stowing the DA to prevent DA/OBSS contact.

Yes, but that is maybe different because the OBSS had been included later in the program.

---------- Post added at 10:14 PM ---------- Previous post was at 09:53 PM ----------

from the Generic Flight Rules:

A11-55 LOSS OF KU-BAND

LOSS OF KU-BAND WILL RESULT IN THE FLIGHT CONTINUING TO NOMINAL EOM. IF THE MISSION-SPECIFIC CAPABILITY JUSTIFIES THE REQUIREMENT FOR THE KU-BAND, PERFORM AN MDF.

Refer also to mission-specific rules that may be documented in Flight Rules Annexes.

Ku-band communication is provided primarily to support payloads. It is used to provide supplemental capabilities unavailable via the prime S-band communications system such as TDRS television, TDRS recorder dumps, OCA, and high rate payload data. Generally speaking, other useful mission objectives can be accomplished even with the loss of these capabilities and, therefore, early mission termination is not justified. The Ku-band system also provides the only source of rendezvous radar capability, but alternate onboard and ground capabilities allow rendezvous to continue in the event of radar failure.

Specific mission objectives that cannot be accomplished with a loss of Ku-band are identified in the Flight Rules Annex. ®[021998-6516 ] ®[012402-5068 ]

Rule {A11-1001}, COMMUNICATIONS GO/NO-GO CRITERIA, references this rule.

 

[DaveS]

Another thing that should be wired up relating to the Ku band antenna is hooking it up to the mission file as a selectable item just like the starboard MPMs and the RMS. The first 6 flights did not fly the Ku band DA. It was first flown on STS-7, the second flight of OV-099. OV-099 was also the first orbiter to have it the DA installed as it was delivered to KSC from Palmdale.

OV-101 and OV-102 were scarred for the Ku band DA but OV-101 never received one and OV-102 only get hers during the OPF turnaround flow for STS-9.

Edit:
It seems like the code to support this are there, it just isn't linked into the mission file code yet.

 

[Urwumpe]

It seems like the code to support this are there, it just isn't linked into the mission file code yet.

AFAIR, we simply assumed it to be there for simplicity, since making it a flexible mission item would require some rewrites of the code, to be releasable. Not impossible, but would take some time to clean the interfaces between EA1, EA2, SPA and DA...currently all is thrown into a single class, that would need to handle the separation by many ifs.

---------- Post added at 09:17 PM ---------- Previous post was at 02:10 AM ----------

DaveS, BTW, I found this caution block in the Workbook, that explains all we need to know:

CAUTION
Care must be taken to ensure that the payload bay doors are fully open before deploying or stowing the DA to avoid damage to the door, the radiator, or the DA itself.​

 

[DaveS]

DaveS, BTW, I found this caution block in the Workbook, that explains all we need to know:

CAUTION
Care must be taken to ensure that the payload bay doors are fully open before deploying or stowing the DA to avoid damage to the door, the radiator, or the DA itself.​

I guess we then can remove the limit code then as the operation responsibility is on the crew.

 

[Urwumpe]

I guess we then can remove the limit code then as the operation responsibility is on the crew.

Exactly. We can put a limit code in again, if we do artificial crew members some day, but that is currently not needed. The work book is pretty nice, contains a lot of information that was currently just guess work on my side.

---------- Post added 01-05-11 at 12:51 AM ---------- Previous post was 01-04-11 at 09:37 PM ----------

One other thing, what about unifying the vc meshes a bit more and get higher performance from the new Orbiter 2010 features?

The talkbacks could for example be done by using a single rectangular (2 triangles) mesh group for each, all talkbacks using the same static texture, and the state is displayed by changing the texture coordinates of each of the four vertices.

The same is possible with light and number displays. In theory, all indicators could use the same large texture, we wouldn't even need any special structure of the objects in the texture, if we use static lookup tables.

Since we no longer paint on that many textures then, the frame rate should improve a lot. The next thing would be finally getting all objects in the VC being standardized, so we don't need that many specialist code or special cases. currently only the switches permit real standard code.

What do you think?

I just work on implementing panel A1U (Ku antenna controls).