Chapter 3. Full Ground Station
What is your mission producing? Why, it’s producing Mission Data. This includes health and safety telemetry—which your customers couldn’t care less about. Primarily, they want the payload or instrument data. Processing this data and generating useful technical or scientific data is what you (or your customer wants).
Missions often split into a Mission Operations Center (MOC) that operates and maintains the health of the satellite and handles communications uplinks and downlinks, and a separate Science Operations Center (SOC) that receives the payload/instrument data from the MOC and distributes it to customers. Think of the MOC as the engineering side and the SOC as the science side. As an Internet analogy, think of the MOC as the server and the SOC as the web pages being served.
Whatever instruments or payload you are flying, you want your data like you want your TV—more of everything.
-
High resolution
-
High cadence
-
Multiple wavelengths/multi-spectral
Expecting it to be like a Discovery Channel movie, users expect raw, unedited high-resolution images at 32 fps using multiple cameras. What they get (they feel) is tiny VGA snapshots from a cheap digital phone.
Downlink Only
At this point, we’re talking about downlink only. The MOC has no control over the data directly; however, actions by the MOC can affect the:
-
Quality (fidelity) of the measurements
-
Completeness of the data
Data levels are defined as:
-
MOC has level 0.
-
SOC may take level 0 and produce either Quicklooks or level 1A.
There is an eternal conflict between transmitting all raw data to Earth, or having the satellite select only the best data to transmit down. Onboard processing of the data reduces the telemetry needs and ensures more data is received; sending raw data ensures that the data sent has more information and encourages unexpected data discovery.
At a government or corporate level, data handling often involves one or more DAACs (Data Active Archive Centers), or an entity like NSSDC (National Space Science Data Center). For your mission, your MOC, SOC, and DAC may all be just the laptop running your mission, but the roles still remain distinct.
Science data does not just include “the bits sent by the instruments,” but also:
-
The raw data from the spacecraft
-
Attitude and orbit information about when and how the data was taken
-
Processed data (Level 1, 2, etc.)
-
Data quality flags (from Ops)
-
Calibration level and version info
-
Other metadata (e.g., planning info)
-
Ownership info
Operations Choices
Your “Concept of Operations Concept” or ConOps is how you plan to operate your satellite, and must be defined before you start building anything. So let’s build a ground system (on paper first)! Here are the steps to design a system:
-
Identify mission needs
-
Determine ops tasks
-
Identify how to do it (and whether we already can do it)
-
Do key trades analysis
-
Develop scenarios
-
Make timelines
-
Assess resources needed
-
Map data flow
-
Identify team
-
Assess costs
-
Derive requirements
-
Make tech plan
-
Iterate
Notice “pick a set of choices randomly and just go with it” is not a valid option. But to do this, we need to look at the core assets involved in a ground system.
Start with the Mission Payload
We assert three categories for defining a mission type and objectives:
-
Trajectory aka orbit
-
Type of payload: Comm, Science, Navigation, Remote Sensing, R&D, Exploration, Tech Demo, etc.
-
Payload complexity
Now we assume that has been defined, so we can work with the tangible assets we are flying:
-
Pointing detector(s) and/or telescope (e.g., HST)
-
In-situ detectors (e.g., radiation monitor)
-
Built-in lab (e.g., bio)
-
Space-based factory (e.g., crystals)
-
Comm system/repeater (e.g., OSCAR)
-
Navigation system (e.g., GPS)
-
Weapon(s) (e.g., space laser, EMP)
-
Tech demo (e.g., ion drive, solar sail)
-
Astronaut(s) (or scientists or space tourists)
-
Deployables and probes (e.g., sails, landers, etc.)
We need a bus that supports the payload. The bus + the payload = the satellite. The fundamental components of a bus are:
-
Power: batteries, solar cells, perhaps an RTG
-
Computing: CPU and data storage
-
Communications: Transceiver (both send and receive) and antenna
-
Attitude and maneuver: Gyros, thrusters, magnetic torque, etc., also star trackers, etc.
Note that “Communications” is part of the bus, but that our entire command and control for operations has to include the entire bus. We will monitor the bus—physical temperature, status of power, status of any systems, status of instruments—as well as download data from the instruments and send up commands. So our operations concept has to look at the entire satellite.
We need to know what the orbit is, as that partially defines your comms by showing what Earth-based locations and what relay satellites potentially can see and communicate with your satellite. Once you tie the orbit to the rotating Earth, you can then begin to map out when and how often you can directly communication with your satellite:
Typical orbits include LEO (circular or eccentric), MEO (circular or eccentric), HEO (circular or eccentric), GEO, halo, helio, or planetary/trajectory. The orbit defines the potential comms.
Comm Quantities
UPLINK is ground to satellite, sending commands or data to a satellite. DOWNLINK is satellite to ground, receiving data from a satellite. The dueling communications quantities are:
-
Number of times you can contact it per day
-
Duration of contacts
-
Amount of data you can uplink per contact
-
Amount of data you can downlink per contact
VERSUS
-
How frequently it must be commanded
-
How much data (if any) per day it generates
-
How much data it can store onboard before requiring a transmit to ground
-
(If CommSat, uplink/downlink are also required)
“Comms” is not necessarily a single entity, or even unique. Different entities can handle different aspects of the data. One common NASA scenario is that all telemetry goes through a dedicated comm provider like DSN or TDRSS/White Sands. This comm provider routes data to the appropriate entities. The Mission Operations Center (MOC) prepares uplinks and receives all housekeeping (HK) telemetry to assess the health and safety (H&S) of the satellite. Meanwhile, the Science Operations Center (SOC) feeds the MOC with plans for upcoming operations, and also receives Quicklook (thumbnail) science data plus a subset of MOC’s HK—specifically, the instrument HK data for monitoring instrument H&S. The third entity, the Data Archive Center (DAC), receives all the stored science data.
These three components—MOC, SOC, and DAC—are the core of your ground system. For a small mission, all three entities may be one person in their basement. For a large-scale science satellite, each entity may be in a different country. For a communications provider, there may be multiple MOCs and, in addition, each subscribed user may be the equivalent of a SOC. One common amateur radio scenario is that each user directly connects to relay satellite. User A sends a message to the relay satellite. User B receives a message from the relay satellite. A different DirectTV scenario is that the comm network MOC sends commands and data up to satellite, while individual users can (passively) receive data from satellite.
In all cases, we are not just separating by whether an entity has uplink or downlink capability and whether they have access to command the satellite, but also whether they are receiving satellite HK data, payload data, or both.
Ground Network
What are the physical ground assets handling the communications?
-
Antenna(e)
-
Comm ops
-
Data distribution
-
Data archiving
-
End users
The questions you need to answer will help define what your comm capabilities are. Where are they located? Are they fixed or mobile? What is their capacity? When do they operate? Who owns them?
Ranging and Orbit Determination
In addition to items you can control—your orbit choice, the ground stations that will support it—there is an additional component that is often hard for the amateur mission to achieve on their own. The question is how to know where your satellite is. Finding the satellite’s position and time is known as ranging, and from this data you can do an orbit determination so as to generate a set of orbital elements that enable you—finally, at your station—to predict where your satellite will be in the near future. Three methods exist to figure this out:
-
You predict based on last known position and velocity (inertial).
-
Your satellite tells you (GPS or equivalent).
-
Someone on the ground tells you (ranging).
Inertial prediction is the least reliable, as deviations due to atmospheric drag, that the Earth is not a pure sphere, and that computers tend to round numbers all lead to the prediction getting worse and worse over time. Having the satellite tell you its position is very useful now that GPS technology is available for LEO satellites. Ranging by US Space Command (formerly called NORAD, and the NORAD facility is still referenced for ranging) is done automatically for every satellite, and if you can match your satellite to the ID which NORAD assigned, this provides a way to get the position on a regular basis.
Sometimes orbit determination is (often?) co-located with your commercial comm provider. Sometimes a third entity such as NORAD/US Space Command handles it. In that case, there will often be a delay before you get the latest information. Sometimes it is up to you, and you must do your own ranging. We’ll cover this in our chapter on orbits. It is possible but not recommended; wait for NORAD to let you know where your satellite is.
Ground System Design Products
The end result of all the above questions and your analysis and answers should feed into an overall map and layout of your ground assets, in a tactical sense. The components you will create include:
-
Geographic maps (where are your assets?)
-
Coverage maps (who sees what when?)
-
Timelines and schedules (when do we have to do what?)
-
Network maps (how are the ground assets connected?)
-
Org charts (what entities are involved, who bosses who?)
-
Resource budgets (spreadsheets to balance your comm capacity against your uplink/downlink data needs.)
-
Cost budgets (you’ll pay for this!)
Now let’s look at some of the big picture risks and how to make assessments.
Mission Phases
Your communications needs will change as your mission evolves. Breaking your timeline into phases will help you decide how to ramp up your mission, deliver on your core goals, and potentially extend your mission life or even repurpose your satellite for alternative uses later on.
The pre-launch phase is where you are building and testing your ground system. During this time, only your core team needs to be active, because there isn’t actually an orbiting asset to manage. Also, during this period, you may be altering your software and hardware choices as you converge on a good design. As you start to get close to launch, you can begin to deploy your specifications and final software to any partners. This is also the time that all licensing and (if money is changing hands) contracts are resolved. Plan in advance how you will get extra capability if you run into trouble after launch.
In-orbit checkout (IOC) is that period immediately after launch, and extending anywhere from days to weeks, during which your satellite first is released, then powers up, and then begins doing simple operations. This is the single most crucial period of the mission, during which you need as much communication capability as you can get your hands on. For IOC, you can draft volunteers to provide additional ground stations for the short term. The core mission of IOC is to ignore the payload, and just determine if the satellite bus—the power, comms, CPU, and any components that are required to operate to keep your satellite alive—is working properly. During IOC, you want to minimize risk, because any loss is a big cost loss. In this phase, Failure is not an option: you have no idea what might fail on your satellite, so you’ll want to have redundant coverage.
Next comes the performance verification (PV) phase, in which you now verify your payload. This can take days or weeks. During this time, you may need to tweak payload settings, fix command scripts, or do other ground operations to get the darn thing to work properly. Since IOC confirmed that you can listen to and command your bus, you likely will not require redundant ground capacity anymore. Instead, you can use whatever your core long-term ground plan is to leisurely tweak your payload until you’ve got it tuned and humming. You still want to minimize risk, so the goal here is to establish nominal operations, where nominal means the normal expected level. This is not the time to change things, just the time to get things working as planned.
Next comes the primary mission phase(s), where your satellite does useful things. The primary mission may be as simple as send a Sputnik ping or it may have distinct phases such as (1) go to Pluto then (2) measure Pluto. This period is the best part of operations, because you’ve verified that you have a working satellite (from IOC) that is returning valid data (from PV), so now you can carry out your mission. You still want to minimize risks and changes so your mission can go as close to how you planned it as possible. How long this phase lasts is up to you, and can be extended until the satellite’s final fiery end.
Optional extended mission phase(s) are when you add or change the mission goals due to your satellite performing longer and better than the primary mission required. This is extra play time, and now you can try all the risky ideas you thought up during the primary mission but were wise enough to not try until now. For example, if your primary mission is to collect three months of data and, three months later, your satellite is still alive, you can go into an extended mission where you can keep doing the same thing, or try some new things that might or might not work. The key value of extended missions is that you can assume increasing risk in hopes of higher reward. Your satellite may also have reduced capacity at this point. Instrument or platform capability may be reduced or degraded due to cost (comm, staffing), failures in the platform (especially gyros or power), instrument problems (especially on multi-instrument missions), cumulative degradation and reduced capacity of the platform or instruments, loss of consumables (fuel, cryogen), and change in location (orbit decays, flybys, loss of some ground stations). An extended mission is the art of adapting to the new situation in a way that lets the satellite still do useful work.
Extended missions can include repurposing, where you completely reinvent the satellite. The WISE infrared astronomical space telescope, for example, reached its end of mission when it ran out of its finite amount of coolant for the main instrument; a decade later, it was powered back up as NEOWISE, a near-Earth asteroid spotter, using the secondary capabilities remaining. The solar physics International Sun/Earth Explorer 3 (ISEE-3) mission was later repurposed—and renamed—as the International Cometary Explorer (ICE) comet rendezvous mission once operators realized it had enough fuel to be the first spacecraft to visit a passing comet. If nothing else, perhaps your satellite can be Repurposed as a target for someone’s space laser? Perhaps not, in which case you will eventually get to…
The end of lifetime for the satellite, at which point you have to decide how to deorbit it. Deorbiting can be as simple as relying on natural drag forces to force a re-entry, or can involve actively commanding a deorbit mechanism to quickly force the satellite to reenter. Upon reentry, the satellite will burn up in the atmosphere. Mission over! Time to start a new project.