The Cyclone Global Navigation Satellite System CYGNSS Mission

The Cyclone Global Navigation Satellite System (CYGNSS) Mission: Science Processing on a Microsatellite with limited resources Scott Miller Robert Klar

Overview • Mission Overview – Science – Spacecraft – Avionics • Flight Software Design – System and Boot Software – Application Software • Challenges 2

Mission Overview CYGNSS measures the ocean surface wind field with unprecedented temporal resolution and spatial coverage, under all precipitating conditions, and over the full dynamic range of wind speeds experienced in a Tropical Cyclone (TC). It does so by combining the all-weather performance of GPS-based bistatic scatterometry with the sampling properties of a microsatellite constellation. Near-surface winds over the ocean are major contributors to and indicators of momentum and energy fluxes at the air/sea interface. Our goal, to understand the coupling between the surface winds and the moist atmosphere within a TC, is key to properly modeling and forecasting its genesis and intensification. 3

Mission Overview

Mission Design Pictured is Hurricane Igor taken on 14 Sep 2010 looking out the window of the International Space Station. This view is just about the same vantage point as CYGNSS will have when it's on orbit. 5

Mission Science Objectives In order to enhance the understanding of TC intensity development – the CYGNSS mission will: • Provide estimates of ocean surface wind speed over a dynamic range of 3 to 70 m/s as determined by a spatially averaged wind field with resolution of 5 x 5 km • Provide estimates of ocean surface wind speed during precipitation rates up through 100 millimeters per hour as determined by a spatially averaged rain field with resolution of 5 x 5 km • Measure ocean surface wind speed with a retrieval uncertainty of 2 m/s or 10%, whichever is greater, with a spatial resolution of 25 x 25 km • Collect measurements of ocean surface wind speed with temporal sampling better than 12 hour mean revisit time AND spatial sampling that samples greater than 70% of historical storm tracks within 24 hours 6

Observatory 7

Observatory • Single String Architecture • Instrument driven configuration • Star Tracker-based 3 -axis Reaction Wheel attitude control • Fixed panel, deployed Solar Array • S-Band Comm • Highly Integrated Structure 8

Deployment Module • Supports Pre-launch and Launch Operations – Pre-launch μSat Command, Telemetry, and Power EGSE interfaces • Powered off at launch • Separation events controlled by Launch Vehicle 9

Flight Software Architecture 10

Software Components • System Software – – – – – • Applications Bootstrap Operating System (RTEMS) System Interface Flash Driver Space. Wire Driver UART Driver I 2 C Driver General Purpose I/O Transceiver Interface – Autonomy (Periodic Processing) – Command Manager – Telemetry Manager – DDMI Manager – Storage Manager – Stored Command Sequencer – Thermal Manager – Power Interface Manager – ADCS Manager (Draper) – ADCS Algorithm (Draper) • Flight Core Libraries – Software Bus – Command Sequencer 11

Software Data Flows 12

Software Tasking

Challenges - Downlink 14

Challenges - Downlink • Modest Downlink speed with S-Band Transmitter • Eight Spacecraft collecting data • Ground Contacts limited to about 20 minutes per Spacecraft every 2 days

Challenges – Downlink (to CFDP or not to CFDP? ) Factor CFDP Simple Playback/Replay Cost to Design No Impact Minimal Negative Cost to Implement Moderate Negative Impact to I&T EGSE Moderate Negative Minimal Negative Impact to Ground Systems and Operations Major Negative Minimal Negative Size of u. Sat FSW Moderate Negative Minimal Negative u. Sat Processor Load Moderate Negative Minimal Negative Downlink Rate Moderate Negative No Impact 16

Challenges - Compression • Two Science Modes that Require Compression – DDM Mode – Blackbody Calibration Mode • DDM Compression Algorithm Results in Two Packetized Datasets for Downlink – Glistening Zone – Noise Floor • Blackbody Compression Algorithm Results in One Packetized Dataset for Downlink 17

Challenges – Compression (Nominal DDM) Glistening Zone Compression Create Low Pass Filtered DDM To Find Estimated Specular Point Use Estimated Specular Point To Select Glistening Zone Pixels Estimated Specular Point DDM from DDMI Noise Floor Compression Use Estimated Specular Point To Select Noise Floor Rows Sum Each Noise Floor Row Into One Value Per Row 18 Bit Truncate, Packetize, and Store in Flash Memory

Challenges – Compression (Blackbody Calibration Mode) Sum Each Row of DDM Into One Value Per Row 1 2 Sum N Consecutive Row Values To Further Compress Bit Truncate, Packetize, and Store in Flash Memory 128 1 2 Blackbody DDM from DDMI 64 19

Challenges – Compression (Prototype Implementation) • Algorithm definitions – SPRL Technical Memo 148 -0046 -X 3, DDM Compression & Decimation Algorithm • Implementation Platform – C Programming Language – RTEMS Operating System – Gaisler GR 712 RC Eval Board (LEON 3, SPARC V 8) • Description and Data Sets – Created representative DDM datasets using pixel values from sample simulation data provided by Chris Ruf, CYGNSS PI – Implemented all algorithm steps for both Nominal DDM and Blackbody DDM Compression (illustrated in previous slides) – Included initializing with configurable algorithm parameters and executing algorithm on representative DDM datasets on four different channels 20

Challenges – Compression (Results of Benchmarking) Timing results obtained for Nominal DDM Compression algorithm by executing algorithm on four separate DDM datasets (i. e. four channels) 10 times and computing the average iteration time while clocking GR 712 RC development board at four different frequencies Clock Frequency (Mhz) Average Iteration Time (seconds) 4 . 049900 12 . 033198 50 . 008191 100 . 004213 • Approximately 33 msec for 12. 5 Mhz target clock frequency • Black Body compression benchmarking averaged 28 msec • Timing results did not include DDM bus transfer time from DDMI nor flash memory storage time 21

Questions?