Second International Conference on Electrical Engineering
25-26 March 2008
University of Engineering and Technology, Lahore (Pakistan)
978-1-4244-2293-7/08/$25.00 ©2008 IEEE.
Systems Design of an Economical and General-Purpose
On-Board Computer for Low-Earth-Orbit Micro-Satellites
Muhammad Naeem Ayyaz
University of Engineering and
Technology, Lahore, Pakistan
M. Riaz Suddle
SUPARCO, Lahore, Pakistan
Shakeel Zahid
SUPARCO, Lahore, Pakistan
Abstract
An On-Board Computer (OBC) is the brain of any
satellite. This sophisticated piece of equipment monitors and
controls each and every function of the satellite. It is generally
a very expensive device, with cost amounting to hundreds of
thousands of dollars. The problem we have addressed in this
research is to conceive and design an economical, general-
purpose and adaptable OBC, for use in general-purpose low-
earth-orbit (LEO) micro-satellites. The hardware and
software design of this OBC is based upon open and flexible
design architecture. The idea is that the design can be used in
or adapted for a variety of small LEO micro-satellites with
minimal modifications. Keeping these goals in view, a
complete architecture of the OBC has been developed. The
design is based on the Intel 80386EX microprocessor
technology. In addition, requirements for the on-board and
ground station software have been identified and concrete
guidelines for design and implementation of the related
software have been provided.
1. Introduction
An on-board computer is especially designed to monitor
and control the real time operation of a satellite in real-time. It
takes control of the satellite immediately after its launch, and
remains in command until the end of the operating life of the
satellite. The primary role of the OBC is autonomous control
of all subsystems of the satellite. The OBC employs complex
hardware and software to communicate with the on-board
subsystems and the ground station. When the satellite is not in
the view of the ground station, all critical operational decisions
and actions are taken by the OBC. It collects information from
different subsystems of the satellite, analyses the information,
and takes necessary and appropriate decisions as and when
required.
The OBC is a special-purpose computer, and is different
in many respects from the conventional PCs and workstations.
An OBC may have a number of interfaces, both serial and
parallel, for communication with the other subsystems of the
satellite. The serial interface may be synchronous or
asynchronous. The software running on the OBC is real-time
software and typically carries out monitoring/controlling
functions. Some satellites also contain an on-board data
handling system (OBDH) for handling large volumes of high-
speed data; this system however does not have the controlling
authority. In small satellites, the OBC may also perform
various other functions, such as storing and forwarding
messages, gathering telemetry and executing
telecommands etc., which in larger satellites are
performed mainly by dedicated subsystems.
The OBC contains circuitry to convert information
received from different subsystems in the form of currents
and voltages into number formats understandable for the
ground station. This data is packetized and transmitted to
the ground station. In this way the OBC is used to send
telemetry information–the health monitor of the satellite–
down to the ground station. The OBC similarly receives
control commands, called telecommands, from the ground
station. It decodes these commands and on-board executes
them to perform the desired functions. Figure 1 depicts a
simplified high-level block diagram of an OBC.
Figure 1. A simplified high-level block diagram of an OBC
The OBC can direct the Power Conditioning System
(PCS) (not shown in the Fig) to turn on/off any subsystem
(except the power system and itself) to save battery power.
For example, at any moment during its flight the satellite
may experience high temperatures in the sunlit region. It
can similarly be subjected to increased radiation
bombardments due to an increase in the solar activity.
These factors may destroy on-board electronic
Main Processor
Program
Memory
Data
Memory
Serial
Interface
e
Parallel
Interface
Any Specialized
Interface, such as
MIL-STD-1553
OBC Bus
2
components or at least cause some malfunctioning. Given
appropriate electronics on-board, the OBC can continuously
monitor the radiation bombardment and its effects on the
health of the satellite. A subsystem for that reason may be
temporarily turned off to save the subsystem from high
temperatures and radiation bombardment.
The OBC also monitors and controls attitude of the
satellite with the help of the Attitude Control Subsystem
(ACS). The attitude means the current position of the satellite,
its side presently facing the sun and the spin of the satellite.
This information is required by the OBC because it needs to
turn its battery power on when the satellite is in eclipse
(behind the earth, away from the sunlight) and turn it off when
the satellite starts drawing the power directly from the solar
panels.
Different architectural paradigms could be employed for
designing OBCs meant for different kinds of satellite
missions. They may range from centralized architectures to the
fully distributed ones. Different design architectures of the
OBC would thus bear different functionalities for the satellite.
We have explored a general-purpose and flexible
hardware/software architecture which results in an OBC that
can be used in, or adapted for, almost any LEO micro-satellite.
The design of this OBC is based upon the idea of open-bus
architecture and it has been implemented around an Intel
80386EX microprocessor. This microprocessor has a proven
track record of use in general space applications. For example,
it has been used by Surrey Satellite Technology Limited in its
UoSAT series of satellites [1]. Similarly, it has been used in
the OBC of the Malaysian satellite TiungSAT-1 [2] and South
African SUNSAT [10]. An Intel 80386EX can handle all the
requirements of an on-board computer for LEO micro-
satellites. Due to the simplicity of its design, the OBC can be
very economically built, both in terms of hardware and
software. The resulting designs are not only completely
functional but also very robust. The later microprocessor
families–such as the Pentiums–have not been successfully
used in space applications, because their space-qualified
versions are not freely available in the market. Besides, the
designers usually do not take risk with the newer
microprocessors.
2. Major functions of the OBC
An OBC needs on-board data to help control the satellite. This
data is gathered in real-time from different subsystems of the
satellite. On analyzing the data, the OBC makes controlling
decisions with the help of on-board system software. Some
core functions implemented by an OBC for LEO micro-
satellites are described as under.
2.1. Transmitting telemetry data
Telemetry data means the information pertaining to the state
of each specific subsystem of the satellite. This information is
received from the satellite at the ground station with the help
of the OBC and decoded to determine whether a given
subsystem is currently ON or OFF and whether it is properly
functioning or not. The telemetry data includes information
related to voltage and current supplied to each subsystem and
the temperatures at different points of the satellite, etc.
At present, there are different formats in use for the
telemetry packets. Some are specific to the particular satellites
and they are decided by the designers working on the
project. We choose the packet formats specified by the
Consultative Committee for Space Data Systems
(CCSDS) [3,11] that have proven to be robust and
immune to errors. This format has been adapted by the
whole European space industry also. A telemetry packet
contains the current date, the current time in UTC
(Universal Time Coordinates) format, and the numeric
values corresponding to the current, voltage and the
temperature information associated with each channel.
The channel means a particular information stream
related to any subsystem. If there are n pieces of different
telemetry information for the whole satellite, then there
will be n channels required in the telemetry packet to
carry the full telemetry data to the ground station. At the
ground station it is known beforehand that which channel
corresponds to telemetry information from which
particular subsystem. For instance, channel 1 may
correspond to current being drawn by the receiver,
channel 2 may represent the current drawn by the
transmitter, and so on. At ground station, a calibration
equation translates each decimal number, delivered as
part of the telemetry packet, into a form that depicts
whether this information pertains to voltage, current or
temperature. The packet may also contain a checksum so
that the ground station could determine whether the
packet is received error-free or not.
1) Voltage Monitoring: The voltage is monitored at
the power-input pins of a subsystem. This voltage is
converted into a number, usually a decimal value, by an
A/D converter (ADC). The value is recorded by the OBC
and transmitted to the ground station. Another task is to
just sense (rather than measure) voltages at the power
input pins of the subsystems and thus determine the
ON/OFF status of a subsystem. OBC senses these
voltages using its parallel ports. This test result is
produced as one-bit information; if the bit is 1 (0) the
subsystem is ON (OFF). This information is called digital
status of the subsystem.
2) Current Monitoring: The information regarding
the current drawn by a particular subsystem is picked
from the PCS, whose job is to monitor current drawn by
each subsystem of the satellite. The PCS converts this
information into a corresponding voltage level, which is
then transformed by the A/D converter into a number
value. The OBC receives and packs this number into a
telemetry packet for onward transmission to the ground
station.
3) Temperature Monitoring: Temperature sensors
located at different corners of the satellite monitor
temperature levels. Most of the temperature sensors
currently used in satellites convert these voltage changes
into corresponding current changes [4]. The OBC
contains current-to-voltage converters to convert each
such current level into a corresponding voltage level. The
ADC then converts this voltage into an equivalent
decimal number, which is then packed by the OBC into
its telemetry packet.
Separate calibration equations are developed at the
ground station for decoding information related to each
3
voltage, current, and temperature. A separate equation is
needed for each different subsystem of the satellite because
the current-to-voltage graph function may be different for each
given subsystem. Finding a voltage or current value from the
decimal value using the calibration equation is a reverse
process of conversion of these values into the decimal
numbers. For a given decimal number, the equation would
determine the value for the corresponding voltage, current, or
temperature in question. For example, for A, B, C, and D as
constants:
voltage1 = A decimal value
current1 = B decimal value
current2 = C decimal value
temperature = D decimal value
2.2. Decoding and executing telecommands
The telecommands from the ground station are used to
issue instructions to different subsystems of the satellite, via
the OBC, to perform different tasks. The commands, for
example, may be meant for the power subsystem to switch
ON/OFF any other subsystem, or these may be issued to a
camera so as to take a snap of the earth and store the image in
the OBC RAM. Similarly, Attitude Control System (ACS) may be issued commands to adjust position of the satellite.
ACS may also be commanded to send attitude related data,
such as sun sensor readings, to the ground station. Some
telecommands are meant explicitly for the OBC to, for
example, make it stop sending telemetry or to download the
photograph stored in the OBC RAM.
A telecommand connector is provided in the OBC on
whose pins a permanent-high or permanent-low signal would
appear when a particular command is received and decoded
by the OBC. These commands are called bi-level
telecommands. They are decoded into two distinct voltage
levels, where a high voltage level is meant for turning a
subsystem ON and a low voltage level is meant for turning it
OFF. The pins of the telecommand connector of the OBC (on
which bi-level commands appear) are connected through a
cable to the telecommand connector of the PCS. These
telecommands are thus used to switch ON/OFF any
subsystem by way of the PCS. The other type of
telecommands is the pulse telecommands. In this case, a pulse
is generated instead of a permanent-low or permanent-high
signal. This type of command is used to set off execution of
one-time operations such as taking a snapshot with camera, or
some other task which requires a triggering pulse for
execution.
The commands may also be time-tagged in advance,
especially for the camera, so that the camera could take a snap
while the satellite is not in view of the ground station. In this
case, the OBC retains the command in its memory after
decoding and, when the stipulated time is reached, a request is
issued to the camera subsystem for taking the picture.
2.3. Orbit and attitude control
The OBC monitors and adjusts the attitude of the satellite
with the help of a special circuitry, called Attitude Control
Subsystem (ACS). ACS contains sensors, which acquire data
pertaining to the attitude and orbit of the satellite at a
particular moment of time. In some satellites, special DSP-
based cards are employed in the ACS, which process this
data, using specialized algorithms, to determine the
attitude and orbit of the satellite. If some adjustments in
the attitude or orbit are required, the ACS can command
the actuators to adjust the orbit and/or attitude of the
satellite. Concurrently, the information received from the
sensors is also sent to the ground station, where similar
calculations, as those being done in ACS, are performed.
In case of failure on part of the ACS, the corrective
measure command is sent to the satellite by the ground
station. In some cases, OBC has the capability to obtain
the orbit and attitude data directly from the sensors and
make decisions to adjust the orbit and attitude. The
algorithms for controlling the orbit and attitude are a part
of the OBC software. This capability is required because
in LEO satellites the OBC should have the authority to
itself adjust its orbit and attitude when it is not in the view
of the ground station. However, when the satellite is being
tracked by the ground station, this function could be
performed by the ground station through the
telecommands.
2.4. Store and forward experiment (SAFE)
OBC can also operate in SAFE mode. In this mode
the OBC can store/forward messages from/to the ground
station. A part of the OBC RAM is reserved for storing
the messages on-board that have been sent from one
ground station to another.
The SAFE mode has STORE, DOWNLOAD,
MESSAGE LIST, and DELETE commands defined for it.
The STORE command is used to store a pre-defined
message sent from the ground station into the OBC RAM.
The DOWNLOAD command downloads a message from
the OBC to the ground station. The MESSAGE LIST
command provides the list of all messages currently
stored on-board. The DELETE command deletes the
message whose number is given in the command. When
SAFE operation is over, the OBC can be returned back to
the telemetry mode.
Figure 2. Main functions of an OBC
O
B
C
Telecommand
execution
Communication with
ground stations
Communication
with subsystems
Decisions on the
basis of data
analysis
Telemetry
gathering
On-board
memory
storage
4
3. A general-purpose OBC
Different satellites fall into different categories, i.e., nano-
satellites, micro-satellites, mini-satellites, and large satellites.
The subsystems‟ number in the satellites also varies
accordingly. Designing a general-purpose OBC for any given
category is a nontrivial task. Such an OBC should be able to
work with as many different subsystems in the satellite
category as possible. The problem we are addressing is to
architect and design a general-purpose Intel 80386EX-based
OBC for the LEO micro-satellite category. These satellites are
of several different kinds, e.g., experimental, communication,
earth observation, weather, and search and rescue satellites
(such as those built for international COSPAS-SARSAT
program).
If the number of peripheral subsystems for the LEO
micro-satellite is permitted to increase across its category,
then the OBC design should be flexible enough to
accommodate the extra interfaces for communication with
these subsystems. Another feature required in this case would
be the allowance of software routines for executing new
telecommands and processing the extra telemetry information.
Our design is flexible enough to accommodate an ample
amount of interfaces that may be generally essential in case of
LEO micro-satellites. It is possible to interface any new
subsystem with this OBC design using serial or parallel ports.
The software routines can easily be modified, if necessary, to
provide additional telemetry and telecommand capabilities.
The OBC would also have the capacity to accommodate
software routines to carry out special tasks required for the
specific mission for which the OBC is being adapted. Since
all the components used in the design of this OBC are of
CMOS technology, the logic level 0 may be set anywhere
between –12V and 0V and logic level 1 can be set between
+2V and +12V. This provides flexibility in interfacing with
other subsystems. The voltage levels and the number of serial
and parallel interfaces of the OBC may therefore be set
keeping in view the needs and requirements of the particular
satellite into which the OBC will be integrated.
4. Implementation of the design of a general-
purpose OBC
Figure 3 shows the basic functional diagram of our OBC.
There are six computers involved in this design. The first
three are the Telemetry, Telecommand, and Attitude Control
computers. They are single-function micro-controller-based
computers, which do not have to perform complex
computations. They collect data from the associated
subsystems and pass it on to a Central Computer. They
similarly pass on commands from the Central Computer to the
subsystems. The Central Computer is where the main
computations are performed, such as decoding the
telecommands, bus control, and communication with the
ground station. Three Central Computers have been used so as
to allow for redundancy.
The telemetry computer (TMY) gathers telemetry
information from other subsystems, such as the PCS, ACS,
and communication subsystem etc. It prepares a packet with
32 analog and 24 digital status signals and sends it over to the
OBC bus–a MIL-STD-1553 bus widely used in the aerospace
industry.
The telecommand computer executes telecommands
on behalf of the Central Computer where they were first
depacketized and decoded. The telecommand computer
simply changes the logic level at one of the pins of one of
the programmable peripheral interface (PPI) attached to
it. Our design provides for 48 telecommands, 44 of which
are bi-level commands and the remaining are pulse
commands. The PPI actually generates only bi-level
commands, which may be converted when needed to
pulse form with the help of a mono-stable multi-vibrator.
The attitude control computer gathers the orbit and
attitude data from the orbit and attitude sensors, performs
A/D conversions, and sends the data to the Central
Computer for analysis and/or onward transmission to the
ground station. Similarly, it receives commands in digital
form from the Central Computer, interprets them, and
then coverts them to analog form to dispatch to one of the
actuators to adjust the orbit or attitude of the satellite.
Figure 3. Basic Functional diagram of an OBC
4.1. Telemetry computer design
In this design, telemetry is gathered into the
telemetry computer through the various subsystems
(mentioned earlier) and the AD590 temperature sensors
located at different points in the satellite. The block
diagram of the analog portion of the telemetry computer
is shown in Figure 4. The microcontroller used is the
89C52, which can process up to 128 analog channels.
There are two 4067 analog 16x1 multiplexers used in the
design (shown as MUX 1‟s), where each one can gather
inputs from up to 16 analog channels. These inputs come
from the different sensors placed in other subsystems.
These include voltage, current, and temperature sensors.
This setup can be easily enhanced to accommodate 64
analog channels, in which case four of the 4067s would
be necessary. The Digital Status, that is the sensing of
voltages at different pins of various connectors, is read by
the 8255 Parallel Peripheral Interface (PPI). The
multiplexers are scanned by the microcontroller in round
robin fashion. The outputs of the two 4067 multiplexers
are fed into a 4051 8x1 analog multiplexer (shown as
MUX 2) whose output is fed into a 0804 ADC. The ADC
converts the analog input into digital form to be read by
the microcontroller. The microcontroller stores these
Telemetry
Computer
Telecommand
Computer
Attitude
Computer
Central
Computer 1
Central
Computer
2
Central
Computer
3
PCS Other AD590
TMY TMY TMY
Other
Subsystems
Attitude Attitude
Sensors Actuators
5
values temporarily in its internal RAM and, when all the 32
analog and 24 digital status lines have been read, a telemetry
packet is formed and stored in the external RAM. A 32 KB of
external RAM would be sufficient for this purpose. When the
Central Computer would ask for the telemetry, the telemetry
computer would then transmit these packets to it via the OBC
bus.
Figure 4. Block diagram of Telemetry Computer
4.2. Telecommand computer design
The telecommand computer, Figure 5, has a simpler
design than the telemetry computer. The design includes a
microcontroller, two 8255 PPIs, and one mono-stable multi-
vibrator. This design accommodates a total of 48
telecommands, out of these 44 are bi-level commands and the
remaining are pulse commands. For 48 telecommands, two
PPIs are required to generate 0V or 5V voltage levels, so as to
be considered as bi-level commands. The 5V level is usually
meant to switch ON any relay or solid-state switch, whereas
the 0V level means setting them OFF. The PPIs are connected
to the data bus of the microcontroller. The microcontroller
generates bi-level commands that are executed through the
PPI. The PPIs are selected one at a time by the
microcontroller as required. The output of the PPI is either
logic 1 or logic 0. These are used to turn ON/OFF any
subsystem via the PCS. The PCS is, therefore, usually placed
near the OBC. If the logic level of a given PPI pin is 1, the
associated subsystem would stay ON till when the logic level
returns to 0.
The pulse commands are generated using the mono-stable
multi-vibrator. When the status of the PPI pins connected to
the input of this multi-vibrator change from logic 0 to logic 1,
the multi-vibrator would generate a pulse. The pulse is
generated when the logic level at the output of the
concerned pin changes from 0 to 1 and then back to 0. The
duration of this pulse can be adjusted by using external
resistors and capacitors.
The telecommand is first received, depacketized, and
decoded by the Central Computer. The Central Computer
then generates a two-byte telecommand for the
Telecommand Computer. The first byte contains data
regarding the name of the subsystem to be turned ON or
OFF, while the second byte contains the actual command.
Both bytes collectively tell the Telecommand Computer
about which pin of the PPI1 or PPI2 should be turned to
logic 0 or logic 1.
Figure 5. The Telecommand Computer
4.3. Attitude control computer design
As described above, the main function of the Attitude
Computer is to gather attitude data from sensors and
transmit it to the Central Computer. The Central
Computer performs necessary calculations on this data
and issues commands back to the Attitude Computer to
apply control functions on actuators. During satellite pass
this information may be uploaded to the ground stations
for retaining history of orbit/attitude of the satellite.
4.4. The design of the central computers
Central Computers are built around the Intel
80386EX microprocessors [5]. A simplified diagram of
the Central Computer is shown in Figure 6. The computer
has 512 Kbytes (128 Kbytes x 4) of RAM, implemented
with 431000 chips, and 256 Kbytes (128 Kbytes x 2) of
ROM. It is configured using a 29C010. E2PROM is used
to keep the possibility of on-board re-programming and
erasing of the program memory to keep room for code-
patching during the mission flight. The microprocessor
contains many units, which are otherwise used as
peripherals such as serial ports, chip select units, and
interrupt control unit, etc. This decreases the number of
components on board and simplifies its design.
Analog Telemetry
(16 Channels)
Digital
Output
MUX 1
4067
MUX 1
4067
MUX 2
4051
Analog Telemetry
16 Channels
ADC
0804
µCont.
89C52
PPI
8255
Digital Status Lines
(24 Lines)
89C52 Microcontroller
8255 PPI 1
8255 PPI 2
TC from GS
Mono
M/V
Different
Subsystems’
Relays/Switches
Pulse
Commands
6
Figure 6. Simplified Diagram of the Central Computer
The telemetry computer sends two types of telemetry
packets to the Central Computer over the system bus. The
first kind is the real-time telemetry data, which consists of
packets that are dispatched during the satellite pass over the
ground station. These are transmitted either regularly at
predefined intervals of, say, one minute or activated through a
telecommand. The Central Computer translates the packets
into CCSDS standard form. These are then passed to the
satellite transmitter for onward transmission to the ground
station. The second type is the whole-orbit telemetry packets
required at ground station to know the behavior of the satellite
when it is not in the view of ground station. These packets
contain a special mark in their header and are sent to the
Central Computer every five minutes. They are held in the
Central Computer RAM and are transmitted to the ground
station when a request in the form of a telecommand is
received.
Table 1. Specifications of MIL-STD-1553 data bus
Data rate 1 MHz
Word length 20 bits
Data bits/word 16 bits
Message length Maximum of 32 data words
Transmission technique Half duplex
Operation Asynchronous
Encoding Manchester II bi-phase
Protocol Command/response
Bus control Single or multiple
Fault tolerance Typically dual redundant,
second bus in “Hot
Backup” status
Message formats Controller to terminal
Terminal to controller
Terminal to terminal
Broadcast
System control
Number of remote terminals Maximum of 31
Terminal types Remote terminal
Bus controller
Bus monitor
Transmission media Twisted shielded pair
Coupling Transformer and direct
The Central Computer is responsible for control of
the data bus which is done according to the MIL-STD-
1553 standard. The specifications of this data bus are
summarized in Table 1 [6].
The data bus standard defines four hardware
elements: the transmission media, remote terminals, bus
controllers, and bus monitors. There are only three
functional modes allowed on the bus: the bus controller
mode, the bus monitor mode, and the remote terminal
mode. The Central Computer, the Telemetry Computer,
the Telecommand Computer, and the Attitude Computer
are capable of working in more than one modes. The
Central Computer acts as the Bus Controller, and the
Telemetry, Telecommand and Attitude computers would
act as Remote Terminals. Figure 6 illustrates a typical bus
configuration.
Bus Controller – The bus controller is the terminal
that initiates information transfer on the data bus. It
sends commands to remote terminals. The remote
terminals act in response to the command. The bus
can support multiple controllers, but only one may be
active at a time. Other requirements for bus controller
as per 1553 standard are: (a) it is “the key part of the
data bus system” and (b) “the sole control of
information transmission on the bus shall reside with
the bus controller.”
Bus Monitor – Bus monitors are frequently used for
instrumentation. The 1553 standard defines the bus
monitor as “the terminal assigned the task of
receiving bus traffic and extracting selected
information to be used at a later time.”
Remote Terminal – Any terminal not operating in
either the bus controller or bus monitor mode is then
operating in the Remote Terminal (RT) mode.
Remote terminals are the largest group of bus
components [8,9]. 1553 BUS STRUCTURE
BusController
BC
RemoteTerminal
RT
MonitorM
RemoteTerminal
RT
RemoteTerminal
RT
Shielded Two-wire CableBus
Figure 6. MIL-STD-1553 Bus Structure
The unit of communication measurement on the Bus
is in words. A word in MIL-STD-1553 is a sequence of
20 bits, with 3 bits for sync waveform, 16 bits for data,
and 1 bit for parity-check. 1553 terminals add the sync
and parity bits before transmission and remove them on
reception.
There are three types of words: command word, data
word, and status word. Figure 7 shows word formats for
MIL-STD-1553 data bus [9].
Intel 80386EX
Microprocessor
431000
RAM
29C010
E2PROM
7
1553 WORD FORMAT
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
15515
16 1
PData
P
1111111115 3
Sync
Sync
Sync
BIT Times
Command
Word
Word
Data
Status
Word
Remote Terminal
Address
T/R Subaddress / Mode Data Word Count /
Mode Code
Remote Terminal
Address
Mess
ag
e E
rror
Inst
rum
enta
tion
Serv
ice R
eq
uest Reserved
Bro
adca
stC
om
ma
nd
Rece
ive
d
Busy
Dyn
am
ic B
us
Con
tro
l Acc
epta
nce
Sub
syst
em
Fla
g
Term
inal F
lag
Parity
Status
T/R - Transmit / Receive
P - Parity
Figure 7. MIL-STD-1553 word format
The primary purpose of the data bus is to provide a shared
medium for exchange of data messages between subsystems.
A message format is shown in Figure 8. Message
transmissions can be done in ten different formats, all of
which are based on the three word formats just mentioned [9].
The information transfer formats are based on the
command/response philosophy, in which all error-free
transmissions received by a remote terminal are followed by
transmission of a status word from the terminal to the bus
controller. This handshaking validates receipt of the message
by the remote terminal.
1553 DATA MESSAGE FORMAT
ReceiveCommand Word
DataWordData
StatusWord
StatusWord**
CommandWord#
From RT Next Sequence
TransmitWord
DataWord Word
Data
DataWord
WordData
WordCommand
#
Next Sequence
From Controller
From Controller
**
From RT
Controller
to RT
Transfer
Transfer
Controller
RT to
Command
From Controller
Receive TransmitCommand WordWord
Transmitting RT
Status DataWordData
**
From
WordData
**StatusWord
FromReceiving RT
#Transfer
RT to RT
RT=Remote Terminal ** # = End of overall sequence= End of transmission from that unit
Figure 8: MIL-STD-1553 data message format
The Central Computer, acting as bus controller, broadcasts a
command word, which all three microcontroller-based
computers would receive. The particular computer for which
it is meant would then take control of the bus and send an
acknowledgement. This computer transmits the same number
of bytes of the requisite data as mentioned in the command
word sent by the Central Computer. When this computer
releases the bus, the Central Computer would take the control
back.
The Central Computer also broadcasts a keep-alive message
on the bus every five minutes, which is received by the other
two Central Computers. In case the Central Computer #1
fails, and the other two do not receive such packet within next
five minutes, the Central Computer #2 would automatically
take control of the bus and start sending keep-alive messages
of its own. If the Central Computer #2 had failed prior to the
failure of Central Computer #1, then the Central Computer #3
would not receive a keep-alive message from Central
Computer #2 after the stoppage of keep-alive messages
from Central Computer #1. The Central Computer #3,
after waiting for 10 minutes, would thus take charge of
the bus. During this time no activity would however be
performed by the OBC.
5. Telecommand execution
The hardware setup required for telecommand execution
of the telecommand has already been explained. Two
options are available for the designers for packetizing the
telecommand; either to follow the CCSDS standard of the
European Space Agency (ESA)–which we recommend–or
to design their own standard. Following the CCSDS
standard would make the system practically prone to
transmission errors. If the designers opt for the CCSDS
standard, the following guidelines would prove to be
helpful for designing the software. [7,12]. The
telecommand packet structure is shown in figure 9 below.
Packet Header (48 bits) Packet Data Field (Variable)
Packet ID Packet SequenceControl Length
Packet Data Fieldheader
(optional)Data
Application Paket Errorcontrol
(optional)
Version#
3
Type Data
FieldHeader
Flag
Application
Process ID
1 1 11
16
Sequence
flags
2
Sequence
Count
14
16 Variable Variable 16
TC Packet
PUS Version
#
Checksum
Type
Ack Service
Type
Service
Sub-Type
3 1 4 8 8
Data Field Header format
Figure 9. Telecommand Packet Structure
The CCSDS recommendations and terms for
telecommand packet are shown in Table 2. The column
values marked TBD are to be decided by the design
engineers, as they would vary from mission to mission.
Table 2. CCSDS packet structure 1. Sub-carrier frequencies, modulation and
waveform
8 or 16 KHz, PSK,
Sine wave
2. Choice of TC data waveform NRZ-L, M
3. Range of TC bit rates 4000/2n, n=0,1, ...,9
4. Medium-rate modulation; range of TC
bit rates
PCM/PM/Bi-Φ
4000*2n; n=1,2,…,6
5. Largest possible length of TC packet 65542 Bytes / Octets
6. Largest possible TC transfer frame
length
1024 Bytes/ Octets
7. Data field header TBD
8. APIDs TBD
9. Application data (No. of bytes, Type) TBD
10. Packet error control TBD
11. Packet segmentation TBD
12. MAPS MAP0 and MAP1
13. Spacecraft ID 123 (TBD)
14. Service types and sub-service types TBD
If the designers wish to implement their own
telecommand system, the following guidelines together
with the recommended software execution steps should
prove helpful. The OBC by default operates in telemetry mode. To
switch it to telecommand mode, an interrupt consisting of
two characters (BY) is sent to it from the ground station.
After switching to the telecommand mode, the OBC
8
would send one character ( ) to the ground station as an
acknowledgement of the interrupt. If the interrupt characters
reach the satellite in corrupted form, no action is taken there.
If an acknowledgment is not received at the ground station for
30 seconds, the ground station would send the interrupt and
waits for another 30 seconds. If the interrupt characters are
accepted by the OBC and the acknowledgement is
successfully received at the ground station, the ground station
is next required to send the password for the telecommand
(AJS). The OBC (after having sent the interrupt
acknowledgement) waits for the password for one minute. If
the password is not received within one minute, the OBC
would return to the telemetry mode. OBC can accept or reject
the password. If the password is accepted, OBC sends a
character ( ) which means that the OBC is ready for receiving
the telecommand. If the password is rejected, OBC sends two
characters ( ) to tell that the password is rejected and should
be sent again. The OBC waits for 2 minutes for a second try of
the password. If the password is received within this time and
is acceptable, the OBC becomes ready for receiving the
telecommand. If the password is not received the second time
within 2 minutes or is again rejected, OBC sends two
characters (½à) to tell that it is reverting to the telemetry
mode. On finally successfully receiving the telecommand
packet, the OBC checks whether the command is meant to be
executed immediately or is it a time-tagged telecommand. The
17-byte configuration of telecommand packet is shown in
figure 10.
Date Time
(UTC)
Command
Word
Time-
Tagged/No
Time
Tagged
CRC End of
Packet
Flag
6
bytes
6
bytes
1 byte 1 byte 2
byte
1 byte
Figure 10. Configuration of telecommand packet
When a telecommand is successfully executed, OBC
sends a two-characters verification ( ) to the ground
station. This verification is also stored in the OBC RAM to be
later sent to the ground station. Sometimes there is a
requirement that the status of all the commands executed on-
board during the past, say, one week be shown. These
verifications would then prove to be helpful. Ten such
verifications (20 bytes) can be stored in the RAM one after
another, after which they will be overwritten by the
subsequent verification bytes. After executing a telecommand,
the OBC waits for one minute for the next commnad. If it is
not received within this time, it returns automatically to the
telemetry mode. OBC can also be explicitly returned from the
telecommand mode to the telemetry mode by sending it the
characters ( ).
If the CRC check for the telecommand packet shows that
the packet is corrupted, OBC sends two characters (¿§) to the
ground station showing that the telecommand packet received
was corrupted and should be sent again. The verification or
the ARQ is sent three times with a gap of 5 seconds to make
sure that it does reach the ground station in case of any loss
during transmission. The telecommand packet is retransmitted
two times, if required. In case all the three tries fail, the OBC
returns to the telemetry mode automatically.
Once the OBC is interrupted from the telemetry
mode, it can be switched to SAFE mode also. The
password for the SAFE mode consists of two characters
( ). When the password is accepted, the OBC sends
down one character confirmation ( ) to the ground
station. If the password is rejected, OBC sends down two
characters ( ), showing that the password has been
rejected and should be sent again. In this case also OBC
waits for two minutes for the next password try, otherwise
it reverts to the telemetry mode automatically. If the
password is rejected for the second time also, OBC
similarly returns to the telemetry mode. OBC gives five
minutes to the user to perform the SAFE operation after
sending its password acceptance to the ground station.
After five minutes, OBC would return to the telemetry
mode automatically.
6. System software design
6.1. On-board software
The on-board software of OBC is a complete
operating system. It performs the following functions:
a) Initialization of microprocessors and
microcontrollers and their peripherals.
b) Gathering of telemetry, done through the
Telemetry Computer. Packetizing telemetry
information. Storing telemetry packets in OBC
RAM and uploading them to the ground station.
Telemetry mode is the default mode; the OBC
Central Computer has to be interrupted for
switching to telecommand mode.
c) Analyzing the telemetry data received from
different subsystems through the Telemetry
Computer and then making decisions regarding
switching ON/OFF any subsystem.
d) Receiving, decoding, and executing
telecommands. SAFE mode is a part of
telecommand mode.
The detail of the telemetry packet, as suggested by
CCSDS, can be seen in [3,11].
Telemetry packets are usually sent by the OBC with
a time gap of 5 seconds between each packet. For the
duration of the gap, idle packets (with 0s padded in the
data field) are sent to the ground station so that
synchronization between the satellite and ground station
is not lost.
If the software designers instead of using the CCSDS
standard wish to implement their own telemetry packet
system (for any practical reason), the following guidelines
would be helpful.
The telemetry packet should hold at least the
following information. The information to be transmitted
in the packet may vary from mission to mission and its
requirements. The following shows some examples.
1) Satellite identity.
2) Date and time.
3) Packet number: This number will start from 1 and go
up to 256. After 256, the number gets reset and start
from 1 again.
4) Information regarding whether the packet is a real-
time packet (i.e., when the satellite is in the view of
the ground station) or is it the packet which was
9
previously stored in the OBC RAM (the whole orbit
telemetry).
5) Analogue telemetry: This contains 32 channels. 160 bytes
would be required to send information contained in these
32 channels. Two bytes are reserved for the channel
number and three bytes for the analog value being sent in
that channel. This analog value is sent as a digital number,
as explained earlier. The digital number is sent to the
ground station after conversion into ASCII codes.
6) Digital status. This contains 24 digital status inputs,
represented in three channels. A channel number is
indicated with the help of the first two of these three
bytes, whereas the value is represented as a hexadecimal
number in the last byte. If we receive A3H in a digital
status channel, this would mean 10100011 in binary. So
bit 0, 1, 5 and 7 are ON and the others are OFF. These
bits would represent 5V at different pins of power
connectors of the different subsystems. This means that
there are a total of 35 channels; 32 of these are for
analogue telemetry and 3 are for digital status.
The format of the telemetry packet is shown below.
Satellite
ID
Date Time
(UTC)
Packet
Number
Real
Time
or
Whole
Orbit
TMY
Data
End of
Packet
Flag
4 bytes 6
bytes
6 bytes 1 byte 1
byte(*)
172
bytes
1 byte
(↓)
The telemetry data is in the following form.
Channel
Number
(2
bytes)
Decimal
Value (3
bytes)
Channel
Number
(2 bytes)
Decimal
Value (3
bytes)
Channel
Number
(2 bytes)
Decimal
Value (3
bytes)
01 070 02 178 03 234
6.2. Ground Station Software
Following are the main functions of the ground station
software, which has been implemented in the C language.
Three P-IV PCs, connected through a LAN, will be adequate
for running the Ground Station software. One computer is
required for Telemetry, one for Telecommand, and one for
SAFE mode.
i) Receiving and consequently displaying and archiving
the telemetry data from the OBC. When the satellite
is in view of the ground station, each telemetry
packet received is stored primarily in a buffer in the
PC RAM. When the buffer becomes full, the packets
are copied into a file. The file remains open till the
completion of the current pass of the satellite. Data
from each new pass goes into a separate file; the files
are named according to the pass number. This file is
processed by separate software, which unpacks
telemetry packets, applies calibration equations to the
data, and either displays the resulting information or
stores it into archive files.
ii) Generating telecommand packets and scheduling
their retransmission, when necessary.
iii) Receiving, and consequently displaying and storing,
pictures from the on-board camera. The picture is
received as a bit stream and is simultaneously shown
on the display. The picture may also be stored as an
archive file.
iv) Generating packets of the message, which was
already typed when the satellite pass was not in
view, and transmitting them to the satellite for
SAFE operation. Receiving response messages
from the satellite, displaying them, and storing
them in a file. Retransmitting during uplink
transmission the packets previously received in
error at the OBC.
7. Conclusion
The OBC design presented in this paper is simple,
general-purpose, easy to implement, and economical. The
OBC has been designed in such a way that it can be used
in, or adapted to, almost any LEO micro-satellite with
minimal changes. The components used in the design are
inexpensive, generally used, and readily available. No
special components, such as FPGAs or PLAs etc., have
been used. Ample technical literature is available for the
80386EX microprocessor and the other peripheral
components, which focuses on their use, interfacing, and
programming. Development systems are also easily
available for this microprocessor.
The interfaces of the OBC have flexible voltage levels.
Therefore they can be customized to work with a variety
of subsystems. The requirements addressed in the design
for the memory, serial and parallel ports, and analogue
and digital telemetry are completely adequate for a micro-
satellite. However, extra serial and/or parallel ports can be
added to accommodate additional subsystems. An OBC
offering these characteristics should be an excellent choice
for the developing countries to use in their current and
future space projects.
8. References
[1] www.sstl.co.uk/datasheets/subsys_obc386.pdf
[2] Mazlan Othman and Ahmad Sabirin Arshad, “TiungSAT-1:
From Inception to Inauguration,” Astronautic Technology (M)
Sdn. Ghd., 2001.
[3] “Packet Telemetry Standard (ESA PSS-04-106 Issue 1),”
The Standards Approval Board (STAB) for Space Data
Communications, 1988.
[4] Robert F. Coughlin and Robert S, Villanucci, “Introductory
Operational Amplifiers and Linear ICs – Theory and
Experimentation,” Prentice Hall, 1998.
[5] “Intel 80386 EX Embedded Microprocessor User’s
Manual,” Intel Corporation, 1996.
[6] “MIL-STD-1553 Tutorial,” Condor Engineering, Inc., 2000.
[7] “Packet Telecommand Standard (ESA PSS-04-107 Issue 2),”
The Standards Approval Board (STAB) for Space Data
Communications, 1992.
[8] Leroy Earhart, “MIL-STD-1553, Aircraft internal time
division command/response multiple data bus”, Test Systems,
Inc Phoenix, Arizona.
[9] “An Interpretation of MIL-STD-1553B” ver2.0 May 26,
1998.ftp://ftp.sbse.com/web_files/pdf/general/1553Interpretation
[10] A.Schoonwinkel et al, “Pre-flight performance of
SUNSAT,SOUTH AFRICA’s first remote sensing and packet
telecommunication s Microsatellite”, EEE Department,
Stellenbosch University, South Africa.
[11] “Packet Telemetry”, Recommendations CCSDS 102.0-B-5,
Issue 5, „Blue Book‟, Consultative Committee for Space Data
Systems, Nov 2000.
[12] “Packet Utilization Standard”, (ESA PSS-07-101) Issue 1,
May 1994, European Space Agency.