SSU Development Thread (3.0 to 4.0)

I thought the orbiter had a lockout just for that on the aft deck panels to prevent inadvertent deployment with the doors closed. Or am I confused with something else?
No lock-outs anywhere on orbiter. I think you're confusing it with lock-outs that are implemented in Shuttle Fleet add-on.

---------- Post added at 11:13 AM ---------- Previous post was at 11:08 AM ----------

GLS, can you make "inhibiting the deployment of the Ku-Band antenna" a SpaceShuttleUltra.cfg configuration file option? In reality, it would be possible to deploy the Ku-Band antenna even with closed Payload Bay (or stowed OBSS) ... of course resulting in damage in various magnitudes, from just a bend antenna dish to LOCV.
This is 100% correct. The Ku band DA can be operated even with the starboard PLBD closed. All that would happen was that the CBs for MMCAs 2 and 4 would pop open as the deployment actuator would use to power in attempting to move.
 
This is 100% correct. The Ku band DA can be operated even with the starboard PLBD closed. All that would happen was that the CBs for MMCAs 2 and 4 would pop open as the deployment actuator would use to power in attempting to move.

Not just that. I remember that somewhere is a warning to not activate the Ku Band antenna with closed payload bay or before deployment, because it could make the gimbal actuators of the antenna explode and damage the Space Shuttle.

Also, even before the CBs pop, you can cause serious damage to the payload bay door structure because the deployment actuator has a lot of torque.
 
GLS, can you make "inhibiting the deployment of the Ku-Band antenna" a SpaceShuttleUltra.cfg configuration file option? In reality, it would be possible to deploy the Ku-Band antenna even with closed Payload Bay (or stowed OBSS) ... of course resulting in damage in various magnitudes, from just a bend antenna dish to LOCV.

I added the change yesterday because of this on SCOM:
The antenna is locked in the stowed position to clear the adjacent payload bay doors and radiators when they are closed or moving.

I don't see the point of adding such option, and probably no one would use it. If that statment on SCOM is correct, then we are correct IMO. If that is wrong and there's no lock, we just remove yesterday's change.
 
I added the change yesterday because of this on SCOM:
The antenna is locked in the stowed position to clear the adjacent payload bay doors and radiators when they are closed or moving.

I don't see the point of adding such option, and probably no one would use it. If that statment on SCOM is correct, then we are correct IMO. If that is wrong and there's no lock, we just remove yesterday's change.

My understanding: We should remove it, because it is technically wrong. But we could keep it, since it could make SSU more beginner friendly.
 
My understanding: We should remove it, because it is technically wrong. But we could keep it, since it could make SSU more beginner friendly.

This "locking" (if it exists) would be done very simply in the switch on panel R13L, using the same signal that drives the PLBD talkback. But being easy or hard doesn't change reality.
Where is that warning about deploying the DA with the doors closed?

BTW: can anyone point me to where there's the diagram of the antenna obstructions with the orbiter parts indicated? I saw that somewhere but now I can't find it :facepalm:.
 
This "locking" (if it exists) would be done very simply in the switch on panel R13L, using the same signal that drives the PLBD talkback. But being easy or hard doesn't change reality.
Where is that warning about deploying the DA with the doors closed?

BTW: can anyone point me to where there's the diagram of the antenna obstructions with the orbiter parts indicated? I saw that somewhere but now I can't find it :facepalm:.
I think you might be referring the obscuration masks available on MM201 SM ANTENNA. They can be found in the Ku band system workbook, starting in section 5. There's no other parts than the starboard PLBD that the DA can come into contact with. There were some concerns on STS-114 that the dish might brush against the FWD end of the OBSS so deployment and activation was delayed from post-insertion on FD1 until after OBSS unberth on FD2. This was fixed on STS-121 and subsequent flights by moving the OBSS and the starboard MPMs a couple of cm further aft. This created the required clearance between the the dish and the OBSS.
 
I think you might be referring the obscuration masks available on MM201 SM ANTENNA. They can be found in the Ku band system workbook, starting in section 5. There's no other parts than the starboard PLBD that the DA can come into contact with. There were some concerns on STS-114 that the dish might brush against the FWD end of the OBSS so deployment and activation was delayed from post-insertion on FD1 until after OBSS unberth on FD2. This was fixed on STS-121 and subsequent flights by moving the OBSS and the starboard MPMs a couple of cm further aft. This created the required clearance between the the dish and the OBSS.

The ODB also contains them, in the format that was used for implementing them in PASS. As table of coefficients and function classes to describe a set of lines that form the mask.
 
Found it! SODB, that's were I saw it.

---------- Post added at 12:26 PM ---------- Previous post was at 12:06 PM ----------

I fixed the ExtAL.msh, centering the hatch windows with the ODS target. Also got rid of the inside window, because it was grey.

Who wants it ?

You'll have to talk to DaveS as he did some work there recently.
 
I didn't know that. Never mind.
Yes, I fixed a few issues with the airlock as well as the TAA. Here's the list of the change-list:

  • Adjusted airlock height by 17 cm to align properly with the bulkhead hatch
  • Fixed the misaligned handrails on the airlock truss
  • Properly mapped the texture of the TCS
  • Moved the TAA up 17 cm to account for the new airlock height


---------- Post added at 05:31 PM ---------- Previous post was at 03:53 PM ----------

There were some concerns on STS-114 that the dish might brush against the FWD end of the OBSS so deployment and activation was delayed from post-insertion on FD1 until after OBSS unberth on FD2.
I have located a photo that shows the pre-flight clearance concern. It's about mid-page: http://photo.net/nikon-camera-forum/00C7fb

---------- Post added at 05:31 PM ---------- Previous post was at 05:31 PM ----------

There were some concerns on STS-114 that the dish might brush against the FWD end of the OBSS so deployment and activation was delayed from post-insertion on FD1 until after OBSS unberth on FD2.
I have located a photo that shows the pre-flight clearance concern. It's about mid-page: http://photo.net/nikon-camera-forum/00C7fb
 
I need some info on the Ku band antenna:
1) confirmation that the mesh is at EL=-29 AZ=-125
2) where exactly does EL=0 AZ=0 point to???
3) what are the ranges for alpha, beta, EL and AZ for the gimbal equations? I'm using alpha -180/180, beta -81/81, EL -90/90 and AZ -180/180, but the movement it doesn't look right.
4) reading SCOM there seems to be a 7º offset between the beta gimbal and the antenna... is this correct?
 
1)It should be.
2)According to the graphic on page 5-8 of the Ku band ops workbook, EL/AZ 0/0 is straight up along the Z axis. the photo below shows the dish at 0/0.
3)Once again, graphic from the workbook is below.
4)The 67° offset is between the alpha gimbal boom and the orbiter X-axis.

Gimbals at EL/AZ 0/0:
iss011e11277.jpg


Ku band gimbals movement limits:
Ku_bd_gimbal_angle_limits.jpg
 
1) Would have to be answered by somebody else.

2) where exactly does EL=0 AZ=0 point to???

Straight forward (+Z in Orbiter).

3) what are the ranges for alpha, beta, EL and AZ for the gimbal equations? I'm using alpha -180/180, beta -81/81, EL -90/90 and AZ -180/180, but the movement it doesn't look right.


alpha: -206° ... +154°
beta: -85° ... +75°

EL: -90° ... +90°
AL: -180° ... + 180°

0° Alpha and 0° beta is the same as 0° EL and 0° AL, that is the only position in which both coordinate systems converge.


4) reading SCOM there seems to be a 7º offset between the beta gimbal and the antenna... is this correct?

Only between the two assembles.

The beta angle is not 7° offset from the antenna vector (the 7° are rather included into the definition)
 
1) Would have to be answered by somebody else.
Straight forward (+Z in Orbiter).
Ku_bd_atenna_az_el.jpg


---------- Post added 09-08-15 at 12:53 AM ---------- Previous post was 09-07-15 at 08:43 PM ----------

Could someone check that the oapiVCSetAreaClickmode bug reported here has been fixed in Orbiter beta rev. 16?
 
Could someone check that the oapiVCSetAreaClickmode bug reported here has been fixed in Orbiter beta rev. 16?

Let me check.

---------- Post added at 12:16 AM ---------- Previous post was at 12:02 AM ----------

Seems to work well now, no problems detected so far. :hailprobe:

---------- Post added at 12:58 AM ---------- Previous post was at 12:16 AM ----------

Martin just did us a big favor and fixed both the panel mouse event and the external camera issues we were having. :hailprobe:

---------- Post added at 04:07 PM ---------- Previous post was at 12:58 AM ----------

Any data on the antenna slew rates (both manual using the A1U switch and auto for stow)?

---------- Post added at 04:10 PM ---------- Previous post was at 04:07 PM ----------

Also, the Ku power switch Standby position, should I take that as On, Off or what does it do exactly?
 
Ku band slew rates:
Fast: 20°/s
Slow: 0.4°/s

System power modes:
ON: This position fully activates the Ku-band system
after the DA is deployed. It provides signal
power to the manual slew switches, the antenna
steering mode switch, the radar/comm mode
switch, the search switch, and the Panel A2
digital readouts. Approximately 2 minutes after
positioning this switch to ON, antenna steering
control may be exercised, but the radar
transmitter is not enabled for another 2 minutes

STBY: This position initiates the timeouts, but
transmitter power is inhibited; ac power is
removed from the gimbal motors.

OFF: Ku-band power removed.
 
Since martins now had implemented a feature for higher MFD resolution and vessel-MFDs, maybe we should start a beta-branch for instantly testing the changes with SSU, after all, he had also been reacting pretty fast to our requests.

What do you think?
 
Since martins now had implemented a feature for higher MFD resolution and vessel-MFDs, maybe we should start a beta-branch for instantly testing the changes with SSU, after all, he had also been reacting pretty fast to our requests.

What do you think?
I think this is a good idea. It should allow us to test things in a good environment.
 
Back
Top