IEEE Geoscience and Remote Sensing Magazine - June 2013 - 62

from the launch vehicle and for anomaly recovery if
rates exceed normal state capabilities. Rate damping uses
a "B-dot" algorithm to command magnetic dipole
moments opposed to the rate of change of the magnetic
vector, both measured in body coordinates. It only uses
the sensed magnetic field, and does not rely on a correct
orbital ephemeris or magnetic field model. Wheel speed
is off for launch and initial tip-off recovery, or set to its
nominal value during anomaly recovery.
After the body rates are damped, the system transitions
into nadir acquisition, which monitors the pitch/roll horizon sensors to determine a rough Earth vector. The sensors are not assumed to be in their linear range; simple "on
Earth" and "off Earth" measurements are used to establish
slow roll and pitch rates to bring the sensors into their linear range (! 5°). The momentum wheel is also maintained
relatively close to its commanded nominal speed, with a
desaturation gain much lower than normal.
When the ADCS brings the sensors within their linear
ranges, it transitions to normal operations. The normal state
uses pitch and roll measurements from the horizon sensors
to calculate pitch, roll, and filtered roll rate information. It
com-pares the measured magnetic field with a calculated
model to determine yaw and filtered yaw rate information.
These measurements are used to control momentum wheel
torques for pitch and the electromagnets for roll and yaw
angle, and pitch wheel desaturation.
Normal control is capable of degraded operation
(used in Standby mode) if the ephemeris and magnetic
field model are temporarily unavailable. Pitch and wheel
desaturation are controlled as before, but roll and B-dot
(y axis) information (as in HCMM) are used to control
roll and yaw with slightly degraded accuracy. The torque
rod commanding is synchronized to permit accurate
measurement of the local geomagnetic field. A Kalman
filter is used to estimate body rates and improve yaw attitude estimation. Orbit position is provided via GPS determination from the DDMI.
6. MIcroSatellIte flIGht Software
The CYGNSS microsat flight software, which handles all
station keeping, is based on a cost-effective, component
architecture, enabling significant software reuse. It is developed in the C Language, executing on the Centaur computer
in the RTEMS real-time operating system environment.
The modular architecture and components enable efficient
development and verification while directly supporting
on-orbit modification. The flight software is table-driven
and includes provisions for memory, table, and program
image uploads. Application components interface through
a software bus implementation (part of the Flight Core) to
exchange CCSDS packets. Standard CCSDS protocols simplify the integration of application components and provide a reliable mechanism to install component stubs and
simulations during software testing. During flight software
development, the software bus is bridged to an Ethernet
62

network via TCP/IP to permit the use of external simulators
to test the ADCS.
RTEMS provides a small memory footprint and deterministic timing. Software development tools include the
GCC compiler, the debug monitor, and the Software Verification Environment. The flight software team has significant flight development experience with this environment
from the Fermi, Juno, and MMS missions.
7. Ground SeGMent and MISSIon operatIonS
7.1. concePT of oPeraTions
In developing the design concepts for the CYGNSS Observatories, the Systems Engineering team has kept in mind
ensuring the safety of the Observatories without ground
intervention. Providing on-board systems which minimize
the need to develop time-tagged command sequences for
each Observatory for routine operations also supports
a simplified operational cadence for maintaining the
constellation.
launch through commiSSioning
Each Observatory is deployed with solar arrays stowed and
the Observatories can remain in this 'stowed' configuration
indefinitely. After deployment from the launch vehicle,
each Observatory transitions automatically through the
initial three states to reach the Standby Mode where it can
safely remain indefinitely.
Deployment of the S/As will occur within a communication pass allowing the CYGNSS operations and SC
teams to observe the deployment sequence and address
any issues that may occur using real-time commanding.
Additional commissioning activities for the Observatories will begin once the S/As are deployed on every Observatory in the constellation and will continue for a period
of 2 to 4 weeks.
Commissioning activities for a CYGNSS DDMI commences once its microsat has completed its commissioning
sequence. DDMI commissioning begins and lasts an additional 4 weeks. During this time, the DDMI is operated in
two Engineering modes, which are used to verify on-orbit
performance and tune the on-board Delayed Doppler Map
(DDM) generation and subsampling algorithms. At the end
of the DDMI commissioning activities, the instrument will
be transitioned into its Science mode where it will collect
data continuously.
Commissioning activities for the microsats and then
the instruments may progress in an interleaved manner. Within a single communication pass activities will
be performed on a single Observatory, however it is not
necessary to complete all commissioning tasks on one
Observatory before progressing to the next Observatory
in the constellation. Since all Observatories are independent, it is also unnecessary to ensure each Observatory
is at the same 'step' in a commissioning sequence. This
independence allows a flexible scheduling approach to
ieee Geoscience and remote sensing magazine

JUNE 2013

Table of Contents for the Digital Edition of IEEE Geoscience and Remote Sensing Magazine - June 2013