IONOSPHERIC SCINTILLATION EXPERIMENT CUBESAT PROJECT
MISSION PLANNING AND CONTROL
A Design Project Report
Presented to the Engineering Division of the Graduate School
of Cornell University
in Partial Fulfillment of the Requirements for the Degree of
Master of Engineering (Electrical)
by
Ryan Song
Project Advisor: Professor Mark Campbell
Degree Date: May 2003
Abstract
Master of Electrical Engineering Program
Cornell University
Design Project Report
Project Title:Ionospheric Scintillation Experiment CubeSat Project
Author: Ryan Song
Abstract:
One of the primary constraints in the ICE Cube satellite mission will be the ability of the satellites to produce sufficient power throughout the mission lifetime. An understanding of the on-board power situation is obtained through simulation of the battery charge level. From this understanding, four control algorithms are proposed. The first algorithm focuses on decreasing power usage by limiting data collection to times when data is predicted to be scientifically relevant. This results in a 50% reduction in the power used by the GPS and communication subsystems. The second algorithm outlines a cycling scheme to decrease power usage during periods of low power generation. The third algorithm attempts to maximize power generation by modifying the satellite orientation. Initial results indicate that during orbits of low power generation, power can be increased by over 15%. The final algorithm focuses on increasing energy storage by optimization of heater usage in affecting the temperature dependent charge efficiency of the battery. Compared to the original heater usage, simulation results indicate a 54% increase in energy stored in the batteries over a single orbit.
Report Approved by
Project Advisor: Date:
Table of Contents
Title ……………………………………………………………………………….1
Abstract …………………………………………………………………………...2
Table of Contents …………………………………………………………………3
Executive Summary ………………………………………………………………4
Overview of the Cornell ICE Cube Satellite Project ……………………………..5
The ICE Cube Simulation ………………………………………………………...5
The FreeFlyer Simulation ………………………………………………...6
The Matlab Simulation …………………………………………………...7
Simulation Results ………………………………………………………..9
Control Algorithms ……………………………………………………………….15
Decreasing Power Usage by Limiting Data Collection …………………..15
Decreasing Power Usage by Data Collection
and Communication Cycling ……………………………………..18
Increasing Power Generation by Attitude Control ……………………….20
Increasing Energy Storage by Battery Temperature Optimization …….…25
Work Remaining …………………………………………………………………32
Conclusion ……………………………………………………………………….33
Appendix A: Satellite Rotation in the Matlab Simulation ………………………34
Appendix B: Characterizing Battery Charge Efficiency ………………………..36
Appendix C: Memory Usage ……………………………………………………37
Appendix D: Matlab Simulation Code ………………………………………….38
Executive Summary
Mission planning is a critical step in ensuring project success. To devise a mission plan, it is first necessary to understand the environmental conditions in which the project will operate. Due to the nature of project, testing in true environmental conditions is not a feasible option; therefore most of the mission planning is based on computer simulation and testing in simulated environments.
A software package called FreeFlyer, by A.I. Solutions, Inc., is used to model the orbit of the satellite. By entering the theoretical orbital parameters of the satellite along with the location of the ground station, FreeFlyer is able to generate information pertaining to the position, velocity, received sunlight and communication window times and durations through the entire life of the mission.
Another simulation was created in Matlab that uses the information generated by FreeFlyer to model the behavior of the satellite through the duration of the mission. The Matlab simulation tracks power generation, power usage, battery charge level, power cycling schedules and memory usage. The results of the simulation revealed that power generation will be the largest constraining factor on-board the satellite. Using the results derived from the simulation, four algorithms are outlined to both decrease the power consumption and increase the power generation on the satellite.
Scintillations are known to occur with highest probability around the geomagnetic equator, between 1 and 4 hours after sunset. The first algorithm focuses on decreasing power usage by limiting data collection to times when data is predicted to be scientifically relevant.
The simulation showed that the amount of power generated on the satellite is correlated with the precession of the orbit. The second algorithm outlines a cycling scheme to decrease power usage during periods of low power generation.
The simulation also revealed that the orientation of the satellite in its orbit relative to the sun has an effect on power generation. The third algorithm attempts to maximize power generation by modifying the satellite orientation through the use of Attitude Determination and Control’s magnetic torquer coils.
Finally, the temperature dependent charge efficiency of the batteries is characterized. The last algorithm focuses on increasing energy storage by optimization of heater usage in affecting the temperature dependent charge efficiency of the battery.
Overview of the Cornell ICE Cube Satellite Project
The International CubeSat Project is a collaborative effort between California Polytechnic State University San Louis Obispo and Stanford University’s Space Systems Development Laboratory. The purpose of the project is to provide a standard for the design of picosatellites such that a common deployment mechanism can be used. Currently, more than 30 academic institutions around the world are developing satellites in conjunction with the CubeSat project.
The Cornell ICE Cube satellite team is a member of the International CubeSat Project. It is developing the first CubeSats to include an integrated science mission. The objective is to design and build two picosatellites for launch into low Earth orbit to study the effects of scintillations in the Earth’s ionosphere on communication signals.
Irregularly structured ionospheric regions can cause diffraction and scattering of trans-ionospheric radio signals. When received at an antenna, these signals present random temporal fluctuations in both amplitude and phase. Ionospheric scintillations may cause problems such as signal power fading, phase cycle slips, receiver loss of lock, etc. They are also known to degrade the quality of satellite navigation systems. This degradation lowers the signal-to-noise ratio of received GPS signals. The satellite will include an on-board GPS receiver, which will record the SNR of the received signal from the GPS satellites. This information will be stored on the satellite until it is transmitted to the ground station where it will be used to characterize the effects of the scintillations on communication signals.
On top of the requirements outlined by the CubeSat project, the inclusion of a science mission adds another set of requirements that must be met in order to achieve the science objective. The collection of data is limited by the amount of memory available for storage and amount of data that can be transmitted to the ground station. The relatively low altitude of the satellite orbit limits the amount of time available for communication and the data rate is limited by the amount of power available for transmission. The power on-board the satellite is limited by the number of solar cells used for power generation. The number of solar cells is limited by the available surface area on the outside of the satellite on which they are mounted. Finally, the CubeSat requirement that the satellites be built to the exact dimensions of a 10 cm cube limits the available surface area.
Ultimately, power is perhaps the single largest constraint on the project and much of the mission planning will focus on optimizing power generation and minimizing power usage.
The ICE Cube Simulation
Initially, the motivation of the simulation was simply to model the charge level of the battery throughout the mission life cycle. However, it became apparent that the simulation could also be used to understand many other aspects of the satellite’s environment. This understanding can then be used to define control algorithms that optimize the performance of the satellite.
The FreeFlyer Simulation
The simulation begins in FreeFlyer, which requires the user to input the orbital characteristics of the satellite. Since the exact orbit was not known at the time of simulation, one was selected with the available information[1]. In addition to orbital parameters, the user can also enter the location of a ground station so communication times can be simulated. The user then defines the duration of simulation and the resolution of the simulated points. The ICE Cube simulation is modeled for the entire six-month lifetime with a one-minute sample period.
FreeFlyer then allows the user to define the output of the simulation. Below is a list of the outputs followed by an explanation of each output and how it is used in the subsequent Matlab simulation:
Elapsed Minutes / Elapsed Days / Orbit NumberSpacecraft Position X / Spacecraft Position Y / Spacecraft Position Z
Spacecraft Velocity X / Spacecraft Velocity Y / Spacecraft Velocity Z
Sun Vector X / Sun Vector Y / Sun Vector Z
Shadow / Contact / Time Of Day
Spacecraft Latitude / Spacecraft Longitude / Contact Event Duration
Table 1: List of outputs of the FreeFlyer simulation/inputs in the Matlab simulation.
Since the sample period is one minute, the Elapsed Minutes vector is simply an integer index of sample points starting from time zero. The Elapsed Days is fractional counter of days starting from time zero. Neither Elapsed Minutes nor Days is currently used in the Matlab simulation. The Orbit Number is an integer vector that is sampled every minute, but only increments at the start of each new orbit. The Matlab simulation uses the Orbit Number to determine the orbital period. The Spacecraft Position vectors (X, Y and Z) are the component vectors in the Earth-Centered, Earth-Fixed (ECEF) reference frame in units of kilometers. The Spacecraft Velocity vectors are the component vectors in ECEF of the velocity of the satellite in units of kilometers/second. The Sun Vectors are the component vectors in ECEF of the position of the sun in units of kilometers. The Spacecraft Position vectors are used to define the position of the satellite as a single point in space. The Velocity vectors are used to define the orientation of the satellite. The Sun Vectors are used to determine the amount of solar flux incident on each of the sides of the satellite. The Shadow vector is a binary vector that is 1 if the satellite is in eclipse and 0 if it is in sunlight. It is used to set the solar flux incident on the satellite to zero when the satellite is in eclipse. It is also used as a parameter in a variety of control algorithms. The Contact vector is a binary vector that is 1 if the satellite is in a communication window and 0 otherwise. It is used in the simulation of energy consumed by the communication subsystem when transmitting. The Time of Day is outputted in GMT and the Latitude and Longitude of the satellite are recorded in degrees. The Time of Day, Latitude and Longitude is information that will be available on-board the satellite and thus can be used in defining control algorithms. As stated previously, each of these outputs is a vector sampled at one-minute intervals with the exception of the contact event duration, which is a list of communication window durations. The length of the contact event duration vector is dependent on the number of communication windows during the simulated period.
The Matlab Simulation
The Matlab simulation imports all of the data described above along with a binary vector defining battery heater usage over a single orbit. This battery heater vector was originally obtained from the Thermal subsystem based on a thermal simulation in IDEAS and a certain control algorithm, but an analysis will be described later in the report to try to improve the efficiency of the battery heater vector in terms of maximizing battery charge level.
The simulation first calculates the amount of energy being generated by the solar cells each minute. To accomplish this, the spacecraft position vectors are used to determine the location of the satellite as a single point in the ECEF coordinate frame. Then the velocity vector is used to define the orientation of the satellite. Since the ADCS aero-fins maintain the pitch and yaw of the satellite, and the torquer coils control the roll, the simulation can assume that the satellite is always oriented in the direction of the velocity vector. Once the orientation is known, the surface normals can be calculated. Using the sun vector, the simulation determines the amount of solar flux incident on each of the sides at any given time. A positive flux indicates that the panel is exposed to the sun. A negative flux indicates that the panel is on the shadow side of the satellite. A negative flux is set to zero. Then the sun light vector (inverse of the shadow vector) is used to mask the solar flux when the Earth eclipses the satellite during its orbit. This information, along with the solar flux at low Earth orbit altitudes, area of solar cells on each panel and efficiency of the solar cells, is used to calculate the power generated by each panel of solar cells every minute. The sum of power generated by each panel is the total power produced by the solar cells.
Below is a diagram of the components of the power subsystem relevant to the charging of the batteries.
Figure 1: Simplified circuit diagram of the power subsystem relevant
to the charging/discharging of the batteries.
Between the solar cells and the batteries is a voltage regulator that maintains voltage used to charge the batteries. This regulator has an efficiency of 75%. The power used by the various components when the satellite is in the sun may come entirely from the cells if they are producing sufficient power. If they are not, the remainder of the power is drawn from the batteries. The power drawn from the batteries is subject to a loss on discharge efficiency on top of the loss from the 12V regulator efficiency. Because the components of the satellite require different voltage supplies, there are two more voltage regulators on the power board. The 3.3V and 5V regulators are both 90% efficient.
The simulation takes all of these efficiencies into account when calculating the charge level of the batteries. Then the simulation defines the power consumed by each of the components when they are on. This information was provided by the power subsystem and was compiled from estimates provided by each of the other subsystems. At the time this report was written, these specifications had not yet been tested for validity and are subject to change.
In addition to tracking the charge level of the batteries, the simulation also tracks the amount of memory used to store telemetry and GPS data. The memory used to store telemetry and data is located on the Command and Data Handling (C&DH) board. Information about the memory available for storage was provided by the C&DH subsystem. The amount of telemetry stored per minute was obtained from the data budget and the amount of GPS data collected per minute was provided by the GPS Science subsystem. A plot showing the simulated memory usage throughout the mission lifetime can be found in Appendix C.
The first version of the simulation included virtually no control algorithms, except that the GPS receiver was limited to collecting data when the satellite passed through the equatorial region. The simulation was simply meant to track the battery charge level. When the simulation showed that there was not always sufficient power in the batteries to supply all the loads, control algorithms were added to the simulation in an attempt to decrease the power consumption when the battery charge level was low.
The code for the control algorithms is not easily understood upon inspection. The logic behind the algorithms will be explained later in the report. However, it is worth noting that much of the complexity of the code is due to the nature of the simulation and not due to the complexity of the control algorithms. For example, since communication is established only if communication windows are longer than 6 minutes, it is not enough to know that the satellite is in a communication window, but it is also necessary to know how long that window will last. The simulation uses the Contact Event Duration vector described in the FreeFlyer Simulation section above. This vector lists the exact duration of each communication window. However, the vector only lists each of the window durations and not when the communication occurs. Therefore, it is necessary to create a counter that increments only when the satellite enters a communication window. The only way to determine this is to use the binary Contact vector and increment only on the transition from 0 to 1. This roundabout method is an artifact of the simulation and will not be necessary when implementing algorithms on the satellite.
The code for the Matlab simulation can be found in Appendix D.
Simulation Results