Skip to Main Page Content

Concept of Operations

Operations Overview

Launch & Deployment

Following the launch from Wallops Island in Virginia, the Phoenix CubeSat will sit on the ISS for a few months before deployment in late January 2020. As several cubesats will be deployed close to Phoenix, there is a required 30 minute wait period in which the satellite is not allowed to transmit or perform operations of any kind. This allows CubeSats to spread out from one another after deployment to prevent any kind of interference. 

Once the satellite has deployed from the ISS, it will be tumbling in space. After the 30 minute wait period, Phoenix will initialize its attitude control and determination system (ACDS), which will use a set of reaction wheels and magnetorquers to slow the spacecraft down to the point where it can be stabilized.This process is known as detumbling. Phoenix will then be oriented with its camera pointed down toward the earth (Nadir) to minimize atmospheric drag. 

Initial Operations Phase

The main mission will not start immediately after deployment. Some time during the beginning of the mission will need to be spent verifying where the spacecraft is in orbit so that we can predict its trajectory in the future. Once Phoenix has been identified, there will be a brief “checkout” phase, in which mission operators will monitor the health of the spacecraft to ensure all hardware is healthy following following launch and deployment. Finally, the checkout phase will be used to test operational procedures, such as collecting test images of Phoenix, AZ to compare how the satellite performs in LEO with how it performed in a laboratory setting. Once the satellite has been officially declared healthy and all operational procedures have been validated on orbit, the primary mission can begin and Phoenix can start collecting images of other US cities.

Disposal

During the operations phase, the spacecraft’s orbit will slowly decay due to atmospheric drag. After two years in LEO, Phoenix will re-enter the Earth’s atmosphere and disintegrate. While Phoenix will be in space for a few years, its operational lifetime is baselined at six months, as this is a typical mission lifetime for CubeSats in LEO.

Satellite Operational Modes 

To support the primary and secondary mission objectives, Phoenix has four primary modes of operation:

Idle mode

Idle mode is the primary mode of the spacecraft, in which the satellite charges the battery and collects heartbeat information.  

Science Mode

Science mode consists of payload calibration and image capture of a target city. The camera shall be calibrated before all images are taken to aid in post-processing and ensure that any scientific investigation done during the course of the mission can be supported.  

Image Calibration 

Image calibrations will be done to the Atlantic Ocean before the start of the imaging pass, and to the Pacific ocean after the imaging pass has complete. The temperature along the coast is monitored and can be obtained for post-processing. Therefore, as both the temperature and emissivity of the water are known, the ocean is able to serve as a reliable source for on-orbit calibration throughout the course of the mission.  

Imaging Operations

To capture an image of a city, the spacecraft is commanded to track the city's lat/long coordinate and take an image when positioned directly above the target. A set of three reaction wheels are contained in the satellite’s attitude control and determination system (ADCS) allow the camera to remain pointed at the specified ground target while the rest of the satellite continues to move along its trajectory. Earth horizon sensors and an onboard magnetometer allow the satellite to monitor its orientation above the Earth to further help control the spacecraft’s motion during this task. This method of fine pointing and control greatly reduces image blur and allows the spacecraft to obtain a high resolution image of the Earth. 

Imaging must occur within a 25deg window from the target location to maintain relative accuracy of the measured ground temperatures, as reflections off of buildings could interfere with the temperatures obtained by the payload. Once an image is captured, it is then named based on the date and time at which it was taken and transferred to the satellite’s onboard computer for storage. The image will be downlinked by the mission operations team at the earliest convenience.

Image Downlink

Longer passes over the ground station are used for downlinking images. During this time, the satellite downlinks as much of an image as possible before leaving the line of sight of the ground station. A downlink of a 321kB image takes approximately 8 minutes, so image downlinks will need to be completed over the course of multiple passes. 

Safe Mode

Safe mode occurs when the hardware experiences an event or fault which requires operations to be restricted for a period of time until the spacecraft is declared healthy again. These events could occur due to 

  • Battery voltage drops below 7.0V

  • Hardware is getting dangerously close to its Allowable Flight Temperature (AFT)

  • Loss of communications with a component 

  • Off-nominal telemetry or power draw 

In the event of safe mode, the operators must assess what sequence of operations would keep the satellite safe and try to resolve the issue if possible. 

Mode Transitions 

The transitions between the modes discussed above are summarized in the image below:

Monitoring Spacecraft Health

To fully assess the state of both the hardware and software during operations, the satellite will maintain various data logs, which record both hardware telemetry and events as they occur. This ultimately allows mission operators can be alerted whether command sequences go as planned or if these fail due to an unforeseen issue. 

Telemetry Logs

Telemetry is collected from the OBC, AX-100, EPS, Battery, and GPS and written to a file in ascii. An ascii format was chosen to allow the operator to easily assess the file and to prevent a single bit flip rendering the file unusable upon downlink, which would have been a large risk for hex format. 

All data is separated by hardware delimited for readability, but additional referencing is required to interpret what each parameter in the telemetry file means. This format allowed us to save valuable space in memory while still making the raw file discernable during the testing and integration phase of the project. 

Heartbeat Transmission (occurs every 30 seconds)

The satellite will regularly output “heartbeats” or “housekeeping packets” to alert any listeners of its status. The heartbeats only contain the telemetry that is critical for assessing the instantaneous state of the spacecraft without having to downink a full telemetry log. To reduce the number of I2C transactions, heartbeats include some information from the most recent telemetry log, such as the power and temperature values from the EPS and battery, and the data from the AX-100. 

Status Logs (Collected Based on Events)

Status logs record events during operations that we would not otherwise get from telemetry. These indicate both good and bad events, and generally serve as a way to provide a more comprehensive status of the satellite while it is idle and while it executes a schedule. Status logs are written in ascii format and don’t require further parsing on the ground after the file has been assembled. A few examples of status logs are listed below:

  • Scheduled command executes on time or is not executed

  • Images are successfully or unsuccessfully written to flash 

  • Errors occurred getting the GPS time

Status Packets:

Some messages are transmitted from the satellite to the ground to immediately indicate whether an operation was successful or unsuccessful. This was implemented specifically for the cases when the spacecraft performs operations over Phoenix, AZ. If the satellite is capturing an image of Phoenix, operators should be able to listen to the spacecraft and know immediately whether the operations sequence was executed successfully or if it may have failed in some way. Examples of status packets include messages such as “Image capture successful” or “Command schedule saved successfully.” These packets are also recorded as status logs in the case where the satellite transmits these messages while not over the ASU ground station.