Docstoc

MEng_Report

Document Sample
MEng_Report Powered By Docstoc
					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:


                                                                                      2
                            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




                                                                             3
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.




                                                                                                  4
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



                                                                                            5
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 information1. 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 Number
    Spacecraft 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

1
  When a more precise orbit is known, another FreeFlyer simulation should be run which generates the
same output vectors so that a more accurate Matlab simulation can be produced.



                                                                                                       6
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.




                                                                                            7
                                            3.3V Regulator              3.3V Loads
                                                (90% efficiency)




                     Solar Cells              5V Regulator              5V Loads
                     (26% efficiency)           (90% efficiency)




                   12V Regulator                                        12V Loads
                     (75% efficiency)




                                                 Batteries
                                           (90% discharge efficiency,
                                             temperature dependent
                                                charge efficiency)




               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.




                                                                                             8
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

It was always known that power was going to be a primary constraint of the mission.
Originally, it was assumed that the satellite was never going to be generating enough
power to collect and transmit data whenever possible. The proposed solution was to
implement a fixed cycling scheme in which data was collected only once every X number
of possible collection times, and communication was attempted once every Y number of
windows of opportunity, where X and Y were increased until power usage was within
acceptable limits.

As stated previously, one of the main advantages of using simulations is the ability to
gain a deeper understanding of the environment of the satellite. The top half of the
following plot shows the energy generated by the solar cells and the bottom shows the
battery charge level. Both are plotted over the entire six-month mission. This particular
simulation did not include any cycling scheme.




                                                                                            9
           Figure 2: Plot of the energy generated by the solar cells and the energy stored in
           the battery over the six-month lifetime of the mission without the implementation of
           a cycling scheme.

From this plot we can see that the vast majority of the time, the batteries are near full
capacity, even without the use of cycling. However, there are periods of time when the
level of the batteries drop drastically. By comparing the cell energy and battery level
plots, we notice that the drops in battery level correspond to drops in the energy produced
by the solar cells. This seems intuitively obvious, but what is not obvious is what is
causing the energy generated by the solar cells to vary over time.

The following plot shows the energy generated by each of the panels of the satellite
(there are no solar cells mounted on the bottom of the satellite) over the six-month
mission lifetime.




                                                                                                  10
           Figure 3: Plots of the energy generated by each of the individual panels over the
           six-month mission lifetime.

Again, it is not intuitively obvious what is happening in this plot. All graphs are plotted
in the same manner, with points at every discrete value. It seems incorrect that the top,
front and back plots are solid, while the left and right are not. We can gain some insight
by zooming in on the plot. Figure 4 is the same graph as above, except it is plotted over a
single orbit instead of a six-month window. By looking at figure 4, it becomes obvious
why the top, front and back appear solid in figure 3. The amount of flux varies from zero
to some maximum value every orbit. Keep in mind that there are nearly 3000 orbits
plotted in figure 3, which is why the plots look solid. The left and right panels, however,
remain at a constant value when in sunlight. That is why they do not appear as solid in
figure 3.




                                                                                               11
           Figure 4: Plot of the energy generated by each of the panels over a single orbit.

In this particular orbit, the right panel is receiving a constant amount of sunlight while the
left receives none. One can tell that this plot is correct by thinking about the orientation
of the satellite as it travels through its orbit. The front side of the satellite is always
facing in the same direction as the velocity vector. When the satellite first comes out of
eclipse, the front of the satellite is facing the sun. We can see that the satellite comes out
of eclipse about 1/5 of the way into the plot in figure 4. As the satellite travels around its
orbit, the top panel begins to be exposed to the sun. As the satellite crosses the equator in
the middle of the plot, the top side is receiving its maximum amount of sunlight. At this
point, the front and back panels are almost completely perpendicular to the sunlight
vector, which is why the power generation is nearly zero for both of these sides. Then as
the satellite continues, the back side begins to receive more sunlight until the satellite
enters back into eclipse. It makes sense that the front and back sides can never receive
sunlight simultaneously, and likewise, in figure 3, the left and right sides can never
receive sunlight simultaneously. It is a little more difficult to understand why the left and
right sides receive a constant amount of sunlight over a period of one orbit (while not in
eclipse).

To gain an intuitive understanding of what is happening, first imagine a polar orbit, in
which one of the two sides (left or right) is constantly facing the sun. Six months later,
when the Earth has moved halfway through its orbit, the other side is constantly facing
the sun. In between these two points (at 3 months), both the left and the right sides are


                                                                                               12
parallel to the sunlight vector, and neither receives any sunlight. This is effectively what
is happening when the left and right sides alternate in prolonged periods of constant
exposure to the sun. But this switch occurs much more often than once every 6 months.
In fact, with this particular orbit, the switch occurs approximately once every month.
This is due to the precession of the orbit. The precession is caused by the fact that the
Earth is not a perfect sphere. The bulge in the equatorial region produces a torque on the
orbit, which causes it to precess.

Now that there is a basic understanding of why the energy generated by the solar cells
varies over time, we examine how this affects the satellite. Figure 5 shows the
correlation between the power generated by the left and right panels and the minimum
power generation by all of the solar cells.




           Figure 5: The plot show the total energy generated by the solar cells from figure 2
           along with the energy generated by the left and right panels. All plot are over a six-
           month window. Minimum power generation corresponds to the times when the
           sunlight vector is perpendicular to the left and right panels and neither is producing
           any power.

It is apparent that times of minimum power generation correspond to the periods when
the sunlight vector is parallel to the left and right panels and neither is producing any
power. Recalling from figure 2, these times also correspond to when the battery is unable
to maintain its charge level, and drops rapidly. The battery level drops because during



                                                                                                    13
these times, the amount of power being generated per orbit (on average) is less that the
power being consumed by the satellite.

If the batteries are ever completely discharged, the satellite shuts off and any telemetry
and data stored in memory is lost. Needless to say, communication is not possible when
the satellite is off. When there is sufficient power for the satellite to start up again, it
essentially starts over. It must go through its initialization and re-determine its orbit
before it can begin collecting data again.

Many ideas were considered to prevent the battery charge level from falling. Some of the
more obvious ones, such as increasing the charge capacity by adding more batteries, were
found to have little merit. The problem is not that the satellite cannot store enough
power; it is that there are periods of time when the solar cells cannot produce enough
power. Figure 2 showed a very optimistic estimate of battery charge level. Figure 6
shows a pessimistic estimate.




           Figure 6: Pessimistic estimate of battery charge level over the six-month lifetime.

Notice that in both figure 2 and 6, once the battery level begins to drop, it plunges very
quickly. The battery level can drop from full to zero in a span of a few days, and it can
stay at that level for weeks. Doubling the capacity of the batteries will double the amount
of time it takes for the batteries to completely discharge, but it will not prevent the
batteries from discharging fully.



                                                                                                 14
Another obvious solution would be to add more solar cells. Unfortunately, there is no
more surface area left on the satellite for the addition of solar cells without requiring
major structural redesign.

Control Algorithms

Since the addition of hardware is either not viable or not feasible, the next logical step is
to focus on reducing power usage and maximizing power generation within the
constraints of existing hardware. This is achieved through the use of control algorithms
on the satellite. When devising such algorithms, it is necessary to keep in mind what
information is available to the satellite that can be used to define the control logic. Also
remember that many of the parameters specified in the following control algorithms are
orbit dependent. They are correct for the particular orbit used in the simulation, but may
not be appropriate for the actual orbit of the satellite. Every effort will be made to
explain how each of the parameters varies depending on the orbit. Once a final orbit has
been chosen, all of these control parameters should be reviewed for validity.

Decreasing Power Usage by Limiting Data Collection

Reducing the amount of data collected decreases power consumption in two ways. First,
it reduces the power consumed by the GPS receiver, which is used to collect the data.
Second, it reduces the power used by the communication board, which is used to transmit
the data to the ground station.

Originally, the plan was to collect data every time the satellite passed through the
equatorial region. This meant that the satellite would collect two sets of data every orbit,
which translated into a considerable amount of information that had to be stored and
transmitted to the ground station.

After consulting with members of the GPS science subsystem, it was learned that
scintillations in the ionosphere occur with highest probability near the geomagnetic
equator, 1 to 4 hours after sunset. It is possible to implement a control algorithm that
limits data collection to times when these conditions are met.

First, it is worth mentioning how the satellite will determine if it is in the equatorial
region. Establishing that the satellite is near the equator requires the satellite to know
approximately where it is. Conveniently, there is a GPS receiver on-board to provide this
information. However, in the interest of conserving power, the GPS receiver will not be
on all the time. In fact, the satellite will only turn on the receiver when it enters within
20 of the equator. But without the GPS receiver on, the satellite does not know whether
it is within 20 of the equator. To solve this problem, there is on-board software, called
the Orbit Propagator, which takes the navigation solution from the GPS receiver and
determines the orbit of the satellite. Once the orbit is determined, the GPS receiver can
be turned off and the software can extrapolate forward (within reasonable time limits) to
determine where the satellite will be at a given time in the future.




                                                                                            15
The GPS receiver only needs to collect data 10 above and below the geomagnetic
equator. But the satellite needs to be turned on before data collection begins to acquire
GPS satellite signals and calculate a navigation solution. The GPS subsystem specifies a
5-minute requirement for a warm start. This means that the GPS receiver must be turned
on at a latitude such that at least 5 minutes elapse before the satellite enters the data
collection region. The correct latitude depends on the angle of inclination and (to a
lesser extent) the altitude of the orbit. To determine this latitude, enter the correct orbital
parameters into FreeFlyer and look at the Latitude output vector. Note when the satellite
enters the data collection region (10) and propagate backwards 5 minutes and note the
latitude. This will be the control parameter for when the GPS receiver should be turned
on.

There is a fixed relationship between the celestial and geomagnetic equators. The GPS
receiver and the Propagator both use coordinates relative to the celestial equator, but
ionospheric scintillations occur relative to the geomagnetic equator. This should be taken
into account in the control algorithm. This can be accomplished by finding a relationship
that can transform between the two coordinate systems or by creating a look-up table that
can map one set of coordinates to the other.

The Propagator software has two modes of operation. Either it can be passed a latitude,
in which case it returns the time when that latitude will be crossed or it can be passed a
time in which case it returns the latitude and longitude of the satellite at that time. The
control algorithm should pass the propagator the latitude determined above and check
against the returned time to determine when to turn on the GPS receiver.

A simple way to cut the amount of data collected in half is to set another condition that
only turns the GPS receiver on if the satellite is in eclipse. This condition includes the
entire window of 1 to 4 hours after sunset. The satellite can easily tell if it is in eclipse by
checking the voltage generated by the solar cells. If they are all nearly zero, then the
satellite is in eclipse.

However, with the extra control parameter that was just described, the satellite is still
taking much of its data at times when scintillations are not highly probable. A more
complicated control algorithm can be implemented to further limit the amount of data
collected. This algorithm uses the longitude from the propagator and the clock on the
C&DH board (synchronized with the GPS clock) to determine the local time in the region
of Earth directly below the satellite. This is a straightforward calculation once time is
obtained in a standard format, such as GMT. Sunset always occurs at around 6 pm at the
equator. So the scintillations occur with highest probability from 7 to 11 pm in the
equatorial region. An hour is added before and after this window, so no relevant data is
missed. The control algorithm then collects data whenever the satellite is in the
equatorial region if the local time below is between 6 and 12 pm. The plot in figure 7
shows the windows during the mission lifetime when these conditions are met.




                                                                                             16
           Figure 7: Energy used by the GPS receiver throughout the six-month mission
           when data collection is subject to the local time based control algorithm.

What we learn from this plot is that satisfying the conditions of the control algorithm is
correlated with the precession of the orbit. That is why there are long periods of time
when the conditions are never satisfied and the GPS receiver never turns on. This
correlation may not be intuitively obvious, but it does make sense. First imagine the
solar system where the Earth is fixed and does not rotate nor revolve around the sun.
Then imagine an orbit that does pass from sunlight into eclipse, but does not precess.
The satellite always passes the equator over the same two places, and it is always the
same time of day at those places. Now allow the Earth to rotate, but still do not allow the
orbit to precess. Now the satellite passes the equator over different areas of the Earth, but
it is always the same time of day in those places when the satellite passes overhead. Now
allow the orbit to slowly precess. The time of day when the satellite passes the equator
now changes slowly with each orbit. As the orbit precesses, it enters a window in which
the conditions are always met, and eventually it exits that window and there is a period of
time when the conditions are never met.

Though this control algorithm drastically reduces the amount of data taken, it is
undesirable to have prolonged periods of time when no data is collected. By
implementing the control algorithm that simply checks if the satellite is in eclipse, data is
always taken once per orbit. Even though most of this data will have no scientific value,
it at least serves as an indicator that the satellite if functioning properly. It is therefore
recommended that the local time based control algorithm not be implemented on the
satellite.

As indicated by the previous analysis on battery charge level, most of the time the
satellite will have sufficient power to collect data (and subsequently transmit that data)
once per orbit, so there is no reason to limit the collection of data during those times.
However, data collection should be limited during periods of low power generation. A
control algorithm to accomplish this will be discussed in the next section.

Finally, this analysis also provides some insight into selecting an orbit for the mission.
Since scintillations usually occur for a small window of time once every six months,



                                                                                             17
choosing an orbit with a high rate of precession will maximize the likelihood that the
satellite will be in a position to take data in regions where the scintillations are occurring.

Decreasing Power Usage by Data Collection and Communication Cycling

A cycling scheme was proposed earlier, but the simulation showed that a fixed cycling
schedule is not necessary. Most of the time, the solar cells are producing sufficient
energy to keep the batteries fully charged, even when data is being taken at every
opportunity and communication is established whenever possible. Instead the satellite
should only cycle data collection and communication when it enters a period of low
power generation. The following discussion outlines a method that allows the satellite to
detect when it is entering such a period.

The algorithm requires knowing the orbital period, the value of the battery current
counter and the voltages from the solar cells. The orbital period should be able to be
obtained from the Propagator. The current counter is located on the power board and the
solar cell voltages are recorded at one-minute intervals by C&DH and stored as
telemetry.

As its name implies, the current counter tracks the current going in and coming out of the
batteries. This information should give a rough estimate of the charge level of the
batteries. If the counter drops below a predetermined level, then the satellite will enter
into cycling mode. This threshold will have to be hard coded into the algorithm. From
the simulation, it would appear that if the charge level of the batteries drops below 75%,
the satellite is entering a period of low power generation. If this algorithm is
implemented on the satellite, it will be necessary to consult the power subsystem on how
the current counter functions. Once the satellite enters the cycling mode, it will sum all
the voltage readings from all the solar cells over the last orbit. Knowledge of the orbital
period is necessary to determine how many voltage readings to sum. It might be
acceptable to choose an arbitrarily long number of voltages to sum over, but it is safer to
use however many are in an orbit.

The result of this summation will be the control parameter that determines when the
satellite will switch out of cycling mode. Once in cycling mode, the satellite will sum the
voltages of the solar cells over one orbital period each time it completes another orbit.
As long as the result of the summation is less than the control parameter, the satellite will
remain in cycling mode. The assumption is that if the current counter drops below the
threshold, the satellite has just entered a period where the two side panels are nearly
parallel with the sunlight vector. The total voltage (and thus the power generation) of the
solar cells over an orbital period will continue to drop until the two side panels are
perfectly parallel with the sunlight vector. Then the side receiving sunlight will switch
and the voltage will begin to increase. Once the solar flux incident on the new side is
enough to bring up the total voltage to above the control parameter, the satellite will
switch out of cycling mode.




                                                                                             18
It might be found that summing voltages over a single orbit causes the cycling to turn on
and off in rapid succession due to noise in the voltage measurements. It may be
necessary to sum voltages over two or three or more orbits to remove this effect. Keep in
mind that C&DH stores the voltages as telemetry, but deletes them after they have been
transmitted to the ground station. It may be necessary to allocate some space in memory
to store these values so that they are always available when needed.

The Matlab simulation does not use a current counter in its implementation of this control
algorithm. It simply checks the voltage level of the two side panels over the last orbital
period. The reason the algorithm cannot be implemented in this manner on-board the
satellite is that the threshold voltage had to be obtained by inspection and then hard coded
into the algorithm. There is no accurate way to determine this value before the satellite is
in its orbit. That is the benefit of using the current counter; it does not require a priori
knowledge of the voltages produced by the solar cells.

In figure 8, the broken line underneath the plot of the solar cell energy indicates when
cycling is turned on. Notice that it corresponds to periods of low power generation when
the battery level drops.




           Figure 8: Solar cell energy and battery charge after implementation of a cycling
           scheme (cycling interval of 5). The broken line under the solar cell energy indicates
           when cycling is on. Note that it is on when the power generation is low, but does not
           prevent the battery charge from dropping to zero.




                                                                                                   19
Determination of the exact cycling interval (i.e. the number of data collection and
communication opportunities to skip between attempts) is still pending further study.
The plot of battery charge level in figure 8 shows that even with cycling, the battery level
still drops to zero. According to the simulation, with the current level of power
generation, even if the GPS and communication boards are never turned on during the
cycling period, the solar cells are still not producing enough power to sustain the basic
functions of the satellite, and the batteries still completely discharge. This is the
motivation for the next category of control algorithms.

Increasing Power Generation by Attitude Control

By simulating the last two control algorithms, we have learned that reducing power usage
may not be enough to keep the batteries from discharging fully. There is a minimum
amount of power that the satellite must use to remain operational and it appears that there
are times when the solar cells are not producing enough power to meet that minimum
requirement. We now focus on increasing power generation to meet that minimum
requirement. The first proposed solution is to use the ADCS torquer coils to roll the
satellite a few degrees in order to increase the amount of solar flux incident on one of the
two side panels when the sunlight vector is nearly parallel to the two sides.




               Figure 9: Proposed solution to increasing power generation by rolling
               the satellite in one direction, and then switching to the other to increase
               solar flux incident to the two side panels.

The satellite cannot be rolled more than 20 in either direction because the
communication antenna on the bottom of the satellite must remain pointed downwards
and the GPS antenna on the top side of the satellite must be pointed upwards.




                                                                                             20
There is no straightforward way to simulate how this solution would directly affect
battery charge levels. Instead, the Matlab simulation was modified by rotating the matrix
that defined the satellite orientation by the maximum allowable roll of 20. Details of
this modification are provided in Appendix A.

The assumption is that this rotation would shift the cell energy plot by a small amount.
By comparing the shifted plot with the un-shifted plot at the point of minimum power
generation (of the un-shifted plot) we can estimate how much more power will be
generated when the satellite is torqued. This simple test only torques the satellite in one
direction. In an actual implementation, the satellite would switch from one side to the
other, depending on which side maximizes power generation.




           Figure 10: Comparison between solar cell power generation of un-torqued satellite
           (background) and satellite torqued by 20 (foreground).

The points of interest are the periods of minimum power generation of the un-torqued
satellite, indicated by the arrows. By comparing the power generated over a single orbit
at those points, we can determine how much we can expect the power generation to
increase by implementing this solution.




                                                                                               21
The following table compares the power generated over one orbit by the un-torqued
satellite versus the satellite torqued by 20. The comparison is done at the first minimum
indicated by the arrow on the left in figure 10.

                                        Power Generated (Watt-hours)
                        Un-torqued                1.8171
                        Torqued                   2.0989

                 Table 2: Power generated over one orbit by the un-torqued satellite
                 versus the satellite torqued by 20.

Rolling the satellite by 20 increases the power generation by 15.5% during this orbit. To
find out if this increase is sufficient, we look at the minimum amount of power that must
be used per orbit.

                     Component                    Power Used (Watt-hours)
                     C&DH Board                           0.54250
                     Power Board                         0.516662
                     Battery Heaters                      0.35000
                     ADCS Torquer Coils                   0.25833
                     ADCS Magnetometer                    0.01302
                     GPS Memory                           0.02755
                     Thermal Sensors                      0.00004
                     Total                                1.70810

                 Table 3: Power used each orbit by essential components. This list does
                 not include power used for data collection or communication.

It appears as if the minimum required power of the satellite is less than the minimum
power generation of both the torqued and un-torqued orbits. But the power generation in
table 2 does not take into consideration battery charge efficiency, nor does the power
consumption in table 3 take battery discharge efficiency into account. There is no simple
way to factor these efficiencies into the calculation because not all the power that is being
generated is going into the battery. Likewise, not all the power that is being used is
coming from the batteries. The battery only charges when the energy currently generated
exceeds the energy currently used. The battery discharges when there is no power
generation (when the satellite is in eclipse) and when the energy currently generated is
less than the energy currently used (the simulation does take all of this into account when
tracking the battery charge level). It would probably be a safe estimate to assume that the
aggregate effect of the efficiencies would be to increase the power used by 5% and
decrease the power generated by 15%. Table 4 shows how this would affect the above
results.


2
  The energy used by the power board was not specified in the document provided by the Power subsystem.
A very cautious over-estimation of 0.3W was assumed here (and in the simulation). It is more likely that
the actual power consumption of the board is less than 0.1W.


                                                                                                     22
                                                               Watt-hours
                       Un-torqued Power Generation              1.5445
                       Torqued Power Generation                 1.7841
                       Total Power Consumption                  1.7935

               Table 4: Comparison of torqued/un-torqued power generation with
               power consumption after factoring in effective battery charge/discharge
               efficiencies.

It is clear that the power generated by the un-torqued satellite is not sufficient to power
the satellite. The power generated by the torqued satellite is very close to the minimum
power required. Keep in mind that this is the orbit with the lowest power generation.
There are probably only a handful of orbits each window of low power generation that
are producing less than the minimum power requirement. If data collection and
communications are stopped prior to entering these orbits, then the battery should hold
enough charge to sustain the satellite through this period.

It appears that there is a benefit to using this control algorithm. The drawback is that
there may not be an easy way to implement it. If we can assume that the exact orbit will
be known before this algorithm is written, and if the simulation in FreeFlyer is an
accurate representation of the satellite’s orbit, then the implementation will be
straightforward. If not, the algorithm becomes very complicated.

We will start with the optimistic case, in which the orbit is known and FreeFlyer is
accurate. We know that the periods of low power generation are correlated with the
precession of the orbit, and precession has a certain periodicity. It is not enough to
simply know the Keplerian elements and the rate of precession of the orbit, just like it is
not enough to define a sinusoid by only its amplitude and frequency. There are an
infinite number of sinusoids with the same amplitude and frequency that are simply phase
shifted relative to each other. Likewise, the exact phase of the precession (relative to the
position of the sun) must be known. If FreeFlyer can accurately synchronize the phase of
the precession with known times, then the control for when to switch from one side to the
other can be coded into the satellite. Some research into orbit selection and FreeFlyer
will have to be done to see if this information can be determined. If it can, then creating
the algorithm is very simple.

To determine the control parameters for the algorithm, simulate the correct orbit in
FreeFlyer and run the Matlab simulation with the generated output. Look at the plot
entitled Cell Energy by Panel. The relevant portion of that plot is shown below.




                                                                                          23
             Figure 11: Power generation of the left and right panels of an un-torqued satellite.
             The arrows correspond to times when the satellite should switch from rolling one
             direction to the other in order to increase power generation.

Determine the time corresponding to the arrows. These are the times when the satellite
must switch from rolling one direction to the other. The satellite must compare the
current time with these known times to decide which direction it should be oriented in.
When the sunlight is known to be incident on the right panel, roll the satellite 20
counterclockwise ( = -20). When the sunlight is known to be incident on the left panel,
roll the satellite 20 clockwise ( = 20)3.

If the plots in figure 11 cannot be accurately generated, then the switching times cannot
be coded into the algorithm. The satellite will not know the optimal time to switch from
one side to the other. The only way for it to determine which side is more efficient is to
periodically check by switching sides. This implementation is contingent on the ability to
get an accurate voltage reading when the satellite switches sides. This may not be
possible because there is quite a bit of variance between the desired angle and the actual
angle of the satellite. According to ADCS, the satellite will oscillate about the desired
angle with a variance of as much as 10. More research will have to be done to
determine if this is a viable option.

The last suggested implementation assumes that the rate of precession is known, but the
phase of precession is not. In this case, the satellite simply has to determine a point to
synchronize its control algorithm with. When the satellite is launched, it will note which
of the two sides is receiving sunlight. It will remain un-torqued until the voltage from
both panels is equal (most likely the voltages will be 0). At this point, the satellite knows
it has reached a time of minimum power generation and it can use this fixed point and its

3
  It may not be desirable to keep the satellite tilted at an angle when it can produce sufficient power without
torquing.


                                                                                                            24
known rate of precession to propagate forward to determine when it should switch sides.
This seems like a simple solution, but there is no guarantee that the satellite will have
enough power to remain operational until this information can be ascertained. Clearly,
there are still many questions that have to be answered before deciding if this algorithm is
appropriate for the mission.

Increasing Energy Storage by Battery Temperature Optimization

A means of increasing energy storage is by optimization of the battery heaters. The
charge efficiency of the batteries is temperature dependent. There are heaters in the
battery pack that can be used to control the temperature of the batteries. Attached to the
battery pack are thermal sensors that measure battery temperature. The temperature
inside the satellite varies from -15 to 5 C. According to the specifications provided by
the manufacturer, in order to charge, the batteries must be at or above 0 C.

The thermal subsystem was given the requirement to keep the battery temperature above
0 C whenever the satellite is in sunlight. This requirement was used to determine how
much power is used by the heaters in the Matlab simulation. From table 3, we can see
that the battery heaters use a significant amount of power to meet this requirement.

Initially, the requirement that the batteries had to be above 0 C in order to charge was
taken at face value. But after calculating how much power the heaters were actually
using, it seemed that perhaps the power used to heat the batteries was more than the
power gained by the increase in charge efficiency. This was the motivation for
optimizing the use of the battery heaters.

The first step in optimization was to characterize the relationship between the various
components of the battery charging system. Figure 12 shows the components relevant to
optimizing the system.

                                        Eb = F(T) (Ein - Eh)


                                 Ein                           Eh
                Solar Cells                  Batteries                  Heaters




                                             Charge
                                            Efficiency
                                               F(T)


           Figure 12: The components of the battery charging system. The efficiency is
           a function of battery temperature. The temperature of the batteries can be
           increased with the heaters.




                                                                                            25
We wish to maximize the temperature stored in the batteries. The amount of energy
stored, Eb, in a given period of time is represented by the following function

                                         Eb  F (T )Ein  E h 

where Ein is the energy from the solar cells minus the energy used by the components in
table 34, Eh is the energy going to the heaters and F is the charge efficiency, which is a
function of the temperature of the battery. The charging efficiency of the batteries is
temperature dependent, but the manufacturer does not provide any information
characterizing this relationship, so it had to be obtained through testing. Details of the
test design and procedure are provided in Appendix B. The results of the tests are shown
in figure 13.




             Figure 13: Measured temperature dependent charge efficiency of the batteries and a
             third order polynomial function fit to the data points.

A third order polynomial function was fit to the data points to define a charge efficiency
curve. The efficiency as a function of temperature can be defined as

             F (T )  0.000026192 T 3  0.00068513 T 2  0.017213 T  0.646128

4
 With the exception of the battery heaters because the energy they use will be accounted for in the
optimization.


                                                                                                      26
where T is measured in C. This function is only valid over the temperature range from
-15 C to 10 C. The optimization actually calculates temperature in Kelvin, therefore,
the equation for battery charge efficiency becomes

             F (T )  0.000026192 T 3  0.020766 T 2  5.46486 T  477 .79504

Again, this function is only valid for temperatures ranging from 258 K to 283 K.

Now that we have defined the charge efficiency of the battery as a function of
temperature, we must define the temperature of the battery, which is dependent on the
temperature of the outside of the satellite and whether the battery heaters are on. The
optimization is set up in discrete time so that the problem can be solved numerically. We
assumed a simplified thermal model for the optimization in which the change in battery
temperature from the heaters does not affect the temperature of the outside shell of the
satellite. With this assumption, the temperature of the batteries can be represented with
the following equation in discrete time

                                                t                               
                                                     uQh  R [Tb ] n  [Ts ] n 
                                                            1
                       [Tb ] n 1  [Tb ] n 
                                                mc                               

where t is the discrete time interval, m is the mass of the batteries, c is the specific heat
capacity of the batteries, u is a binary number representing if the heaters are on or off
(on = 1, off = 0), Qh is the power of the heaters, R is the aggregate thermal resistance of
the material separating the batteries from the outside of the satellite and Ts is the
temperature of the outside shell of the satellite. Below is a table of the values used in the
optimization.

                                    t                 100 s
                                    m                 0.06 kg
                                    c              896 J/(kg-K)
                                    R               12.77 K/W
                                    Qh                 1.5 W
                                    Eh          0.041667 (W-h)/t

                           Table 5: Parameters used in the optimization.

There are two time-varying inputs in the optimization, the temperature of the shell of the
satellite, Ts, and the energy coming from the solar cells, Ein. A vector defining the
outside temperature of the satellite over one orbit was obtained from the thermal
subsystem. This vector was determined from the thermal model in IDEAS. A vector
defining the energy from the solar cells over one orbit was obtained from the Matlab
simulation. Both of these vectors are defined at 100-second intervals. This time interval,
t, is used because the control algorithm for the heaters operates at this interval. This
means that the algorithm checks some condition (such as the temperature of the batteries)


                                                                                            27
to determine if the heaters should be turned on. If the condition is met (e.g. the battery
temperature is below the threshold), then the heaters are turned on and remain on for 100
seconds until the algorithm checks the condition again.

The orbit used in the Matlab and IDEAS simulations is 93 minutes in duration. There are
approximately 56 100-second intervals in the orbit. The optimization varies the length-
56 binary heater on/off vector, u, to find the optimal combination that maximizes the
energy stored in the battery over the orbit. The optimization was performed in Microsoft
Excel using the Solver add-in. Solver uses the branch-and-bound method for integer
optimization problems.

We want to find the optimal steady-state control algorithm, meaning we want the
temperature at the beginning of the orbit to be as close as possible to the temperature at
the end of the orbit. This ensures that we find the optimal heating times for every orbit as
opposed to just this particular orbit. To accomplish this, we set an initial battery
temperature, [Tb]0, and set a constraint in Solver that the final battery temperature ([Tb]56)
must be within a degree of [Tb]0.

Unfortunately, this gives us two types of variables that we can vary in the optimization.
Changing [Tb]0 can change the optimal u vector, and therefore can change the amount of
energy stored in the battery. Luckily, the optimal range of [Tb]0 is relatively small, so we
can manually vary [Tb]0 and let Solver find the u vector. We know we have found the
optimal initial battery temperature when the Solver solution (of energy stored in the
battery) is maximized relative to other initial battery temperatures. The optimal initial
battery temperature is usually between 0 C and 10 C.

The optimal [Tb]0 was found to be 6 C with a corresponding u vector shown below




           Figure 14: The optimal u vector does not turn the heaters on until the satellite is in
           sunlight. Once the heaters are turned on, they remain on for 10 consecutive 100-second
           intervals.

Compare that to the original u vector, which tried to keep the battery temperature at or
above 0 C whenever in sunlight.


                                                                                                    28
             Figure 15: The original u vector turns the heaters on mostly while the satellite is in
             eclipse. This control algorithm has the heaters turned on for a total of 16 100-second
             intervals.

When using the optimal heater vector, the battery stores 0.80 W-h of energy the orbit.
When the original heater vector is substituted in the spreadsheet, the battery stores 0.52
W-h of energy. With the optimization, there is almost a 54% increase5 in the amount of
energy stored in the batteries during this orbit. The results are tabulated below.

                         Optimal Heater Vector                   0.79908 W-h
                         Original Heater Vector                  0.51898 W-h
                         Difference in Stored Energy             0.28010 W-h
                         Percent Increase                           53.97%

                 Table 6: Energy stored in battery using the optimal u vector versus
                 the original u vector during one orbit.

This simulated increase in stored energy is meaningless unless we can implement a
control algorithm that can turn the heaters on at the optimal times. It is not desirable to
code the u vector directly into the algorithm, because it is only optimized for this
particular orbit. In the actual orbit of the satellite, there may be more or less than 56 100-
second intervals, and then the algorithm would no longer be appropriate. We must
therefore find some correlation between when the heaters are on and conditions in the
satellite that can be measured.

The algorithm originally proposed by the thermal subsystem uses the measured battery
temperature as the condition for determining if the heaters should be on. This algorithm
is fairly complex because it tries to maintain the temperature of the batteries above a
certain temperature only when the satellite is in sunlight. It does not matter how low the
temperature drops while in eclipse as long as it is at or above threshold when it enters
into sunlight. For this reason, it is not feasible to simply enter a minimum battery
5
 This is not a 54% increase compared to the results of the Matlab simulation. The simulation outlined
previously does not yet take into account the temperature dependence of the charge efficiency.


                                                                                                        29
temperature and always check against this condition. This method requires that the
algorithm be synchronized with the orbit and estimate how long the heaters must turned
on in order to bring the batteries up to threshold by the time the satellite enters into
sunlight.

Since the battery temperature was a control condition in the original algorithm, it seemed
like a good starting point for the new algorithm. But, as can be seen in the following
plot, there is not a high correlation between the battery temperature and the optimal times
for the heater to be on that can be used for control.




           Figure 16: Comparison of the battery temperature with heating and the u vector.

If it appeared that the heaters were trying to maintain the batteries at a certain
temperature, then using a temperature threshold would seem appropriate. An argument
could be made that the heaters try to bring the temperature of the batteries up to at least
-5 C once the satellite is in sunlight, yet when the temperature drops below -5 C after
the heaters are turned off, it is not in the interest of efficiency to turn them back on. This
is because it is not efficient to leave the heaters on for only a short period of time. It
seems safe to assume that the optimal time to turn the heaters on is when the satellite
enters sunlight. The best temperature controlled algorithm would probably heat the
batteries to a predefined temperature (in this case -5 C) and then turn the heaters off for
the remainder of the orbit. However, this temperature-controlled algorithm would just be
an ad hoc implementation that seems to work, without any justification for why it works.


                                                                                             30
To gain a deeper understanding of the optimization, we compare the optimal heating
times to the energy coming from the solar cells.




             Figure 17: Comparison of the energy from the solar cells, E in, and the u vector.

We can immediately see a relationship between the two plots. The heaters turn on at
approximately the time when the solar cells start producing energy (when the satellite
enters sunlight). They remain on as long as the energy the cells are producing increases.
Once the Ein starts to decrease, the heaters turn off. What this suggests is that, instead of
measuring battery temperature, we can use the sum of the voltages produced by the solar
cells to control the battery heaters. Implementation of this control algorithm is very
straightforward. The heaters turn on once the solar cells start producing a voltage, and
are kept on as long as the currently measured voltage of the cells is greater than the
previously measured voltage6.

The optimization assumes that the amount of energy coming from the solar cells is the
same every orbit. However, we know from the Matlab simulation that this is not the
case. The characteristic shape of the curve in figure 17 remains the same, but the amount
of energy fluctuates from orbit to orbit. During periods of low power generation, it might
6
  There is a brief period of time starting from approximately n = 41 when the solar cell voltages increase. It
is probably not desirable to turn on the heaters during this period. There may have to be additional logic in
the control algorithm to prevent this from happening.


                                                                                                           31
be more efficient to heat the batteries less. Since generated power first goes to
components that are on, and only what is left over is stored in the batteries, if there is no
power left after supplying the components, there is no point in heating the batteries. It
might be appropriate to add another condition that requires the batteries to be charging
for the heaters to be turned on. This is merely an assumption. Further study would have
to be performed to characterize the relationship between optimal battery temperature and
energy generated by the solar cells to determine if this assumption is correct.

Work Remaining

Once the actual orbit of the satellite is determined, another simulation should be run in
FreeFlyer with the correct orbital parameters. Using the output, the Matlab simulation
should be run again to check the validity of the control algorithms.

A general method for defining when the satellite should enter cycling mode has been
defined in the section entitled Decreasing Power Usage by Data Collection and
Communication Cycling. However, the actual details of the cycling algorithm (i.e.
cycling interval, coordination with the ground station) have yet to be defined.

If the control algorithm outline in the section Increasing Power Generation by Attitude
Control is to be implemented, some research should be done into whether FreeFlyer
accurately simulates the phase of orbital precession to decide if the control for the
algorithm can be directly coded into the satellite.

The Matlab simulation does not yet account for the temperature dependence of the
battery charge efficiency. To create a more accurate model of the mission, the results
from the battery temperature optimization should be incorporated into the simulation.
This will require tracking the battery temperature with the equation

                                                       t                               
                                                            uQh  R [Tb ] n  [Ts ] n 
                                                                   1
                              [Tb ] n 1  [Tb ] n 
                                                       mc                               

described in the section, Increasing Energy Storage by Battery Temperature
Optimization. The equation can be tracked in the main loop of the simulation, entitled
calculating power and data usage. The battery charge efficiency should be updated
within the loop7 as well, according to the equation

                  F (T )  0.000026192 T 3  0.020766 T 2  5.46486 T  477 .79504

The efficiency must be calculated in terms of Kelvin because the temperature equation
above is defined in Kelvin. The efficiency should be updated before it is used at the end
of the loop to calculate battery charge.



7
    Currently, the battery charge efficiency is defined outside the main loop in the initializations.


                                                                                                        32
According to the battery specifications, the discharge efficiency is more temperature
invariant than the charge efficiency. However, it may be worthwhile to characterize the
temperature dependency of the discharge efficiency as well, to determine if the batteries
should be heated in eclipse.

Conclusion

Although much effort was put into making the simulation as thorough as possible, it is
still far from modeling all of the aspects of the satellite’s behavior and environment. It is
tempting to assume that the simulation is always an accurate reflection of reality and it is
easy to look at results from the simulation and identify correlations that, in actuality, do
not exist. It is therefore necessary to be cautious of an over-reliance on simulation.

However, it is undeniable that we have gained a deeper understanding of the mission
through the use of simulation. It has revealed that careful planning is necessary in order
to sustain the power requirements of the satellite. Much insight has been gained by
studying the results of the Matlab simulation. From this insight, we were able to outline
two algorithms that can be used to reduce the amount of power usage and two algorithms
that should increase the power generation and energy storage on the satellite.

At this stage, these algorithms are merely suggested ideas. They should be verified for
validity8 before implementation, either through independent simulation or from expert
opinion. Implementation of some algorithms will require careful coordination between
many subsystems. There are many details that, for the sake of brevity, were not included
in this document. A thorough understanding of the simulation, the subsystems and the
satellite as a whole is strongly recommended before the implementation of control
algorithms begins.




8
 The control algorithm defined in the section entitled Increasing Power Generation by Attitude Control
must first be verified for feasibility with the ADCS subsystem.


                                                                                                         33
Appendix A

Satellite Rotation in the Matlab Simulation

The orientation matrix is defined in the ECEF coordinate frame, shown in the following
figure




               Figure 18: The local coordinate frame of the satellite varies throughout the
               orbit relative to the ECEF coordinate frame.

The time-varying orientation matrix in the ECEF coordinate frame is define as,

                                         X x ˆ     Yx
                                                     ˆ    Zx 
                                                             ˆ
                                         X
                                      M  y        Yy    Zy
                                              ˆ      ˆ       ˆ

                                          X zˆ
                                                   Yzˆ   Z zˆ 
                                                               

      ˆ ˆ       ˆ
where x , y and z are fixed relative to the satellite according to the following figure.




                                                                                              34
               Figure 19: The local coordinate frame of the satellite. The satellite always
                              ˆ
               travels in the x direction.

                                                                                           ˆ
To increase the incident solar flux on the side panels, the satellite is rotated about the x
axis with the following rotation matrix,

                                         1   0             0   
                                         0 cos
                                    Rx                 sin  
                                     ˆ                          
                                         0 sin 
                                                        cos  

where  = 20. The resulting satellite orientation matrix, M is define as

                                            M  Rx M
                                                 ˆ




                                                                                               35
Appendix B

Characterizing Battery Charge Efficiency

Since there is no simple way to measure the absolute charge efficiency of the batteries, a
test was developed to estimate the relative charge efficiency. First it was determined that
the batteries took 90 minutes to fully charge at room temperature. Then, a program was
written in LabVIEW by the testing subsystem that automated the charge and discharge of
the batteries. The program charged the batteries for 90 minutes and paused. It allowed
the user to decide when to begin discharge of the batteries through a fixed load. During
discharge, the program took battery voltage readings at 1-second intervals.

The batteries were placed in a temperature-controlled chamber and charged at a fixed
temperature ranging from -15 C to 10 C. Six separate tests were run in 5 increments.
For each test, the batteries were charged for 90 minutes in the temperature chamber and
then taken out and allowed to equilibrate to room temperature before discharge. This
ensured that the change in battery performance from test to test was due to charge
efficiency and not discharge efficiency as well. The batteries were discharged until the
voltage dropped below 7.5V and the protection circuit shut the batteries off. The
recorded voltages were used to calculate the amount of power that was stored during the
90-minute charge, according the following equation,

                                               V2
                                          P
                                               R

where V is the voltage of the batteries and R is the resistance of the load. Since the
resistance is the same for every test, and we are only interested in the relative charge
efficiencies, when the ratios of power generation are calculated, the R always drops out.
So in effect, we are only concerned with the square of the voltage.

On top of the six data points taken over the operating temperature of the satellite, one
more test was run at room temperature to be used as a control value. According the
battery specifications, the optimal charge efficiency of the batteries is 80%. The test
charge at room temperature was assumed to be at optimal efficiency and all other
efficiencies were determined relative to that point.




                                                                                           36
Appendix C

Memory Usage




        Figure 20: Memory storage level throughout the six-month lifetime of the mission.
        The line at the top represents the memory capacity. Note that the amount of telemetry
        and GPS data stored never exceeds the storage capacity.




                                                                                                37
Appendix D

Matlab Simulation Code
%ICE Cube Simulation
% Ryan Song - rs125@cornell.edu
% Keith Sinclair – kjs39@cornell.edu

%Load Files into variables
load Sim_in.txt
minute = Sim_in(:,1);
days = Sim_in(:,2);
orbit = Sim_in(:,3);
sc_pos_vector = Sim_in(:,4:6);
sc_vel_vector = Sim_in(:,7:9);
sun_light = mod(Sim_in(:,10)+1,2);
sun_vector = Sim_in(:,11:13);
contact = Sim_in(:,14);
gmt_time = Sim_in(:,15);
lat = Sim_in(:,16);
long = Sim_in(:,17);
clear Sim_in;

load Duration.txt
duration = Duration;
load Heater.txt;
heater = Heater;

% find length of data file
D=size(sun_vector);
rows=D(1);
cols=D(2);
time=minute;

% change to unit vectors
disp('changing to unit vectors')
for index=1:rows,
           sv_l = norm(sun_vector(index,1:3));
           scpl = norm(sc_pos_vector(index,1:3));
           scvl = norm(sc_vel_vector(index,1:3));

           sun_vector(index,1:3)=sun_vector(index,1:3)./sv_l;
           sc_pos_vector(index,1:3)=sc_pos_vector(index,1:3)./scpl;
           sc_vel_vector(index,1:3)=sc_vel_vector(index,1:3)./scvl;

           end

% determine spacecraft frame axis
disp('finding s/c axis')
sc_xaxis = zeros(rows,cols);
sc_yaxis = zeros(rows,cols);
sc_zaxis = sc_pos_vector;

for index=1:rows,
           z    =   sc_pos_vector(index,1:3);
           v    =   sc_vel_vector(index,1:3);
           temp =   z*(v');
           x    =   -z .* temp + v;
           y    =   cross(z,x);

           sc_xaxis(index,1:3) = x;
           sc_yaxis(index,1:3) = y;
end

% determine surface normals
disp('finding surface normals')
top         = sc_zaxis;
bottom      = -sc_zaxis;
front       = sc_xaxis;



                                                                      38
rear           = -sc_xaxis;
left           = sc_yaxis;
right          = -sc_yaxis;

% determine flux on each face, zero if negative
disp('finding surface flux')

top_flux   =   zeros(rows,1);
bot_flux   =   zeros(rows,1);
frt_flux   =   zeros(rows,1);
bak_flux   =   zeros(rows,1);
rht_flux   =   zeros(rows,1);
lft_flux   =   zeros(rows,1);

for index=1:rows,
           top_flux(index)    = top(index,1:3)*sun_vector(index,1:3)';
           if top_flux(index) < 0
               top_flux(index)=0;
               end

               bot_flux(index)    = bottom(index,1:3)*sun_vector(index,1:3)';
               if bot_flux(index) < 0
                   bot_flux(index)=0;
                   end

               frt_flux(index)    = front(index,1:3)*sun_vector(index,1:3)';
               if frt_flux(index) < 0
                   frt_flux(index)=0;
                   end

               bak_flux(index)    = rear(index,1:3)*sun_vector(index,1:3)';
               if bak_flux(index) < 0
                   bak_flux(index)=0;
                   end

               rht_flux(index)    = right(index,1:3)*sun_vector(index,1:3)';
               if rht_flux(index) < 0
                   rht_flux(index)=0;
                   end

               lft_flux(index)    = left(index,1:3)*sun_vector(index,1:3)';
               if lft_flux(index) < 0
                   lft_flux(index)=0;
                   end
end

% apply shadow eclipse times
disp('applying eclipse times')
for index=1:rows,
           top_flux(index)     =   top_flux(index)*sun_light(index);
           bot_flux(index)     =   bot_flux(index)*sun_light(index);
           frt_flux(index)     =   frt_flux(index)*sun_light(index);
           bak_flux(index)     =   bak_flux(index)*sun_light(index);
           rht_flux(index)     =   rht_flux(index)*sun_light(index);
           lft_flux(index)     =   lft_flux(index)*sun_light(index);
end

% Determine orbital period
orbital_period = 0;
for k=1:300;
    if (orbit(k) == 2)
        orbital_period = orbital_period + 1;
    end
end

% solar flux in W/m2
solarflux = 1353;

% cell efficiency
cell_eff = .26;            % cell efficiency confirmed by Power subsystem to be 26%




                                                                                      39
% Area of each cell
length_cell = .04;
width_cell = .03;
area_cell = length_cell*width_cell;

% Cell layout
top_cell = 6;                %   6   cells   on   top side (side with GPS antenna)
front_cell = 6;              %   6   cells   on   front side (side opposite aero-fins)
back_cell = 2;               %   2   cells   on   back side (side with aero-fins)
left_cell = 6;               %   6   cells   on   left side
right_cell = 6;              %   6   cells   on   right side

% Areas
area_top = top_cell*area_cell;
area_front = front_cell*area_cell;
area_back = back_cell*area_cell;
area_left = left_cell*area_cell;
area_right = right_cell*area_cell;

% Power
top_power = top_flux*area_top*cell_eff*solarflux;
front_power = frt_flux*area_front*cell_eff*solarflux;
back_power = bak_flux*area_back*cell_eff*solarflux;
left_power = lft_flux*area_left*cell_eff*solarflux;
right_power = rht_flux*area_right*cell_eff*solarflux;

% Total power generated by solar cells
total_power = top_power + front_power + back_power + left_power + right_power;

% Total energy generated by solar cells per minute
cell_energy = total_power./60;

% Distributed energy is all the energy available for use during the mission.
% There is a voltage regulator between the solar cells and the battery in order
% to maintain the correct charge voltage at the battery. It is 75% efficient.
dist_energy_eff = 0.75;
dist_energy = dist_energy_eff.*cell_energy;

inst_energy_used = zeros(1,rows);

% Battery energy capacity (Watt-hours)
bat_cap = 8.4;
bat_level = zeros(1,rows+1);
bat_level(1) = bat_cap*0.9;     % initially battery 90% charged
discharge_eff = 0.9;            % efficiency of power taken from battery
charge_eff = 0.75;% 0.8;        % efficiency of power put into battery

% Voltage regulator efficiency
volt_reg_eff = 0.9;

%   The following is the energy used by the various subsystems when on (Watt-hours).
%   This information was provided by the Power subsystem. All values are divided
%   by 60 to represent the energy used in 1 minute. Some values are divided by a
%   voltage regulator efficiency. This depends on their required input voltage.
%   The batteries operate at around 12 volts. Components requiring 3.3 V or 5 V
%   must be stepped down through 90% efficient voltage regulators. Dividing by the
%   regulator efficiency increases the amount of energy consumed by each component.
%   Since we are interested in tracking how much power is taken out of the battery,
%   and not how much is actually used by the component, this is a valid assumption.

% CDH
cdh_energy = 0.35/60;

% Comm
comm_rx = 0.271950099/60; % energy used receiving per minute
comm_tx = 3.93165/60;      % energy used transmitting per minute
percent_rx = 0.064;        % fraction of communication window spent receiving is 6.4%
comm_actv_energy = (comm_rx*(percent_rx)+comm_tx*(1-percent_rx))/volt_reg_eff;
comm_idle_energy = (0.000020899/60)/volt_reg_eff;




                                                                                         40
% GPS
gps_energy = (1.625/60)/volt_reg_eff;         % energy used by GPS receiver
gps_mem_energy = (0.0016/60)/volt_reg_eff;    % energy used by the GPS memory

% ADCS
adcs_magnetomer_energy = 0.05*0.168/60;
adcs_torquer_energy = (0.1*1.5/60)/volt_reg_eff;

% Power
power_mcu_energy = (.3/60)/volt_reg_eff;

% Thermal
therm_sensor_energy = (0.01*0.00225/60)/volt_reg_eff;
therm_heater_energy = 1.5/60;     % Powered directly from batteries (no efficiency loss)


% Initializations

% Comm
contact_number = 1;               % for indexing duration array
comm_energy_used = zeros(1,rows);

% GPS
gps_datasets = 0;
gps_minutes_on = 0;
gps_energy_used = zeros(1,rows);
in_gps_region = 0;                 % assume GPS is initially not in equatorial region
dataflag = zeros(1,rows);

% Thermal
new_orbit = zeros(1,rows);
therm_on = zeros(1,rows);


% Since the heater on vector was defined independently of the FreeFlyer
% simulation, it is not synchronized to the rest of the input vectors.

%   The following determines if the orbital period of the heater on vector
%   is the same as the orbital period of the FreeFlyer simulation. If
%   they are different, the heater on vector is adjusted to match the
%   FreeFlyer simulation.

heater = heater';
if (length(heater) < orbital_period)
    zeropad = orbital_period - length(heater);
    heater = [heater(1:50) zeros(1,zeropad) heater(51:end)];
elseif (length(heater) > orbital_period)
    truncate = length(heater) - orbital_period;
    heater = [heater(1:50) heater(51+truncate:end)]
end

% The heater on vector is defined starting from when the satellite
% enters sunlight. The FreeFlyer simulation is defined starting
% from an arbitrary point in the orbit. The two must be synchronized.

% The following determines when the satellite first enters
% sunlight.

for i=1:rows-1
    if ((sun_light(i) == 0) & (sun_light(i+1) == 1))
        new_orbit(i+1) = 1;
    end
end

% The following determines at what point in the orbit the
% FreeFlyer simulation begins.

orbit_min = orbital_period-1;
n=1;
while (new_orbit(n) == 0)
    orbit_min = orbit_min - 1;



                                                                                        41
      n=n+1;
end

% The following synchronizes the heater on vector with the
% FreeFlyer simulation and creates a heater on vector for
% the entire duration of the simulation.

for i=1:rows
    therm_on(i) = heater(mod(i+orbit_min,orbital_period)+1);
end


% Data collected by satellite
data_storage_level = zeros(1,rows);          % Bits of data stored on satellite
storage_capacity = 8192000;                  % Maximum bits of data that can be stored
gps_per_min = 15600;                         % Bits of GPS data collected per minute
telem_per_min = 800;                         % Bits of telemetry collected per minute
download_efficiency = 0.75;                  % Download efficiency accounts for protocol
                                             % overhead and lost packets
download_per_min = floor(576000*download_efficiency);       % Bits of actual data
                                                            % downloaded per minute
telem_hours = 12;                            % Store telemetry into file every 12 hours

% Initial cycling control parameters
gps_cycle_number = 6;           % number of orbits per GPS cycle
comm_cycle_number = 6;          % number of orbits per comm cycle
min_side_panel_power = 0.75;
gps_cycle = 0;
comm_cycle = 0;
left_panel_power = 0;
right_panel_power = 0;
average_left_power = 1;
average_right_power = 1;
cycling_on = -1*ones(1,rows);
cycling_off = -1*ones(1,rows);

% The following is the main loop that tracks the charge level of the batteries.
disp('calculating power and data usage')
for m=1:rows

      % Track power generated by left and right panels of the satellite
      if (mod(m,orbital_period) ~= 0)
          left_panel_power = left_panel_power + left_power(m)/orbital_period;
          right_panel_power = right_panel_power + right_power(m)/orbital_period;
      elseif (mod(m,orbital_period) == 0)
          left_panel_power = left_panel_power + left_power(m)/orbital_period;
          right_panel_power = right_panel_power + right_power(m)/orbital_period;
          average_left_power = left_panel_power;   % Average power generated by left panel
          average_right_power = right_panel_power; % Average power generated by right panel
          left_panel_power = 0;
          right_panel_power = 0;
      end

      % Energy used continuously (CDH, GPS memory, Powerboard, ADCS, Thermistors)
      const_energy_used = cdh_energy + gps_mem_energy + power_mcu_energy + ...
          adcs_magnetomer_energy + adcs_torquer_energy + therm_sensor_energy;



      % Energy used by GPS subsystem
      if (m > 1)
          if (sun_light(m) == 0)
              if (sun_light(m-1) == 1)
                  dataflag(m+orbital_period) = 1;   % Predict time of sunset in next orbit
              end
          end
      end

      % Cycling control algorithm
      if (average_left_power < min_side_panel_power & ...
             average_right_power < min_side_panel_power)       % Cycling on



                                                                                         42
   cycling_on(m) = 0.01;

   % Energy used by comm subsystem
   if (contact(m) == 1)
       if (duration(contact_number) > 6 & data_storage_level(m) > 0)
           if (comm_cycle == comm_cycle_number)
               if (data_storage_level(m) < download_per_min)
                    comm_energy_used(m) = comm_actv_energy * ...
                          data_storage_level(m)/download_per_min;
               else
                    comm_energy_used(m) = comm_actv_energy;
               end
               data_downloaded = download_per_min;
           else
               comm_energy_used(m) = comm_idle_energy;
               data_downloaded = 0;
           end
       else
           comm_energy_used(m) = comm_idle_energy;
           data_downloaded = 0;
       end
   else
       if (m > 1)
           if (contact(m-1) == 1)
               contact_number = contact_number + 1; % Increment Comm contact number
               if (comm_cycle < comm_cycle_number)
                    comm_cycle = comm_cycle + 1;
               else
                    comm_cycle = 0;
               end
           end
       end
       comm_energy_used(m) = comm_idle_energy;
       data_downloaded = 0;
   end


   % Energy used by GPS algorithm
   if ((lat(m) < 20) & (lat(m) > -20))          %      Enters whenever satellite is within
                                                %      +-20 degrees of equator
       if (in_gps_region == 0)                  %      Enters if this is the first minute
                                                %      in a GPS region
           take_data = sum(dataflag(m:m+14)); %        Take data flag set if sunset occurs
                                                %      within +-20 degrees of equator
           if (take_data == 1)                  %      Enters if sunset occurs in
                                                %      equatorial region
               if (gps_cycle < gps_cycle_number)            % Enters if GPS cycle counter
                                                            % is less than cycle number
                        gps_cycle = gps_cycle + 1;   % Increment the GPS cycle counter
                 else
                        gps_cycle = 0;               % Once GPS cycle counter = cycle
                                                     % number, set counter back to zero
                        gps_datasets = gps_datasets + 1;    % Increments GPS dataset
                                                            % counter
                 end
           end
        end
        if ((gps_cycle == gps_cycle_number) & (take_data == 1))
            gps_energy_used(m) = gps_energy;
            gps_data = gps_per_min;
        else
            gps_energy_used(m) = 0;
            gps_data = 0;
        end
        in_gps_region = 1;
    else
        gps_energy_used(m) = 0;
        gps_data = 0;
        in_gps_region = 0;
    end
else                              % Cycling off



                                                                                          43
         cycling_off(m) = 0.01;

        % Energy used by comm subsystem
        if (contact(m) == 1)
            if (duration(contact_number) > 6 & data_storage_level(m) > 0)
                if (data_storage_level(m) < download_per_min)
                    comm_energy_used(m) = comm_actv_energy *
data_storage_level(m)/download_per_min;
                else
                    comm_energy_used(m) = comm_actv_energy;
                end
                data_downloaded = download_per_min;
            else
                comm_energy_used(m) = comm_idle_energy;
                data_downloaded = 0;
            end
        else
            if (m > 1)
                if (contact(m-1) == 1)
                    contact_number = contact_number + 1; % Increment Comm contact number
                end
            end
            comm_energy_used(m) = comm_idle_energy;
            data_downloaded = 0;
        end

         % GPS subsystem
         if ((lat(m) < 20) & (lat(m) > -20))          %   Enters whenever satellite is within
                                                      %   +-20 degrees of equator
             if (in_gps_region == 0)                  %   Enters if this is the first minute
                                                      %   in a GPS region
                 take_data = sum(dataflag(m:m+14)); %     Take data flag set if sunset occurs
                                                      %   within +-20 degrees of equator
                 if (take_data == 1)                  %   Enters if sunset occurs in
                                                      %   equatorial region
                      gps_datasets = gps_datasets + 1;    % Increments GPS dataset counter
                 end
             end
             if (take_data == 1)
                 gps_energy_used(m) = gps_energy;
                 gps_data = gps_per_min;
             else
                 gps_energy_used(m) = 0;
                 gps_data = 0;
             end
             in_gps_region = 1;
         else
             gps_energy_used(m) = 0;
             gps_data = 0;
             in_gps_region = 0;
         end
   end

   % Energy used by heaters
   if (therm_on(m) == 1)
       therm_energy_used = therm_heater_energy;
   else
       therm_energy_used = 0;
   end

   % When in eclipse, all power used comes from batteries and is subject to a loss on
   % battery discharge efficiency

   if (sun_light(m) == 0)

         % The power used by all the subsystems comes from the battery when the satellite
         % is in eclipse

         inst_energy_used(m) = const_energy_used + therm_energy_used + ...
             comm_energy_used(m) + gps_energy_used(m);




                                                                                           44
            % Using power from the battery is subject to the battery discharge efficiency
            bat_level(m+1) = bat_level(m) - inst_energy_used(m)/discharge_eff;

            % Battery cannot hold negative charge
            if (bat_level(m+1) < 0)
                bat_level(m+1) = 0;
            end

      else

            %   The power used when the satellite is in the sun may come entirely from the
            %   cells if they are producing enough
            %   If they are not, then the remainder of the power comes from the battery
            %   The power coming from the battery is subject to the discharge efficiency, the
            %   power coming from the cells is not

            inst_energy_used(m) = const_energy_used + therm_energy_used + ...
               comm_energy_used(m) + gps_energy_used(m);

            if (dist_energy(m) > inst_energy_used(m))      % If the cells are producing
                                                           % enough power
                % The battery is being charged
                bat_level(m+1) = bat_level(m) + (dist_energy(m) - ...
                   inst_energy_used(m))*charge_eff;
            else                               % If the cells are not producing enough power
                % The battery is being discharged
                bat_level(m+1) = bat_level(m) + (dist_energy(m) - ...
                   inst_energy_used(m))/discharge_eff;
            end

            if (bat_level(m+1) > bat_cap)           % Battery cannot exceed its charge capacity
                bat_level(m+1) = bat_cap;
            elseif (bat_level(m+1) < 0)             % Battery cannot hold negative charge
                bat_level(m+1) = 0;
            end
      end

      % Telemetry stored for transmission
      if (mod(m,telem_hours*60) == 0)
          telem = telem_per_min * telem_hours * 60;
      else
          telem = 0;
      end

      % Data storage level
      data_storage_level(m+1) = data_storage_level(m) + gps_data + telem - data_downloaded;
      if (data_storage_level(m+1) < 0)
          data_storage_level(m+1) = 0;
      end
end


figure
subplot(2,1,1)
plot(cell_energy,'.')
title('Cell Energy')
axis([0 rows 0 0.08])
hold on
plot(cycling_on,'.r')
plot(cycling_off,'.g')
hold off
subplot(2,1,2)
plot(bat_level)
title('Battery Level')
ylabel('Watt-Hours')
axis([0 rows 0 10])

figure
subplot(2,1,1)
plot(comm_energy_used,'m')
title('Comm Energy Used')



                                                                                                45
axis([0 rows 0 0.08])
subplot(2,1,2)
plot(gps_energy_used,'m')
title('GPS Energy Used')
axis([0 rows 0 0.08])

figure
subplot(5,1,1)
plot(top_power,'.')
title('Cell Energy by Panel')
ylabel('Top')
axis([0 rows 0 3])
subplot(5,1,2)
plot(front_power,'.')
ylabel('Front')
axis([0 rows 0 3])
subplot(5,1,3)
plot(back_power,'.')
ylabel('Back')
axis([0 rows 0 3])
subplot(5,1,4)
plot(left_power,'.')
ylabel('Left')
axis([0 rows 0 3])
subplot(5,1,5)
plot(right_power,'.')
ylabel('Right')
axis([0 rows 0 3])

storage_limit = storage_capacity * ones(1,rows);
figure
plot(data_storage_level)
title('Memory Storage Level')
axis([0 rows 0 10000000])
hold on
plot(storage_limit,'r')




                                                   46

				
DOCUMENT INFO