# Presentation: 116783

## Spacecraft Operations ConceptMOWG2

**Rich Cassell**
**September 15-16,1999**

## Operational Concept-Passes

## Operational Concept- Table and software Uploads 

**Table and software Uploads**
**On QUIKSCAT, “Files” of tables or software were 32768 Bytes maximum**
**@ 2 KBPS, a “File” took 231 seconds + ground transit time from MOC to EPGS to upload (~ 5 minutes/”file”)**
**Software Uploads are not “planned” at this time**
**Patches and images will be uploaded on an “as needed” basis**
**Table Uploads are dependent on the device and on the “mission elapsed time” ( i.e. when they are done)**
**TBD tables during LEOP for “tweaking”**
**TBD tables for Star Table updates, etc.**

## Operational Concept-Commanding

**Command uplink data rate = 2 KBPS**
**Commands are in the form of CCSDS CLTU’s**
**each CLTU contains between 1 and 50 commands**
**Maximum length of a CLTU is 2056 bits**
**each command in the CLTU is 40 bits + BCH (10 bits)**
**56 bits of the CLTU are for the sync and tail sequence**
**There is a minimum of 48 idle bits between CLTU’s**
**to allow system to remain synchronized**
**to prevent command overrun when executing high level discrete commands (~50 milliseconds each)**
**Most commands will sent for storage and later execution**
**There will be very little real-time commanding during LEOP and normal ops**

## Operational Concept-Power Management

**Spacecraft will “fly” in one of four positions during normal operations**
**Airplane mode (+/- Z-axis in the orbit plane)**
**Sailboat mode (+/- Z-axis perpendicular to the orbit plane)**
**Solar Arrays will be inhibited from articulation over Antarctica and Greenland portions of the orbit**
**by stored command**
**by plan: arrays can remain fixed until sun angle reaches 50 degrees from perpendicular**
**Battery temperatures will be controlled to +5o C nominal, but never more than +10o C and never less than -10o C (survival heaters will come on near -7o C)**
**Transmitters will be turned off after each pass**

## Operational Concept - Attitude

**Spacecraft attitude determination and control will be autonomous (performed on-board with no ground intervention) except for:**
**Off-nadir pointing (discussed below)**
**Orbit maneuvers (discussed below)**
**S/C attitude is nominally nadir pointing, with yaw of -90, 0, 90, or 180 deg**
**Yaw angle depends on beta angle, to optimize power generation and keep the battery cool**
**Transitions are commanded from the ground**
**Solar panel motion (autonomous):**
**Fixed at high beta angle**
**Fixed at low beta angle and high latitudes**
**Moved to maximize power generation at low beta angle and low latitudes**

## Operational Concept - Off-Nadir Pointing

**Spacecraft will be rolled about nadir to point at reference groundtrack to within 30 m**
**To produce better science data**
**Algorithm developed and software written by CCAR; performance simulated by Ball**
**This off-nadir pointing will be done constantly - every day, all the time**
**Except when observing targets of opportunity**
**Reference groundtrack defined by the Science Team after launch; transferred once to LASP**
**System will be highly automated**
**Software will run at LASP, using the orbit determination solution as input**

## Off-Nadir Pointing - Procedures and Features

**Procedure (all done at LASP):**
**Obtain OOD solutions, propagate forward**
**CCAR s/w calculate time series of ECI quaternions to point at reference groundtrack**
**Insert quaternions into fixed frame ECI target tables**
**Upload and execute **
**Features:**
**Calculate and upload 36 hours of roll commands once each day**
**Point at nadir between 60 deg S and 60 deg N (to save memory space)**
**Point at reference groundtrack above 60 deg latitude**
**New pointing quaternion each minute**
**Results is ~745 targets uploaded per day**
**Fits in 1024 element target table **
**Can probably upload target table and CSM on a single pass**
**Can upload full target table in 4.25 minutes**
**Verified very quickly with a checksum command**

## Operational Concept - Attitude for Orbit Adjusts

**Thrusters point in -z direction - s/c must be reoriented to thrust in other directions**
**Thrusts will only be in one of four directions - plus and minus velocity, and plus and minus across track (in horizontal plane)**
**Yaw motion only**
**Must reorient from whatever yaw angle s/c is flying in to whatever yaw angle is required for the burn**
**System is highly automated**
**Commands specify an attitude target (1, 2, 3, or 4) - s/c will reorient from whatever attitude it is in to the target attitude for the burn**
**Second target command after the burn to return to orientation for operations**
**Template simplifies command generation**

## Operational Concept - Orbit Adjusts

**Orbit maintenance is critical to optimize ICESat science yield**
**Must maintain groundtrack repeat to within 800 m at all latitudes**
**Small burns necessary to compensate for the effects of:**
**Atmospheric drag (along track burns to increase altitude)**
**Luni-solar gravity (across track burns to adjust inclination)**
**Groundtrack location will be monitored and predicted by Raytheon software**
**Based on daily orbit determination solution from GPS data**
**Graphical and tabular output produced daily**
**Operators will observe and can predict when a maintenance maneuver is necessary several days or more in advance**

## Ops Concept - Orbit Maintenance Maneuvers

**	****	****	****	****drag make-up****	****	****inclination**
**frequency****	****	****1 week ****(1)****	****	****2 months**
**magnitude****	****	****80-150 mm/s****	****	****1-1.8 m/s**
**length ****(2)****	****	****6-10 s****	****	****	****1-2 min**
**location****	****	****	****arbitrary ****(3)****	****	****equator crossing**
**Notes:**
**(1) At solar maximum; will increase up to perhaps two weeks later in the mission**
**(2) Early in the mission; will increase by a factor of two or more later in the mission as tank pressure decreases**
**(3) Drag make-up burns can occur at random locations; we will monitor the frozen orbit and specify locations if necessary to drive perigee and eccentricity back toward frozen values**
*** ICESat orbit maintenance analyzed recently in paper by Demarest and Schutz**

## Ops Concept - Maneuver Design

**Orbit (groundtrack location) will be monitored and predicted daily**
**Operators will observe and decide when to perform an orbit maneuver**
**Drag make-up**
**Inclination**
**Switch orbits (calibration and mission)**
**Raytheon software will produce burn time, delta-v, and yaw angle**
**Need to write s/w to convert to thruster on times (tank blowdown relations; did for QuikScat)**
**Ingested by command generation s/w to produce commands for upload**
**Template to simplify command generation**

## Operations Concept - Orbit Determination

**Operational orbit determination to a few meters accuracy required for orbit monitoring and maneuver design**
**Produced using GPS data from the s/c with GPS data from a worldwide network of tracking sites, in the MicroCosm software**
**GPS data from s/c in X-band downlink; available 6 hours after downlink**
**GPS data from ground network available from JPL; data obtained over Internet or ftp**
**Orbit determination initiated by operator**
**Nominally each day**
**Date retrieved from JPL automatically**
**Process runs to completion nominally without operator intervention**
**Produces orbit estimates, quality measures**
**Provides data for planning/scheduling products (STK s/w), orbit monitoring (s/w), off-nadir pointing s/w**

## Operations Concept - Planning/Scheduling Products

**Planning/scheduling products produced by STX software**
**Contact data (AOS, LOS, elevation angles)**
**Eclipse times**
**Apogee/perigee times**
**Input is orbit estimate from MicroCosm s/w**
**Output is IIRVs (Improved Inter Range Vectors) **
**Transmitted to EPGS via WOTIS**

## Operational Concept-DSU Management

**DSU is planned to be “dumped” during each contact**
**Start “dump” will be begin where stop “dump” from last pass ended**
**under normal conditions, the DSU will be completely “dumped” during each pass**
**any “gaps” in the data due to start/stop will be filled in with real-time data from the pass**
**There can never be more than 8 orbits between “dumps” to prevent data loss**

## Operational Concept-SSR Management

**SSR is planned to be dumped during each contact**
**Start dump will be begin TBD frames back from where stop dump from last pass ended**
**any “gaps” in the data that might have existed otherwise will therefore be filled in**
**There can never be more than 8 orbits between dumps to prevent data loss**

## Operational Concept-Real-time and Playback Telemetry Rates and Formats

**The real-time downlink rate during normal operations will always be 16,384 BPS**
**When collecting data at the 16384 BPS rate, the DTU will always be the “long” format**
**The data collection rate (for housekeeping data) during normal operations will always be 4.096 BPS when out of sight of a ground station**
**the only exception to this will be during anomalous conditions when the need arises**
**When collecting data at the 4,096 BPS rate, the format will always be the “short” format**
**The downlink rate for DSU data is 262,144 BPS and the data contains both formats**
**Both the Real-time and Playback data streams are CCSDS**

## Operational Concept-Science Telemetry Rates and Packets

**The Science Data downlink rate is 40 MBPS**
**The Science Data downlink is CCSDS “packetized” data of which there are three types of packets**
**GLAS Science Packet**
**PRA Packet**
**GPS Science Packet**

## Operational Concept-GPS Management

**The current plan is to simply turn the GPS receiver “on”**
**There are no other planned activities**

## Operational Concept-BST Management

**The current plan is to uplink a single “precession quaternion” once or twice per week to the Bus Star Tracker (BST)**
**The BST star table will be updated about once per year**
**There are no plans to uplink a complete star catalog during the mission**

## Typical “Day in the Life of the Spacecraft”

**There will be four contacts per day, minimum**
**The DSU will be “Dumped” at every contact**
**The SSR will be “Dumped” at every contact**
**The CSM will be loaded ~once per day (~every fourth contact) with sufficient commands for 2 days**
**700 commands or so for Off-Nadir Pointing Target Table Entries**

## Spacecraft Compatibility Testing

**There are currently 5 compatibility tests:  Basic Command and Telemetry, RF-CTV, LASP-Instrument, End-to-end (thermal vacuum), and Post-environmental**
**Basic Command and Telemetry (Compatibility Test # 1)**
**First time for verifying ability of MOC to send Commands and Receive Telemetry with the real spacecraft**
**RF-Compatibility Test Van (Compatibility Test # 2)**
**Only time to verify the RF compatibility with the EPGN**
**First chance to generate tapes of telemetry for later end-to-end testing with the ICESat Ground Network (IGN)**
**LASP-Instrument (Compatibility Test # 3)**
**First time for verifying ability of MOC to send Commands and Receive Telemetry with GLAS instrument**
**End-to-end (Compatibility Test # 4)**
**Takes place during spacecraft thermal vacuum**
**tests the entire IGN**
**Post-environmental (Compatibility Test # 5)**
**Final test to show that everything is ready for launch**