See gtorbsim:

Help | Examples

Also see:

• gtobssim

This parameter encodes the desired pointing strategy. It can be either the path of the file to be parsed, or a single command.

If a single command, each portion of the command is separated by a "|". For instance, in the case of a simple survey with a rocking offset of +35, the command to be passed will be: Timeline = |SURVEY|+35.0|

On the other hand, for a PROFILED survey the syntax should be as follows: Timeline = |PROFILED| 54301.0| 600 +35.0 1200 +25.0 1800 +15.0 ....|

The first item specifies the survey as PROFILED, the second item must be the epoch or ROCKSTART in MJD format, then the rocking parameters are specified using the sequence TIME0 ANGLE0 TIME1 ANGLE1 TIME2 ANGLE2 ... and so on.

Times must be in seconds, and angles in degrees. Notice also, that times must be increasing, and that the first and last angle must be the same.

Finally, a command to simulate a pointed observation can be given as: Timeline = | POINTED | 234.98 | 34.56 | where the first parameter after "POINTED" is the Right Ascension in degrees with values between 0.0 and 360.0, and the second is the Declination expressed in degrees between -90.0 and 90.0.

Only empty spaces are allowed between each entry. * FIXED SURVEY - the spacecraft does a sky survey with a specified offset with respect to its local zenith for one orbit, and then uses the opposite offset to another orbit, and so on.

* PROFILED SURVEY - the spacecraft observes in survey mode according to a specified profile consisting of 17 increasing times and 17 zenith offsets.

* POINTED - the spacecraft stares at a specified location in the sky identified by RA and DEC.

EphemFunc is used to specify which function must be used to calculate the position. The orbit simulator is capable of using 3 different types of ephemeris:

• NASA Flight Dynamic Facility (FDF) format, already used for missions such as RXTE. In this case the value of EphemFunc is yyyy_eph.

• Satellite Tool Kit (STK) format, already in use for SWIFT. xyzll_eph
  is the name of the function that is used to propagate the spacecraft
  position.

• NORAD Two Line Elements (see NORAD Two-Line Element Sets Current Data, in which case the spacecraft position is calculated
  "on- the-fly". The value for EphemFunc in this case is tlederive.
  

The orbit simulator needs to know the spacecraft position in the entire interval of interest in order to properly calculate the attitude; therefore, it must be capable of either reading in a file that contains the spacecraft ephemerides, or of calculating them on the fly.

The orbit simulator can handle three different types of ephemeris files. If in FDF or STK ephemeris format, the corresponding functions (respectively yyyy_eph or xyzll_eph), it simply reads the file and populates the EphemData structure:

• MJD - vector for time stamp in MJD format

• X - X component of the spacecraft position vector

• Y - Y component of the spacecraft position vector

• Z - Z component of the spacecraft position vector

• Lat - vector for the Latitude in EC system

• Lon - vector for the Longitude in EC system

• Alt - vector for the Height in EC system

• VelRA - vector for the velocity compenent in RA in EC system

• VelDEC - vector for the velocity compenent in DEC in EC system

• Period - Ephemerides Period, not used with the available Ephemerides formats

• SemiMajorAxis - not used with the available Ephemerides formats

• ent - number of entries in each vector

In a Two Line Elements file, the corresponding function, tlederive, calls readTLE, which searches for the specific satellite (Fermi), and parses the Two Line Elements parameters into the structure atElemTle. The function then uses the Simplified General Perturbations Satellite Orbit Model 4 (SGP4) algorithm to calculate the satellite position in the interval of interest with the requested time resolution, and then populates the EphemData structure. The
accuracy of SGP4 is 0.1^o in both latitude and longitude from the ground.

Note: TLE files should not be used for intervals greater than 30 days, since the accuracy tends to degrade due to perturbations.

The Units keyword is used as conversion factor to km, since not all ephemerides have the position calculated in the same way. If tlederive or xyzll_eph, the value for Units is 1, while in the case of yyyy_eph, it is 10000.0.

This keyword is used to specify a parameter for the time resolution for the orbit simulator. Clearly, if yyyy_eph or xyzll_eph is used to calculate the spacecraft position, the time resolution of the ephemeris file must be the same as the specified one. Otherwise, an error is generated. If a Two Line Elements file is used, the spacecraft position is propagated using the indicated time resolution.

Note: The resolution must be specified in minutes, or fraction of a minute.

saafile gives the file name that contains the specification of the polygon (in terms of Latitude and Longitude) that defines the South Atlantic Anomaly (SAA) region. Only LATSAA files are supported.

The saa function is called to calculate the South Atlantic Anomaly (SAA) entry/exit. The SAA region is approximated by a polygon, which is specified by the Longitude/Latitude of its vertices. Currently, there are two different ways to indicate the polygon, and the above function is capable of handling both of them.

The algorithm used for the event times calculations is the same as the one used by TAKO. This routine determines if each ephemeris point is in or out of the SAA polygon. A filename should be passed which defines SAA polygon
(longitude/latitude pairs).

In cases where the filename is not passed in, a default hard-coded table of pairs will be used. In addition to an ephemeris point being in the SAA polynomial, the ephemeris point prior will also be included as in the SAA region, since somewhere between the two points is when the actual SAA is entered.

For this routine to work, the last latitude/longitude pair must be the same as the first.

Last updated by: Chuck Patterson 02/16/2011