VIEWS: 8 PAGES: 46 POSTED ON: 6/24/2011
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