TRMM attitude processing algorithm

TRMM Attitude Processing - RevisedPeter NoerdlingerSpace Applications Corp.March 11, 1996; with Appendix 3 of May 25, 1996Release 2

1. Purpose:

Convert incoming data xerror, yerror, zerror and "flying mode" to Euler angles relative to inertial, geocentric orbital coordinates.

2. Definitions:

"Inertial" orbital is defined in the TK User's Guide. It has its Y axis along the negative orbit normal, Z towards geocentric nadir, and X the cross product of Y and Z. It is, of course, not truly inertial, itself - we mean that it uses position and velocity vectors defined in inertial space, as contrasted with Earth-fixed space.

The values xerror, yerror, zerror are defined in a "tipped orbital system" described in a paper "TRMM Yaw" by Tom Flatley dated Nov, 1992 and in Build 3, Version 2 TRMM ACS Algorithm Document, GSFC code 712.1, Aug 10, 1994. The tipped system has its yaw (z) axis along geodetic nadir. Its y and x axes are "tipped" from those of the inertial orbital coordinate system by a rotation about an E-W line that brings the z axis to geodetic nadir. There is further explanation of the algorithms and the geometry in the Theoretical Basis of the Science Data Processing Toolkit and in comments within the function $PGSSRC/CSC/PGS_CSC_TiltYaw.c.

Note that TRMM is referenced and controlled to approximate geodetic nadir and not to geocentric nadir; thus the values of xerror, yerror, zerror are expected to be small (< ~ +-0.2 deg)

3. Notation:

3.1 Spacecraft Axes: (x,y,z).

Unit vectors are denoted (i,j,k) when indexing is not needed;

e_m or e_n, etc., where m or n stands for an integer index when indexing is needed.

3.2 Orbital Reference Frame Axes: (x',y',z'). Unit vectors (i',j',k')

3.3 Tipped Orbital Reference Frame Axes: (x",y",z"). Unit vectors (i",j",k")

3.4 Altered Flying Mode Axes (Modes 1-4):

There are 5 flying modes (also denoted "TargetOrientation"), of which four are used: 0,1,3,and 4. All but mode 0 can be represented by rotations of TRMM about its own Z axis (yaw) provided that this rotation is done first. Thus, we choose the Euler angle order 3-2-1. This also matches the TRMM on-board attitude system, which processes the roll and pitch data as if there were no real change - that is why the flying mode is reported separately. Only the Sun sensor control referencing for yaw is sensitive to the change in flying mode, and there, too, the Euler angle order 3-2-1 is assumed in the processing. Therefore, our only action to take into account flying modes 1-4 will be to increment the yaw by the required amount.

3.5 Pitch Maneuver (Mode 0):

The spacecraft will occasionally execute a 360 degree pitch maneuver, which is specified in more detail in Appendix 2 and which is analyzed in Section 6. This mode is denoted mode 0 or "TargetOrientation = 0". In this case, the attitude is fixed in inertial space and is thus approximately a 360 degree pitch maneuver. The maneuver will start with whatever flying mode was in effect at the time and will end there. See section 6. The angles xerror, yerror, zerror reported in this mode will be relative to inertial (commanded). This maneuver, presents special processing problems, which are solved in Section 6.

3.6 Quaternions:

quaternions are shown in boldface.

3.7 Euler Angles:

Euler angles are in radians and within arrays they are listed in the same order as the "Euler Angle Order": 3-2-1. They are denoted also as yaw, pitch and roll. When the flying mode is not mode 1, the term "yaw" will refer to the last line of Table 1, Sect. 5 and not to "zerror."

3.8 Angular rates:

Angular rates are in rad/sec. In normal flying mode the rates are stripped for orbital motion by using the vector described in "0.2.3.2 ACSGyroAttd" on p 59 of the TRMM ACS Algorithm Document, Build 5.1a. (See Appendix 2).

4. General Analysis of Chaining Operations:

(Skip this section if your interest is in coding and testing)

We want Euler angles taking the spacecraft from orbital (not tipped orbital) to actual orientation. This is representable as

orbital -> tipped orbital -> actual (spacecraft orientation)

We are given the last part in the attitude data - the xerror, yerror, zerror values. We can generate the transformation

tipped orbital -> orbital by using PGS_CSC_TiltYaw().

4.1 Details on Chaining Operations:

In developing a way to chain the transformations, we must be careful on two issues: (1) are we rotating objects, vectors, etc. ("alibi" interpretation) or are we re-expressing the same vectors in rotated coordinates ("alias" interpretation). (2) We must be careful in using any Toolkit or other function, to interpret it correctly in this regard. By defining different coordinate systems with different unit vectors, we are starting with the "alias" approach. We shall continue by looking at how a fixed vector "a" transforms from one system to another. As Malcolm D. Shuster has pointed out in his classic review, "A Survey of Attitude Representations" in J. Astronaut. Sci. 41, 439 - 517 (1993), (see pp. 494-495), the matrix for alibi is the transpose of that for alias, and in the alibi case, we don't deal with a fixed vector at all.

In any case, remember, although our Euler angles are to rotate the spacecraft from orbital to actual, our quaternions in the Toolkit transform vectors from spacecraft to inertial J2000. This is all done automatically and is not affected by what is done in the present analysis, so long as it is correct. In this document, for consistency with our software, we'll define an "attitude matrix" as one that performs alias transformations - it acts on components and not on unit vectors.

Thus if we identify primed as orbital and unprimed as spacecraft, we have, for any vector a,

a_m' = S(AttMatSpacecraftToOrb(m,n)) a_n (1)

n

Basic rule: the matrix to take a vector from a representation as components in (i,j,k) to components in (i',j',k') is found by writing a = a_x * i + a_y * j + a_z * k =

a_x' * i' + a_y' * j' + a_z' * k'

Then dotting into (in turn) i,j,k we get

a_x = a_x' (i'*i)+ a_y' (j'*i)+ a_z' (k'*i)

a_y = a_x' (i'*j)+ a_y' (j'*j)+ a_z' (k'*j) (2)

a_z = a_x' (i'*k)+ a_y' (j'*k)+ a_z' (k'*k)

Note that i = (i'*i)i' + (j'*i)j' + (k'*i)k'

j = (i'*j)i' + (j'*j)j' + (k'*j)k' (3)

k = (i'*k)i' + (j'*k)j' + (k'*k)k'

(the same matrix). Thus we can write:

AttMatOrbToSpacecraft(m,n) = e_p * e_q' (4)

and use it to transform either unit vectors or coordinates in the same sense. On the other hand,

a_x' = a_x(i'*i) + a_y(i'*j) + a_z(i'*k)

a_y' = a_x(j'*i) + a_y(j'*j) + a_z(j'*k) (5)

a_z' = a_x(k'*i) + a_y(k'*j) + a_z(k'*k)

or AttMatSpacecraftToOrb(m,n) = e_m' * e_n (6)

This is the transpose of the matrix in Eq. (2), but the rule is to apply the same attitude matrix either to coordinates or to unit vectors. The reversal occurs between alias and alibi only.

5. Obtaining the Euler angles from the flying mode and "errors":

The angles xerror, yerror, zerror should determine the attitude up to a yaw rotation specified by flying mode. (For flying moide 0, special operations are required in addition to those shown here - see Sect. 6).

Ignoring, the yaw, "xerror" and "yerror" can be identified as:

xerror = the angle between the x axis and the (x",y") plane (7)

yerror = the angle between the y axis and the (x",y") plane (8)

From these relationships we could establish the attitude matrix of the spacecraft relative to the tipped orbital plane if we knew the yaw. But the yaw is actually defined in the Flatley paper by picking it as the first Euler angle. It is easy to verify from the equations at the bottom of Flatley's p. 10 that, when the yaw is small (not ~90 or ~180 deg), that

eulerAnglesTip[0] = roll = xerror (9a)

eulerAnglesTip[1] = pitch = yerror (9b)

eulerAnglesTip[2] = yaw = zerror (see note 1) (9c)

Note:These are all relative to tipped orbital coordinates [exception: In mode 0 they are relative to inertial coordinates]. Eq. (9c) will be superseded by the last row of Table 1, below!

When the yaw is re-referenced to 90 degrees, or 180 deg the following table can be seen to apply:

Table 1 - Yaw Adjustments
 

Note that the plans are to use mostly modes 1 and 3. The term "TargetOrientation" is used in the Code 712.1 document and is the same as "mode". Modes 1 and 3 will be used about equally, depending on the Sun angle. The 360 degree pitch maneuver is denoted TargetOrientation = 0.  In Table 1, the lower case p, if it appears in your browser, stands for pi=3.14159265358979....

The overall sequence of steps will be:

Step 1. Get TippedToSCEuler angles "PGSt_double TipToSC_Eul[3]" from tipped orbital to spacecraft from Eqs. 9a, 9b, and Table 1 last line. That line replaces Eq. 9c. The order within any array of Euler angles will be: "yaw, pitch, roll." When the flying mode is not mode 1, the term "yaw" will refer to the last line of Table 1 and not to "zerror."

Step 2. Put these in PGS_CSC_EulerToQuat to get the quaternion quatSCtoTip from spacecraft to tipped orbital. The call is PGS_CSC_EulerToQuat(eulerAnglesTip,eulerAngleOrder,quatSCtoTIP) where eulerAngleOrder is the PGSt_integer[3] array with the value [3,2,1], and the array eulerAnglesTip contains the angles in that order.

Step 3. Obtain the TOD spacecraft coordinates. For TRMM we obtain these from the TOR ephemeris, for AM1 we'll need to use J2000. FDF actually provides True of Reference where "Reference" is normally the start of the first orbit in that file, and appears in the FDF file header, bytes 337-392. The change in reference frame in one day could be neglected for our purposes, but we'll use a rigorous method. Rigorously, one does the following calls [these are written as if we had to start with TOR; if the ephemeris is already in J2000 then steps (a) - (c) have presumably been done and only steps (d-e) are needed; the "posvelECI" in step (d) is the 6-vector of J2000 position and velocity data at time secTAI93TOD:

a. convert both times to secTAI93:

secTAI93TOR is from converting bytes 337-392

secTAI93TOD is from converting the packet

b. Pack TOR position and velocity into PGSt_double posvelTOR[6].

c. PGS_CSC_TODtoJ2000(6,secTAI93TOR,posvelTOR,posvelECI)

d. PGS_CSC_J2000toTOD(6,secTAI93TOD,posvelECI,posvelTOD)

e. break out position and velocity positionTOD[3],velocityTOD[3]

[by using pointers cleverly, you can actually avoid the "pack" and "break out" steps - see Note 3 for illustration.].

Step 4. Obtain the quaternion quatTipToOrb for tipped orbital -> orbital from PGS_CSC_TiltYaw(). You need the TOD position and velocity. The call is

PGS_CSC_TiltYaw(positionTOD,velocityTOD,A,C,quatTipoORB)

where you should get A and C from PGS_CSC_GetEarthFigure() with the model IERS-1989. A citation for the choice IERS-1989 is appended. A is the semi-major axis and C the semi-minor.

Step 5. Multiply quatSCtoTip by quatTipToORB using PGS_CSC_quatMultiply; the result is quatSCtoORB. The call is:

PGS_CSC_quatMultiply(quatTipToORB,quatSCtoTip,quatSCtoORB),

The output is the third argument.

Step 6. Invoke

PGS_CSC_QuatToEuler(quatSCtoORB,eulerAngleOrder,eulerAnglesOrb)

to get the Euler angles in inertial orbital coordinates, where eulerAngleOrder is the PGSt_integer[3] array with the value [3,2,1] and eulerAngles is the PGSt_double[3] array of angles you want for the output to the Toolkit. The final result is:

eulerAnglesOrb, which should be written to output. The rates are to be simply passed directly on; they are specified as instantaneous axis rates and not Euler angle rates (Appendix 2). In Mode0 they are inertial rates; other modes TBD.

6. Special Sequence of Operations for Flying Mode 0:

In the case of flying mode 0, the spacecraft locks on to inertial, holding it as best it can with gyros. We must capture the inertial state at the time T_0 of the first packet with mode 0. This is done by calling [denote this Eq. P1]:

PGS_CSC_getECItoORBquat(posECI_0,velECI_0,quatECItoORB_0)

The function requires the J2000 position and velocity of the spacecraft, posECI_0 and velECI_0.

The subscript "_0" on a quantity tells us that it is defined at the start of mode = 0. quatECItoORB_0 must be retained until the mode changes from mode 0. We must also capture the flying mode (1,3, or 4) just before the maneuver, as it is used to reference the body axes during the maneuver. This will be called the "remembered flying mode."

Denote the inertial frame whose axes are along ideal TRMM x,y, and z at T_0 as ORB_0 (we shall establish that this is justified). We'll call this the "inertial locked" reference frame. Because there is no attitude sensing in this mode and the gyros will drift, we do not consider it necessary to deal with the difference between TOR and TOD (< 0.3" arc) at this level. TOD vs J2000 could be significant, however, and is accounted for. This difference could be, for example, ~5 arc minutes or 10 km equivalent position error in 1997 or 2003.

The quaternion quatECItoORB_0 takes vectors from ECI (J2000) to orbital coordinates, when it is applied in PGS_CSC_quatRotate(), but if, instead, it is converted to Euler angles, it would represent the spacecraft turning from orbital zero-attitude orientation to J2000. This is in general consonance with the fact that a spacecraft motion is an alibi motion while a coordinate transformation is an alias. We can thus state that quatECItoORB_0 just as well represents a rotation of the spacecraft from its orbital coordinates at T_0 to J2000.

The idea of our method is that, having captured the coordinate system to which the attitude is being controlled in quatECItoORB_0, we can then generate a further tansformation quatECItoORB at any time during the maneuver that takes us back to the current orbital coordinates. The initial transformation that we need is actually from orbital to J2000. (Tipped orbital is meaningless in this context). Because quatECItoORB_0 is from J2000 to orbital, this will require generating its conjugate, quatECItoORB_0*, where the (*) represents quaternion conjugation (you can just reverse the sign of the zero component). In brief, we replace the old sequence of transformations:

Old Sequence (for Modes 1-4)

(i) SCtoTip (from inputs)

(ii) TipToORB (from TiltYaw)

with the new set

New Sequence (for Mode 0)

(i) SCtoORB_0 (from inputs)

(ii) ORB_0 to J2000 (from quatECItoORB_0*)

(iii) J2000 to current (T_I) orbital (from quatECItoORB)

Note, once again, that for Mode 0 we do NOT use a tip-to-orbital transformation.

The required operations are (one-time per mode change operations are denoted with a terminal "0"):

Step A0.1 identify the time of the first Mode 0 packet, T_0

Step A0.2 Save the flying mode from the previous packet.

Step B0. invoke PGS_CSC_getECItoORBquatto get quatECItoORB_0 with the call

PGS_CSC_getECItoORBquat(posECI_0,velECI_0,quatECItoORB_0)

Step C0. Conjugate the quaternion by reversing the sign of its [0] component, obtaining quatORB_0toECI=quatECItoORB_0*= (-quatECItoORB_0[0],quatECItoORB_0[1],quatECItoORB_0[2], quatECItoORB_0[3]) Save this for the duration of the Mode 0 event.

The following steps are for any later time T_I during the same maneuver (mode staying 0; the I stands for "inertial lock". In any processing here, use the remembered mode from just before Mode 0.)

Step D. Get ORB_0 to SC Euler angles "PGSt_double ORB_0toSC_Eul[3]" from ORB_0 to spacecraft from Eqs. 9a, 9b, and Table 1 last line. That line replaces Eq. 9c. The procedure is exactly the same as in ordinary (Modes 1-4) Step 2; only the names are changed, because we are working with the relation of the spacecraft to locked ORB_0 coordinates, not to tipped orbital. But use the remembered mode, of course, not mode 0 from Step A0.2.

Step E. Put these Euler angles in PGS_CSC_EulerToQuat to get the quaternion quatSCtoORB_0 from spacecraft to inertial locked. The call is

PGS_CSC_EulerToQuat(ORB_0toSC_Eul,eulerAngleOrder, quatSCtoORB_0)

where eulerAngleOrder is the PGSt_integer[3] array with the value [3,2,1]

Step F. obtain posECI[3] and velECI[3] at this time T_I

Step G. invoke PGS_CSC_getECItoORBquat(posECI,velECI,quatECItoORB) which gets, at time T_I, the ECI to ORB quaternion.

Step H. Combine with the stored quaternion using PGS_CSC_quatMultiply(quatORB_0toECI,quatSCtoORB_0, quatSCtoECI). This last result takes us between SC and ECI.

Step I. Bring us from ECI to orbital with PGS_CSC_quatMultiply(quatECItoORB,quatSCtoECI, quatSCtoORB)

Step J. Invoke

PGS_CSC_QuatToEuler(quatSCtoORB,eulerAngleOrder, eulerAnglesOrb)

to obtain the Euler angles. This step is identical with the ordinary (Modes 1 - 4) Step 6.Step K. Re-acquisition of Mode 1 or 3: At the end of Mode 0 operations the spacecraft will revert to Mode 1 or Mode 3- whichever it started with. Resume normal processing then, ignoring any transient, but check that the mode is indeed the same one you started with; flag the attitude as bad otherwise. Appendix 1Explanation of the Choice of IERS-1989

From lmarkley@ccmail.gsfc.nasa.gov Mon Feb 26 10:11:26 1996

Return-Path: <lmarkley@ccmail.gsfc.nasa.gov>

Received: from rocinante.gsfc.nasa.gov by eos.hitc.com (4.1/SMI-4.1)

id AA27033; Mon, 26 Feb 96 10:11:23 EST

Received: from msmail.gsfc.nasa.gov by rocinante.gsfc.nasa.gov (5.65/1.35)

id AA05907; Mon, 26 Feb 96 10:15:02 -0500

Received: from ccMail by ccmail.gsfc.nasa.gov (SMTPLINK V2.10.08)

id AA825358312; Mon, 26 Feb 96 10:06:41 EST

Date: Mon, 26 Feb 96 10:06:41 EST

From: lmarkley@ccmail.gsfc.nasa.gov

Message-Id: <9601268253.AA825358312@ccmail.gsfc.nasa.gov>

To: pnoerdli@eos.hitc.com (Peter Noerdlinger)

Cc: jennifer_bracken@ccmail.gsfc.nasa.gov, tom_flatley@ccmail.gsfc.nasa.gov

Subject: Re: TRMM attitude

Status: R

The latest version of the TRMM ACS Algorithm Document (Build 5.1a, October 2, 1995) specifies a=6378.1363 km and flattening=1/298.257.

To the best of my knowledge, these are the values we are using. The revised equatorial radius was given to us by Evette Brown-Conwell of Flight Dynamics/553 in November 1994. They didn't give us an updated flattening factor at that time, and we didn't ask for one.

The algorithms we use are in module AcsInertAttd, documented on pp 60-62 of the above-referenced document. I believe you have an earlier version, which should have the identical algorithm.

I don't have a preference for any specific Euler angle sequence. Since yaw is the least-well controlled, 3-2-1 or 3-1-2 is probably the bezst choice. You should use the more conventional of these.

Landis Markley

_______________________________________________________________________________

Subject: TRMM attitude

From: pnoerdli@eos.hitc.com (Peter Noerdlinger) at Internet

Date: 2/23/96 10:47 AM

We are coding some stuff here at EOSDOS/SDPS to bring the TRMM attitude into an Euler Angle format referenced to geocentric orbital coordinates (nadir toward Earth center, Y along negative angular momentum vec.)

In so doing, we want to use the SAME Earth axes you use originally in the tipped-axis transformation. The old Flatley paper gives a = 6378.14 and flattening = 1/298.257 . We find this is exactly the IAU 1976 model. Are these the numbers you will actually use?

(WGS84 has a = 6378.137 and f = 1/298.2572236)

(I realize we are way down in the noise here - but no sense in coding in different numbers from what you will use !) Thanks much

P.S. I believe you are not defining an Euler angle sequence, but I thought we had some information long ago that you were thinking of 3-2-1 or recommending it perhaps. Do you have any opinion as to what is best to use - we are converting to Euler angles as I mentioned. Thanks again

Peter D. Noerdlinger

[Senior Scientist - EOSDIS Project]

Space Applications Corp. - c/o Raytheon Space Systems

1616 McCormick Drive

Upper Marlboro, MD 20774-5372

tel: (301) 614-5475

FAX: (301) 925-0321 (Telephone to confirm -

machine is unattended)

e-mail: pnoerdli@eos.hitc.com

"Take care of the nanoseconds and the milliseconds will take care of themselves."

Received: from rocinante.gsfc.nasa.gov by ccmail.gsfc.nasa.gov (SMTPLINK V2.10.08)

Return-Path: <pnoerdli@eos.hitc.com>

Received: from igate1.HAC.COM by rocinante.gsfc.nasa.gov (5.65/1.35)

id AA07499; Fri, 23 Feb 96 10:49:28 -0500

Received: from EDEN1.HAC.COM by igate1.hac.com (4.1/SMI-4.1)

id AA09544; Fri, 23 Feb 96 07:44:28 PST

Received: from eos.hitc.com by EDEN1.HAC.COM (PMDF V4.3-13 #5884)

id <01I1JMU4C3C0000L9T@EDEN1.HAC.COM>; Fri, 23 Feb 1996 07:45:43 -0800 (PST)

Received: from shark.HITC.COM.eosdis by eos.hitc.com (4.1/SMI-4.1)

id AA13597; Fri, 23 Feb 96 10:42:03 EST

Date: Fri, 23 Feb 1996 10:42:03 -0500 (EST)

From: pnoerdli@eos.hitc.com (Peter Noerdlinger)

Subject: TRMM attitude

To: lmarkley@ccmail.gsfc.nasa.gov

Cc: elarson@EDEN1.HAC.COM, khalsa@EDEN1.HAC.COM, kummerer@eos.hitc.com, pgstlkit@EDEN1.HAC.COM, pnoerdli@EDEN1.HAC.COM

Message-Id: <9602231542.AA13597@eos.hitc.com>

Content-Transfer-Encoding: 7BIT

------------------------------------------------------------------

Comment: Further attempts to get Dr. Markley to identify his model or to adopt a standard one in its place failed. Therefore we'll use IERS-1989. The 30 cm difference amounts to a change in flattening of only 1 part in 10 7 or an effective altitude change of 1 part in 10 6. This will affect the attitude by less than 10 8 radians or < 0.001 arc seconds - negligible.

For the record, the Earth Axes and flattening for IERS-1989 are:

IERS1989:

Semi-Major axis 6378136.000000

Semi-Minor Axis 6356751.301569

1/f 298.257000000

Appendix 2 - Pitch Maneuver

Date: Tue, 05 Mar 96 09:03:20 EST

From: lmarkley@ccmail.gsfc.nasa.gov

Message-Id: <9602058260.AA826045433@ccmail.gsfc.nasa.gov>

To: pnoerdli@eos.hitc.com

Subject: Re: 360 deg maneuver

Status: ORrpf

Below is my best information about the 360 deg TRMM maneuver, as verified by Sam Placanica.

Landis Markley

____________________________________________________________________________

Subject: Re: 360 deg maneuver

From: Samuel Placanica

Date: 3/5/96 8:55 AM

Landis, the following is all correct:

1. This maneuver is performed by commanding an inertial hold for one orbit, which gives a 360 deg pitch maneuver in an earth-referenced frame

2. The rates will be correct inertial rates (no orbit rate stripping)

3. The angles will be error angles in the body frame, the angles between the commanded inertial attitude and the gyro-sensed attitude. They are actually just the integrated gyro outputs on the three body axes, not true Euler angles except in the small-angle approximation

4. The maneuver will start from +x forward or -x forward, depending on which way the spacecraft is flying when it is commanded. It will never be commanded from -y forward.

Let me add that we also integrate the position error signals, thereby employing a PID controller. We also want to reacquire earth pointing mode as close as possible to the completion of the one-orbit CERES calibration in order to minimize reacquisition transients.

Sam

According to Sam Placanica of GSFC in e-mail March 11, 1996:

"As shown on p. 59 of the TRMM ACS Algorithm Document, a constant mean orbital rate is used for stripping purposes only when the ACS is in mission mode and the ephemeris has been marked bad. When the ACS is in mission mode (with a good ephemeris) or in Delta-V mode, the orbit rate stripping rate is not constant and is represented by the 3x1 vector "wbody". This vector is the resultant of calculations made in 0.2.3.3 AcsInertAttd on pages 60-62.

Appendix 3TRMM Spacecraft Analysis

Summary of Expected Behavior Due to the Transform from Geodetic to Geocentric Nadir

Peter D. NoerdlingerMay 23, 1996

The TRMM spacecraft is referenced and controlled to the local horizontal -essentially geodetic nadir. Therefore, the EOSDIS DPREP software algorithm for attitude, developed by Peter Noerdlinger, snd coded by Robert Kummerer, transforms the attitude to the EOSDIS/SDP Toolkit standard of geocentrically defined orbital coordinates. This Table below gives predictions of the sense and approximate signs of the changes in the attitude angles due to this transformation, based on the author's understanding of the geometry. The tests conducted by R. Kummerer to validate the overall sense and magnitude of the changes to the angles were conducted by using simulated data from GSFC, with all the angles at or near 0.0, and examining the changes to them after DPREP processing. All the predictions were validated, thus providing a preliminary "sanity check" on the software. The changes in yaw are complex and small, and were not analyzed by this method.

Explanation of Columns:

Flying mode: +x -> x fwd, -x -> yaw ~180 deg, -y -> yaw ~90 deg

Mode 0 - inertial lock - handled separately

Eul Ang: The Euler angle affected - or at least the one I can predict

Latitude: 17N means about 17 deg North, 17S means about 17 deg South (half max points intended to maximize the product of the Northward or Southward velocity with the magnitude of the latitude.) Since thr TRMM has low orbital inclination, the Northward and Southward bearings given are shorthand for NE and SE - there is always a steady Eastward component. The first four rows of the Table are for top and bottom of orbit - about 35 degrees N or S.

MaxN -> about 35 deg N, MaxS -> about 35 deg S

Bearing: N -> Northward, S-> Southward, E -> Parallel to equatorial plane

Expected Increment: Sign of difference of angle after processing and before.

Size will be about 10 minutes arc in the MaxN and MaxS cases, else about 3 to 5 minutes arc.

Truth Table - validated by R. Kummerer of Hughes May 25, 1996