This document describes the design of an extensible telemetry and command architecture for small satellites. Key aspects include: 1) A centralized server stores telemetry data, software configurations, and acts as a backup. Distributed hardware gateways at each ground station receive data, convert beacons, and store all data on the centralized server. 2) Telemetry is parsed according to a master definition that allows new parameters to be added easily. Beacons and files are converted to engineering units and stored in a mySQL database for post-processing. 3) A file transfer protocol is used to exchange data and commands between the satellite and ground stations during short orbital passes, with an emphasis on reliability, efficiency, and security

1. Design of an Extensible Telemetry and Command
Architecture for Small Satellites
Dawson Beatty∗
, Brenden Hogan†
, Cameron Maywood‡
Faculty Advisor: Brian Sanders
Colorado Space Grant Consortium, Boulder, Colorado, 80310
April 7, 2016
Small satellites missions often vary in duration, data generation, and communications
architecture in addition to a host of other parameters. However, all small satellite missions
need to capture telemetry, display this telemetry, and command the satellite. Loss or delay
of this telemetry to ground operators can mean potential loss of vehicle in the worst case
scenario. In addition the scientific or calibration data collected represents a significant in-
vestment by stake holders. Design of telemetry and command architectures must therefore
have the same mission assuredness as the space asset. To this end, a robust data storage
system that aims for eliminating a loss of data event is presented. Utilizing a centralized
server and distributed gateway system, this architecture aims to be extensible to any num-
ber of ground stations with an internet connection. The software contains a centralized
telemetry definition to easily process incoming telemetry, store it, and display it while
also being able to add parameters without additional development. This definition also
allows new missions to quickly adapt the architecture to their needs. Secure encrypted
commanding for low latency, high loss connections is also demonstrated in a simulated
environment. All software used in the architecture requires no licensing agreements for
educational endeavors and is available without corporate interaction.
I. Introduction
The Colorado Space Grant Consortium has designed, built, and operated multiple small satellites. Each
of these satellites produced its own unique telemetry that required conversion, storage, and software to
display it in a human readable format. Although the telemetry is unique, many of the operations performed
on it are common to all systems. This aspect means a system can be created that can be extended to
other small satellite missions. In addition, more and more ground stations are becoming available to student
teams. Coordinating all of these stations requires an extensible architecture that can easily be deployed to
new stations. This philosophy is applied to the design of a new system for the PolarCube satellite that will
be used on many future missions.
Currently the PolarCube satellite2
is preparing for launch and a system is being put in place to handle
the telemetry. This system, called the PolarCube Ground Segment(PCGS), comprises the software and
hardware for all data handling after conversion by the radio frequency hardware. The system is extensible
to a network of ground systems and easily maintained by using a unified software repository and distributed
hardware gateways at each ground station. Ease of maintainability of the system in a extensible network is
critical due to the rapidly shifting nature and skill levels of student teams. It is important to note that all
transmitted data from the space asset is valuable for mission success and therefore the PCGS has stringent
requirements. These include among others being usable at all times, and ensuring that the probability of a
loss of data event be minimized.
∗dawson.beatty@colorado.edu
†brenden.hogan@colorado.edu
‡cameron.maywood@colorado.edu
CU Boulder 1 of 7
Colorado Space Grant Consortium
Spring 2016

2. II. Architecture
The PolarCube satellite has two different radio links as well as two different transfer formats. The two
transfer formats are either beacon packets or file transfers. Beacon packets are sent from the satellite at a
specified interval with no ground interaction. These packets contain a fixed set of data that details the status
of the satellite at time of transmission. File transfers are designed to up-link configurations/commands or
down-link targeted segments of data. The satellite possesses a omni-directional UHF/VHF link used to
transmit beacons and as a backup file transfer route. The satellite also possesses a directional S-Band
link that is used only for file transfers. Only one link is used at any one time and transmits to its own
independently located ground station.
The PCGS utilizes a centralized server with distributed hardware gateways at each links ground station.
In the current architecture this is a UHF/VHF station co-located with the University of Colorado-Boulder
COSGC and a off-site S-Band Station. The central server acts as a data and code repository as well as a post
processing center. Each hardware gateway is responsible for executing transfers as well as real time decoding
of the satellite beacon. All systems are utilizing a lightweight Unix based architecture, the Xubuntu Linux
distribution.
A. Central Server
The central server is located at the University of Colorado-Boulder COSGC location and hosts the Samba
share that links the gateways to it. In this Samba share all up-linked/down-linked data is stored, as well
as all software configurations. This means that updates to all gateways’ code can be executed from one
location. It also means that the entire system has the same information available to it, and redundant copies
of data. Gateways and developers are capable of writing to this share while data users have only read access.
To ensure robustness, the system periodically backs up all files to a separate storage drive that has no delete
capability. This architecture ensures that although a loss of asset event could not easily be recovered from,
a loss of data event is highly unlikely.
In many modern architectures three instances of each asset are available to recover from a loss of asset
event capable of real time asset switching. This real time asset switching significantly increases complexity
and fully redundant assets can be expensive and underutilized. As a solution to this, the team has stored
the configuration of each asset and has one additional backup asset that can be used to replace any section
of the architecture. This allows the system to quickly and easily recover from a single complete failure.
Large volumes of data can be generated and accumulate over the mission life. As an example, the
DANDE small satellite mission accumulated roughly half a million unique telemetry points over its mission
life.1
This data needs to be regularly accessed for post processing. Using a mySQL database was chosen
based on its proven speed, reliability, and ease of use. As an example the DANDE database took up to ten
minutes to process using text file based tools vs less then 20 seconds using database tools like mySQL. As
communications systems for small satellites increase in capability, telemetry can rapidly press the limits of
text based data storage. If functional, PolarCube’s S-Band link has the capability to produce more telemetry
in a single pass than the entire DANDE mission.
Figure 1. DANDE Post Processed Temper-
ature Data
Post processing of the data is required to draw meaningful
conclusions about the health of the satellite. Post processing
includes conversion of data from engineering units and plot-
ting of trends on different time scales. All data that enters the
mySQL database has been converted to real units. This can
occur either at the gateway nodes or at the central server. Cur-
rently, beacon processing occurs at the gateway and is inputted
directly into the mySQL database. Files downlinked from the
satellite are processed on the central server after the pass has
concluded. Programs that plot trends in the data pull from the
mySQL database. Plotting parameters are determined based
on configuration and the master telemetry definition(expanded
upon in Telemetry Parsing).
An example is given in figure 1 of what post processed tem-
perature data from the DANDE satellite looked like. By look-
ing at the telemetry in this format, trends emerge about the
CU Boulder 2 of 7
Colorado Space Grant Consortium
Spring 2016

3. long term temperature behavior. This behavior could not be
observed by looking at only limited subsets of data and reveals
far more about the state of the system. Post processing can extend far beyond tracking data trends as well.
Satellite telemetry can be fed back into models to help refine past behavior or predict future behavior.
Real time post processing is also present on the system and can be used as required. The PCGS needs
this capability to realize the benefits of the GPS data produced by the satellite during a pass. This GPS
data increases the knowledge of the satellite’s position and therefore the pointing of the directional antennas.
When new GPS data is received from the satellite it is provided to the processing program and new ephemeris
is provided to the RF system. The use of real time pass dependent post processing increases complexity and
introduces areas for potential failure. Real time post processing that affects operations in real time should
therefore be avoided if possible.
B. Hardware Gateways
The hardware gateway is located in the chain after the data has left the RF system as digital values, but
before it has been converted to human readable data. The gateway primarily handles file transfers and
beacon conversion. As a secondary function, the gateway is also capable of displaying a real time GUI of the
most recent information on the health of the satellite. The most important feature of the gateway is that it
logs all data that is sent to the satellite and all data that is received. If an error is made at some point in the
processing or generation of data, the original untainted data stream exists. If behavior that is not expected
is observed, the commanding can be examined for fault in the form that was sent to the satellite.
File transfer occurs using a UDP-Based File Transfer Protocol (UFTP) where the gateway acts as both
a sender and listener. This file transfer protocol is expanded upon later, but how the results are used will
be discussed here. Commands and configurations are stored in the Samba share, and when triggered, the
gateway will broadcast them to the satellite. The ground will also broadcast a down-link file that instructs
the satellite what data to deliver. The satellite also has a broadcasting capability, and when this down-link
file is received, it will broadcast the requested data. All data is passed as binary files, saved in the Samba
share, and given to the central server. The central server will then process the data as mentioned above,
and described in detail in later sections.
Beacon conversion occurs when a data stream with a unique beacon header is received. The system
automatically processes this data as a beacon instead of a UFTP file transfer request. It is parsed by the
gateway immediately and stored to the database. Beacon data is then presented to the user of the gateway
using a GUI or user interface as to give some idea of satellite health. This GUI can examine limits in the
master telemetry definition and draw attention to values outside of limits. This software functionality is
enabled using a Python based architecture supplemented by native Bash. The GUI makes use of PyQt to
present the data in a readable format. In addition to presentation of the data the GUI also enables the user
to enable a file transfer using any gateway.
III. Telemetry Parsing
From the perspective of a ground station team, all small satellites require very similar software to parse
read in data. The only differences from mission to mission arise in the specific health and status updates
provided by each satellite, and the format in which they arrive. The PCGS team seeks to develop an
extensible architecture, allowing simple adjustments of variables and mission parameters. This entails parsing
the regular status update beacons, as well as parsing larger files coming in from the satellite.
Data received on the ground typically comes in as straight hexadecimal numbers, so specific instructions
are needed to describe which sections of the file are to be converted to text, and which parts are numbers
representing the status of the satellite. The team defined each of three different types of files, all handled in
different ways. The status update beacons will be the most common, coming every 15 seconds. The team will
also receive other data when requested from the ground. Using this strategy of master telemetry definitions
has many benefits, particularly the easily extensible nature of the program. For each new parameter added
to the mission, a single line of a spreadsheet needs to be updated, then the software will take care of the
rest.
CU Boulder 3 of 7
Colorado Space Grant Consortium
Spring 2016

4. Figure 2. Telemetry Software Diagram
The software will constantly monitor a prede-
fined data stream or folder (Figure 2), checking for
any new files down-linked from the satellite. When
received, the first few bytes constituting the file
header will be checked to see which telemetry defini-
tion should be applied to the file. Beacon files and
other types of file will have a preexisting teleme-
try definition, which includes name, data type, unit
conversion, and a range of appropriate values if nec-
essary. The satellite will also down-link data from
its science mission, which will not be processed by
the PCGS team. All science data is uploaded to the
mySQL database for analysis by the science team.
A somewhat non-conventional approach becomes
necessary for satellite data, since minimization over
transmission is a priority. Each hexadecimal num-
ber represents a full byte of information, which is
equivalent to 8 bits. This amount of information is
enough to express one character, or decimal values
up to 256. To minimize the amount of data to be sent down on a potentially lossy connection, numbers
will frequently need to be bunched together, and therefore given in the form of partial bytes. While this
technique is efficient for data packing, it presents a significant problem on the ground since traditional hex-
adecimal parsing software won’t output a meaningful result. To account for this, the software converts all
the incoming data into a string of binary data. From this point it is trivial to consult the master telemetry
definition and retrieve the number of bits needed for each data point.
Although this introduces slightly more complicated code on the ground, the benefits of minimizing the
amount of data sent over a lossy connection far outweigh the inconvenience. The robustness of binary also
allows for easier parsing of unsigned and signed integers.
The master telemetry definition also includes engineering unit conversions. These conversions exist to
allow the satellite to send data in the simplest format. For example, a temperature reading on the satellite
might be 4.156◦
C. Instead of sending down a larger floating point number to account for the decimal,
PolarCube can instead send down ‘4156’ then have it properly converted on the ground.
After parsing out the data and updating the user interface with beacon information, the mySQL database
will be updated with all retrieved information.
The software will include a visual component for the user, allowing to see problems at a glance. Having
a user interface to control the ground station instead of relying on straight code and files has the added
benefit of easily training future members of the control team. The user interface will be updated every time
a beacon is successfully received and processed. The software can compare the received value with a range
of acceptable values, and raise a warning if the number is outside of what is expected.
IV. File Transfer
In order for information to be exchanged between Ground Station and PolarCube, a specific method of
data transfer must be utilized. Although it is possible to simply send a continuous bit-stream from a server
to a client via methods such as circuit switching, the most conventional way that modern telecommunications
is implemented is through network packets. In essence, a network packet is a small element of an entire file
that contains information about the file as well as part of the file itself. This method of file transfer has
proven to be extremely effective at bandwidth optimization over other methods such as the one mentioned
previously and, consequently, will be utilized in PolarCube communication.
To carry out this packet transfer, a procedure known as a file transfer protocol (FTP) must be utilized.
This is, essentially, a series of processes to get a number of packets from one destination to another while also
taking into account packet error, traffic, and server-to-client connection. In the case of PolarCube, the FTP
will initiate communication between PolarCube and Ground Station to retrieve scientific data and beacon
data from PolarCube, as well as send commands from Ground Station to PolarCube that are generated by
the Ground Station team. However, there are three parameters of significant importance that must be met
CU Boulder 4 of 7
Colorado Space Grant Consortium
Spring 2016

5. during this communication: reliability, efficiency, and security.
In regards to reliability, the FTP must be robust in its performance. If files are lost in transit, there
must be immediate measures taken to ensure that they are not lost permanently. Many of these files may
be critical in nature (such as satellite commands) and could result in unfavorable or disastrous consequences
under emergency situations. In regards to efficiency, PolarCube will only be overhead of the Ground Station
antennas for 10 minutes per orbital pass. This makes file transfer speed an imperative factor for mission
success as all the required data must be transferred within this time limit. Lastly, in regards to security,
data will travel between PolarCube and Ground Station via radio waves sent from UHF/VHF and S-band
antennas. As radio waves travel between destinations, they are susceptible to interception from other un-
intended clients. In order to prevent this data from being acquired from others without authorization, the
data must be encrypted so that only PolarCube and Ground Station can decipher the radio waves into actual
meaningful data.
A. UFTP
There are two primary types of Internet Protocol (IP) connections: Transmission Control Protocol (TCP)
and User Datagram Protocol (UDP). Both of these protocols contain variations in both efficiency and
reliability and, depending on the specific application, have benefits over one another. A brief summary of
some essential differences is shown below:
Table 1. TCP vs. UDP specifications.
TCP UDP
Packet Header 20 bit 8 bit
Connection Required handshake None
Error Checking
Mandatory checksum
(IPV4/IPV6)
Mandatory checksum
(IPV6)
Transfer Attempts
Retransmitted until
completion acknowledged
One attempt
Packet Ordering Yes (packets numbered) Not necessarily
Traffic
Delays transmission
if congested
Transmits regardless
of congestion
While both of these protocols effectively encompass a distinct file transfer behavior (i.e. comprehensive/slow
vs. limited/fast), neither of them individually incorporate all of the desired file transfer conditions for
PolarCube.
In order to accommodate the desirable qualities from both of these protocols, an additional protocol
known as UDP-Based File Transfer Protocol (UFTP) will be adopted for communication with PolarCube.
UFTP is a multicast file transfer program that allows for the efficient transfer of files to multiple receivers
simultaneously. Although the name implies that UFTP primarily reflects the characteristics of UDP, much
of the packet acknowledgment and order operations of TCP are also implemented in its protocol. Addi-
tionally, UFTP offers powerful encryption capabilities which is an especially significant concern for satellite
communication. Within UFTP, there exists three distinct phases: Announce/Register, File Transfer/NAK,
and Completion/Confirmation.
1. Announce/Register: The server transmits an announcement over a public multicast address which the
clients are expected to be listening on. The respective clients subsequently send a registration message
to the server in response to the announcement. In the case of PolarCube, a closed-group option will be
implemented allowing membership only by the specified client (PolarCube or Ground Station). Upon
receiving the registration message, the server sends an encryption key back to the client at which point
the client then acknowledges the key to the server. The type of encryption that will be utilized for
transmission between PolarCube and Ground Station is known as Advanced Encryption Standard 256
(AES-256) which generates a 256 bit key that is virtually unsolvable through brute-force techniques.
2. File Transfer/NAK: The server sends information about the file to the client; this information contains
the name, size, and how distinct packets the file will be broken down into. The server then begins to
CU Boulder 5 of 7
Colorado Space Grant Consortium
Spring 2016

6. send the file to the client one packet at a time at a user specified transmission rate. Like UDP, UFTP
does not guarantee ordered packets. However, UFTP assigns numbers to each packet so that the client
may reassemble them in the correct order upon file transfer completion. Once the entire file has been
sent, the server sends a message to the client indicating the file transfer has ended.
After receiving the completion message, the client then checks for any missing or corrupted packets.
If any are found, a message containing a list of negative acknowledgments (NAK’s) for these packets
is sent back to the server and the server resends the specified packets only. This process repeats until
the client has received the entire file at which point it sends a completion message to the server. This
entire phase is repeated for any subsequent file to also be transferred to the same client.
3. Completion/Confirmation: The server sends a message to the client indicating that the file transfer
session is ending. The client then sends a message back to the server acknowledging this, and the
server sends a final confirmation of this acknowledgment.
As mentioned previously, UFTP exhibits many similarities to TCP in regards to packet acknowledgment and
order handling. However, the process in which UFTP implements them what differentiates its performance
over TCP. During a file transfer, TCP sends each individual packet of the file and waits for an acknowledg-
ment from the client before sending the next packet. For an ideal connection, this does not cause a significant
decrease in performance as most packets are received the first time. However, satellite connections can often
be extremely inconsistent (e.g. as high as 20% packet loss for DANDE1
) and consequently, acknowledging
every packet when multiple packets are failing to reach the client exponentially increases the file transfer
speed. UFTP, however, sends every packet of the file to the client and waits for a single acknowledgment
from the client addressing every missing packet instead of just an individual one. In this case of inconsistent
satellite links, this dramatically decreases the amount of acknowledgments that are required between Polar-
Cube and Ground station. As mentioned previously, once in orbit, PolarCube will be overhead of Ground
Station’s antennas for only 10 minutes per orbital pass, making file transfer speed an imperative factor in
mission success. Consequently, UFTP’s superiority in speed solidifies the choice of UFTP over TCP and
UDP.
B. Network Inconsistencies
Given that connection inconsistencies are expected between PolarCube and Ground Station, it becomes
apparent that simulating these possible losses before launch would be a valuable tool in the analysis of the
telemetry and command system; one such tool is known as a network emulator. A network emulator creates
a virtual network that network traffic (i.e. UFTP) must go through before reaching their destination. This
virtual network can then be modified to exhibit many less-than-ideal conditions such as latency, packet loss,
packet corruption, and packet reordering.
The network emulator that will be implemented with PolarCube is a Linux configuration called Netem.
It is already enabled in the Linux kernel and controlled by the tc (traffic control) command in the iproute2
package. Shown below is a simple example of a netem functionality:
tc qdisc change dev eth0 root netem delay 100ms loss 5.0%
This command would cause a 100ms delay and 5.0% packet loss for all packets being sent through the eth0
port, and the configuration would remain active on this port until another command to remove it is run.
By using packet delay and loss information from previous missions, models, and estimates a reasonable
representation of what could be expected for PolarCube can be created. This would allow for further testing
of UFTP’s performance under various conditions and enable the rest of the Ground Station team to develop
a more effective and comprehensive data acquisition architecture.
V. Conclusion
The architecture presented paves the way for the development of the PolarCube Ground Segment. A
centralized server and hardware gateways create a system that can be extended to multiple ground stations.
This is accomplished by utilizing a Samba based sharing system which ensures that software is up to date
and data shared across all assets. Data storage methods that are resistant to multiple points of failure create
CU Boulder 6 of 7
Colorado Space Grant Consortium
Spring 2016

7. a system that minimizes loss of data events. An extensible master telemetry definition is shown that allows
for parsing and post processing of all data. Furthermore, this definition can be updated if changes occur
without a need to change existing software. Finally, UDP based transfer ensures that the system can quickly
communicate over lossy connections. A method for analyzing and testing this protocol is presented using a
network emulator. Ultimately, all of these aspects make the PCGS a extensible and robust infrastructure
for small satellite telemetry and command handling.
Acknowledgments
The authors would like to acknowledge Brian Sanders for managing the team and facilitating resources.
In addition the team thanks Bill Irelan, Mike Trowbridge, and Vignesh Muralidharan for their guidance and
laying the foundation this architecture was built on.
References
1Hogan, Brenden J., Franklin A. Hinckley, and Tanya Y. Hardon. ”DANDE Operations and Implications.” Digital Com-
mons. Utah State, 2014. Web.
2Alvarenga, Glenda M. PolarCube: A Student Led CubeSat Mission. 11 PolarCube A Student Led CubeSat Mission.pdf.
COSGC. Web.
CU Boulder 7 of 7
Colorado Space Grant Consortium
Spring 2016