Design and Development of Generic Nanosatellite Bus Ground ControlSoftware Suite
by
Mirue Choi
A thesis submitted in conformity with the requirementsfor the degree of Master of Applied Science
Graduate Department of Aerospace EngineeringUniversity of Toronto
Copyright c© 2010 by Mirue Choi
Abstract
Design and Development of Generic Nanosatellite Bus Ground Control Software Suite
Mirue Choi
Master of Applied Science
Graduate Department of Aerospace Engineering
University of Toronto
2010
This thesis describes, in chronological order, the design and implementation of four separate
ground control applications for use of the Generic Nanosatellite Bus, a multi-purpose satellite
platform developed at the UTIAS Space Flight Laboratory. A direct ground control application
and time-tagged remote control application are used to provide full control over a Generic
Nanosatellite Bus satellite for short and long term operational and testing purposes. Similarly,
a direct control application and a scheduling application are implemented for the control of the
payload computer on CanX-3 BRIght-star Target Explorer, a stellar-observation satellite based
on the Generic Nanosatellite Bus platform. This thesis goes into details on how the display and
control interface is implemented and used, what set of actions are taken to create and interpret
packets exchanged over a communications link, and what precautions are taken in the face of
expected issues.
ii
Acknowledgements
I’d like to start this by acknowledging Dr. Robert Zee, foremost of all. Without your invitation
to begin my masters program here in SFL, I would not be a part of this wonderful discipline of
study, nor would I be gearing up for Ph.D. in it. It is all thanks to you that I have gotten to
where I am now. I am truly grateful for being given this opportunity.
I’d like to acknowledge everyone from SFL for their hard work and having been my associa-
tion for the last two years, but among them, these people stood out for me: Daniel Kekez for all
your work in NICE and TIP, and many other common codes you wrote and commented before
I was in SFL, and countless other questions I asked during my stay here. Without you and the
answers you gave me, I may still be lost in my own mess of codes. Jakob Lifshits, for all our
discussions about the questions I posed, about IOBC, about the imager, and much more. You
being there as a fellow Computer Engineering student really helped me out to the very end.
Mark Dwyer, for your work with CANOE software and all our discussions regarding it. So much
of what I have done is connected directly to your work. Roman Ronge, for your contribution to
building the ADCS interface for my GNBControl. Our spirited discussions did manage to get
somewhere! Henry Spencer, for your work on the bootloader. I had trouble staying awake for
the bootloader review sessions we had, but they were nonetheless a learning experience. Mihail
Barbu, for your work with the power board and IOBC, gladly answering any questions I had
with them, and being the person to go to when I have a hardware problem for anything. I’d
still be waiting for new parts without you. Grant Bonin, for your work in BCDR and your
ground software, BCDRTerm. Your software for BCDR set a great example for others working
with devices, and made my life that much easier. Marc Fournier and Michael Greene, for all
the work you’ve done for the attitude control device software, and all those answers to get all
those device interfaces running. Karan Sarda and Amee Shah for the guidance in working with
the ground station, which translated to my capacity to judge what a good interface should do
and should not do. Jakub Urbanek, for taking over the duty of the operator. You’re already
more deeply involved in it than I am, so no worries there. Scott Armitage for his guidance in
Latex to write this thesis, and the often-created Shawarma run with his car. Patrick Gavigan
and Laura Bradbury for making our little corner more lively than ever. Erica Peterson for your
iii
cookies and cupcakes! Though I doubt Patrick found them amusing. Last but certainly not
the least, Cordell Grant, for your guidance and help in getting connected with everyone in and
outside the lab to get the work done.
Finally, to Mom, Dad, and little sis Narae: my family. All of this would be meaningless
without your wholehearted support. I’m glad you’re here, and I hope it will be so for a long,
long time.
iv
Contents
1 Introduction 1
1.1 The CanX Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Current Ground Control Station Architecture . . . . . . . . . . . . . . . . 2
1.2 Generic Nanosatellite Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Generic Nanosatellite Bus Ground Control Application 6
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Overall Design Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Queue Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Threaded Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Persistent, Customizable Command Script . . . . . . . . . . . . . . . . . . 16
2.2.4 Achieving Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5 Information Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.6 Subsystem/Device Interface Management . . . . . . . . . . . . . . . . . . 19
2.3 Main Architectural Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Intra-Application Message Queue . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 Packet Storage and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.3 Queue Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.4 Managing and Displaying History . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.5 Application Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Individual Subsystem Architectural Implementation . . . . . . . . . . . . . . . . 36
2.4.1 “Main” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
v
2.4.2 Attitude Determination and Control System . . . . . . . . . . . . . . . . . 40
2.4.3 Device with Similar Access Schemes . . . . . . . . . . . . . . . . . . . . . 45
2.4.4 Custom Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3 GNB Time-Tagged Commands Control Application 48
3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Satellite-Side TimeTag Implementation . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 Overall Design Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.1 Simplification of Queue Structure . . . . . . . . . . . . . . . . . . . . . . 53
3.3.2 Knowledge of Contents and Scripting of Time-Tagged Packets . . . . . . . 53
3.3.3 Information Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4 Architectural Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.1 Queue Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.2 Packet Storage and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.3 TimeTag Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.4 TimeTag Script Language . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.5 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.6 Automation of GNB TimeTag . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 BRITE Target Observation Scheduler 67
4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 BRITE Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3 BRITE Payload Imager System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4 Overall Design Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4.1 Handling BRITE Target Setup File . . . . . . . . . . . . . . . . . . . . . . 72
4.4.2 Command Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4.3 Generating Observation Commands . . . . . . . . . . . . . . . . . . . . . 75
4.4.4 Generating and Decoding TimeTag Scripts . . . . . . . . . . . . . . . . . 75
4.5 Architectural Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5.1 BRITE Target Setup File and Target Field Selection . . . . . . . . . . . . 76
vi
4.5.2 Command Interface, Generation, Storage . . . . . . . . . . . . . . . . . . 80
4.5.3 Exporting and Importing TimeTag Scripts . . . . . . . . . . . . . . . . . 82
5 BRITE Payload Ground Control 85
5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2 Overall Design Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.1 Image Downloading Module . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.2 Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.3 IOBC Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Architectural Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.1 Image Download and Display . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.2 IOBC Command Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6 Conclusions 96
6.1 Recommendations for Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Bibliography 98
vii
List of Tables
2.1 GNBControl Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 GNB TimeTag Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1 BRITE Schedule Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 Two Sample BRITE Target Setup Files with Different Parameters . . . . . . . . 73
5.1 BRITE PGC Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
viii
List of Figures
1.1 Block Diagram of the Current Ground Control Station Architecture. . . . . . . 3
1.2 NICE Main Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 The GNB Layout [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Sequential Diagram for a Typical Satellite Pass without a Queue. . . . . . . . . . 12
2.2 Sequential Diagram for a Typical Satellite Pass with a Queue. . . . . . . . . . . . 13
2.3 Block Diagram of GNBControl Architecture. . . . . . . . . . . . . . . . . . . . . 21
2.4 GNBControl Root Interface Screen. . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 GNBControl Queue Interface Screen. . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6 GNBControl History Logger and Packet Display Interface Screen. . . . . . . . . 24
2.7 GNBControl Options Interface Screen. . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Flow Diagram for Processing Packets to be Sent in GNBControl. . . . . . . . . 28
2.9 Flow Diagram for Receiving and Processing Packets in GNBControl. . . . . . . 30
2.10 Flow Diagram for Propagation of OPTIONS Object. . . . . . . . . . . . . . . . 34
2.11 Options List showing ADCS Modes Configuration List being Modified. . . . . . 35
2.12 Satellite Subsystems and corresponding GNBControl’s Subsystem Interfaces . . 36
2.13 Main Subsystem Interface Window on GNBControl. . . . . . . . . . . . . . . . . 37
2.14 OBC Switching Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.15 ADCS Interface with ACS Exchange. . . . . . . . . . . . . . . . . . . . . . . . . 41
2.16 Sample ACS Exchange Structure and Memory Manipulation. . . . . . . . . . . . 43
2.17 I2C Interface with Configuration for BCDR. . . . . . . . . . . . . . . . . . . . . 45
2.18 Custom Packets Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
ix
3.1 High Level Time Tag Architecture. [23] . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Difference of Knowledge between GNB TimeTag and GNBControl. . . . . . . . 54
3.3 Block Diagram of GNB TimeTag Architecture. . . . . . . . . . . . . . . . . . . . 58
3.4 GNB TimeTag Root Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5 Sending Packets in GNB TimeTag. . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6 Receiving Packets in GNB TimeTag. . . . . . . . . . . . . . . . . . . . . . . . . 62
3.7 Command Interface in GNB TimeTag. . . . . . . . . . . . . . . . . . . . . . . . 62
3.8 A Sample TimeTag Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.9 Options Interface Pop-up Window. . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.10 Pass Information Display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.1 BRITE Target Graphic User Interface. [26] . . . . . . . . . . . . . . . . . . . . . 70
4.2 Relationship between BRITE Payload Imager System Hardware . . . . . . . . . 71
4.3 BRITE Schedule Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4 Block Diagram of Classes in BRITE Schedule. . . . . . . . . . . . . . . . . . . . 78
4.5 Flow Diagram for Parsing BRITE Target Setup Files. . . . . . . . . . . . . . . . 79
4.6 Command Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.7 Creating a TimeTag Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1 Block Diagram of BRITE PGC Architecture. . . . . . . . . . . . . . . . . . . . . 91
5.2 BRITE PGC Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3 Image Displayed on Image Display while Downloading. . . . . . . . . . . . . . . 94
5.4 BRITE PGC when Sending a Packet. . . . . . . . . . . . . . . . . . . . . . . . . 95
x
Chapter 1
Introduction
The Space Flight Laboratory (SFL) at the University of Toronto Institute for Aerospace Studies
(UTIAS) is Canada’s foremost expert in the field of nanosatellites (classification for satellites
with mass value ranging from 1 to 10 kg). Embracing the microspace philosophy [1], SFL is
composed of 17 staff members and 15 students to form a tightly-knit multi-disciplinary team of
engineers in a relatively informal environment, proven to be capable of achieving the mission
objectives in severely cost/time-constrained situations. Already with two nanosatellites in orbit
and fully operational, SFL is currently poised to send four additional nanosatellites into space,
under the common design of the Generic Nanosatellite Bus (GNB).
These GNB satellites need to be controllable from ground via ground control applications.
The ground control application currently in use at SFL is lacking in terms of efficiency and
variability, hence is highly-unsuitable for the upcoming missions. This thesis explores the
design and implementation details of four ground control applications that have been developed
to replace the current ground control application. They, as a whole, also attempt to provide a
long term ground control solution to any nanosatellites using the GNB platform.
Each ground control application specializes in a particular form of functionality. One ap-
plication is used to provide direct control over all components of the GNB platform, while
another allows issuing of time-tagged commands to the satellite. The other two applications
generate time-tagged commands and provide direct control for the payload system of CanX-3
BRIght-star Target Explorer (BRITE).
1
Chapter 1. Introduction 2
1.1 The CanX Program
Initiated in 2001, the goal of the Canadian Advanced Nanospace eXperiment (CanX) program
is to design and build low-cost nanosatellites for education and research purposes. Masters
students, under the guidance of senior engineering staff, contribute to developing and building
the satellites. Since the Masters program typically lasts two years, a satellite ideally is designed,
developed and assembled within the said two years to provide the students with full exposure
to all aspects of a typical satellite mission. This, in combination with low development cost,
allows satellites under the CanX program to possess quick turnaround time on funding invested.
Hence, scientists can gain cheap avenues of access to space, while the students gain the much-
needed exposure and experience on working with fully operational satellites. Currently, CanX-2
technological demonstration nanosatellite and CanX-6 Nanosatellite Tracking of Ships (NTS)
are in orbit, having completed their mission objectives but still fully operational and performing
additional experiments. See the CanX-2 System Overview [2] and conference paper on NTS [3]
for more information.
1.1.1 Current Ground Control Station Architecture
The current ground control architecture is described by Figure 1.1 shown below. Communi-
cation with the satellite is achieved by using an UHF uplink and S-Band downlink antennas
installed as part of the ground station hardware. Terminal Node Controller (TNC) maintains
control over the antennas and provides pathways for the data to move from the satellite to the
ground control applications and vice versa. Terminal Interface Program (TIP) is connected to
TNC, redirecting the data received from TNC to the appropriate client application connected to
it, or sending data from one of its client applications to TNC to be transmitted to the satellite.
Of the three applications connected to TIP in the figure, Whole Orbit Data Downloader
downloads the Whole Orbit Data from the satellite, while the Satellite Telemetry Snapshot
takes a snapshot of the current satellite telemetry, both in an automated fashion and displayed
/ logged appropriately. The two applications together serve as a way to check the satellite’s
health from the ground station.
Chapter 1. Introduction 3
Figure 1.1: Block Diagram of the Current Ground Control Station Architecture.
Commands to either CanX-2 or NTS are sent via Nanosatellite Interface Control Envi-
ronment (NICE), its interface shown below in Figure 1.2. A collaborative effort from Eric
Caillibot, Daniel Kekez and Nathan Orr, NICE was developed to be a simple, uncomplicated
interface for issuing various commands to the satellite in space. Currently, NICE is split into
two distinct builds, one containing the automated payload data downloading module for NTS,
and the other containing the more varied and flexible payload experiment scheduling module
for CanX-2. NICE has been in service as long as the two satellites have, and changes have
been made reactively to various issues that occurred while in orbit. The most recent build for
CanX-2 has been in use for over a year, while the current build for NTS has been in service for
approximately eight months at the time of writing.
1.2 Generic Nanosatellite Bus
With the stunning success of CanX-2 and NTS, the number and the scope of missions under
SFL increased. As CanX-2 and NTS were both developed according to the irrespective missions,
new missions meant developing a host of new satellites. To mitigate the overhead required in
design of a new satellite bus for each mission, the Generic Nanosatellite Bus (GNB) design,
shown below in Figure 1.3, was created.
Most satellite designs end up requiring similar or same parts as the previous design to
mitigate the cost for its development and testing. The same idea can be extended to subsystems,
Chapter 1. Introduction 4
Figure 1.2: NICE Main Interface.
and in a larger scale, to an entire satellite bus. GNB is designed for the specific purpose of
allowing a large variety of payloads to be accommodated in a singular bus design, promoting
reuse of the design for various missions with only its payload swapped out. This allows a
significant amount of cost for design, development and testing of a typical satellite to be cut
away safely, while providing similar or higher level of quality that CanX-2 and NTS have seen.
Currently three missions are planned to make use of the GNB design: CanX-3 BRITE, CanX-4
and CanX-5 Formation Flying, and AISSat-1.
CanX-3 BRITE is a multi-nation (Canada, Austria, Poland), multi-satellite constellation
for long term stellar imaging and observations. Its mission is to gather photometric data on the
brightness and temperature variations of the brightest stars on various timescales, providing
unprecedented precision that cannot be obtained from the ground due to limitations imposed
by the terrestrial atmosphere [5]. Its payloads are composed of a telescope, a CCD imager and
a star tracker. The Austrian satellites are scheduled for launch in 2011.
CanX-4/5 Formation Flying mission uses two identical GNB nanosatellites equipped with
Chapter 1. Introduction 5
Figure 1.3: The GNB Layout [4].
thrusters to demonstrate low-cost, high-precision formation flying capabilities of nanosatellites.
Other mission objectives include demonstrating centimeter-accurate relative position determi-
nation and sub-meter relative position control, demonstrating autonomous formation mainte-
nance in multiple orbital configurations and at various separation distances and developing
fuel-efficient autonomous formation flight algorithms [6]. CanX-4 and CanX-5 have a tentative
launch year of 2011.
The goal of the Automatic Identification System Satellite (AISSat-1) mission is to inves-
tigate the feasibility and performance of a spacecraft-based Automatic Identification System
(AIS) sensor in LEO as a means of tracking maritime assets, specifically those within Norwegian
territorial waters [7]. Its payload is an AIS receiver, and its functionalities are very similar to
above-mentioned NTS. Some modifications to the GNB structure were performed to accom-
modate the AIS sensor and its VHF antenna, but the internal hardware remains the same as
GNB. AISSAT-1 was launched and confirmed healthy on July 12, 2010.
Chapter 2
Generic Nanosatellite Bus Ground
Control Application
Generic Nanosatellite Bus Ground Control (GNBControl) is, in a broad view, a client appli-
cation designed to allow its users to compose command packets in the NanoSatellite Protocol
(NSP) format and send it to a target satellite. For the purpose of the GNB design, GNBControl
is a semi-automated application used by the operators at the ground station to command any
GNB satellites. As a successor to NICE, GNBControl is coded such that it offers much greater
flexibility to modify parameters available in each packet, a necessary step in order to support
the multitude of satellite missions using the GNB platform without changing the source code
of the application.
GNBControl is also a much more complete and complex application in comparison to NICE,
a testament to much more advanced capabilities of the GNB’s various subsystems. In this chap-
ter, design and implementation details for GNBControl’s various subsystem control interfaces
are discussed alongside its main requirements, design principles and underlying implementation.
A quick note: There is no testing process dedicated to GNBControl, because any testing
of GNBControl’s functionalities is tied directly to corresponding devices. This is in fact true
for all ground software functionalities. Thus, ground control applications rely on each device’s
unit level and system level testing to test their functionalities as well. For a sample testing plan
document, refer to GNB LFFT Test Procedure [8].
6
Chapter 2. Generic Nanosatellite Bus Ground Control Application 7
GNBControl took around a year’s worth of development time to mature. It is currently in
service as a testing interface for various devices and testing procedures.
2.1 Requirements
GNBControl’s requirements are defined under the BRITE and CanX-4/CanX-5 Ground Seg-
ment Software Architectural Requirements [9], in two particular sections: Section 6.1 and
Section 7.4. In Section 6.1, general requirements for any ground segment software for the
GNB are listed, setting a baseline in which all GNB ground segment software must adhere to.
In Section 7.4, requirements specific to Spacecraft Control - a ground control application, or
more specifically, GNBControl - are defined. Table 2.1 lists choice requirements from these two
sections.
Generic Nanosatellite Bus Requirements
GSS-SYS-1 Both missions (CanX-4/-5 and BRITE) shall use a common ground station
architecture on identical ground station hardware. Mission specific opera-
tions shall be performed by mission-specific software.
GSS-SYS-6 Each ground station program shall communicate with other programs over
a Transmission Control Protocol / Internet Protocol (TCP/IP) Socket.
GSS-SYS-7 Communication over the TCP/IP socket shall consist of Serial Line Internet
Protocol (SLIP) - framed NSP packets.
GSS-SYS-8 Each TCP/IP socket shall be encrypted using Secure Socket Layer (SSL).
GSS-SYS-9 Each program connecting to another shall require a login consisting of a
username and password. The recipient program shall have an authorized
list of which users may connect.
GSS-SYS-10 The ground station software shall include sufficient automation to allow a
single operator to perform all necessary operations during any given pass.
GSS-SYS-11 The ground station shall allow for automated communication and data re-
trieval during unattended passes.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 8
GSS-SYS-12 All ground station software shall maintain a log of issued commands, received
responses, and telemetry.
Spacecraft Control Requirements
GSS-Control-1 Spacecraft Control Application shall be able to issue commands in real-
time to BRITE, CanX-4, and CanX-5 to control the Housekeeping Com-
puter (HKC), the Attitude Determination Control Computer (ADCC) and
its subsystems.
GSS-Control-4 Spacecraft Control shall be able to upload and execute new software to any
of the NSP-enabled devices on the GNB.
GSS-Control-5 Spacecraft Control shall be able to poll one or more telemetry points in real
time, at specified intervals.
GSS-Control-6 Spacecraft Control shall log all telemetry received to a user-defined file, in
Comma-Separated Values (CSV) format.
GSS-Control-7 Spacecraft Control shall be able to command and query the Attitude Deter-
mination Control System and the subsystems connected to the ADCC.
GSS-Control-8 Spacecraft Control shall be able to upload new Two-Line Elements (TLEs)
to the ADCC if required.
Table 2.1: GNBControl Requirements
GSS-SYS-1 reaffirms the purpose of the GNB platform as a reusable design spanning multi-
ple missions. GNBControl must be designed to allow this as well, implicitly demanding a mea-
sure of customizability built into it. However, this requirement also states that mission-specific
operations shall be performed by mission-specific applications, assuring that GNBControl is
only expected to provide control interface for hardware common to the GNB platform.
However, GSS-Control-1 then states that all subsystems of the HKC and the ADCC be con-
trollable. This statement, after several discussions with the project lead, has been interpreted
as “Any subsystem connected to the HKC or the ADCC”. As the two On-Board-Computers
Chapter 2. Generic Nanosatellite Bus Ground Control Application 9
(OBCs) have access to all non-payload-related components within the satellite, the requirement
is specifying that all components of the satellite be controllable through Spacecraft Control.
Note that GSS-Control-4, 5, 7 and 8 are all sub-requirements of GSS-Control-1.
GSS-SYS-6, 7, 8 and 9 specifies how GNBControl will need to communicate with other
applications. On the previous ground station setup, NICE and TIP used an encrypted TCP/IP
connection to communicate with each other. Similar architecture is used for GNB platform as
well: all generated packets from GNBControl and the subsequent replies from the satellite will
pass through a server named Multiplexer (MUX). Hence, GNBControl and MUX can use the
code that already exists for NICE and TIP to also establish an encrypted TCP/IP connection
to communicate with each other.
GSS-SYS-10 and 11 specifies a need for automation such that either the pass can be managed
by a single operator, or if the pass is unattended, the basic data retrieval can be performed. On
NICE, any standard non-telemetry data retrieval must be initiated by an operator, interrupting
his or her flow of work. Similarly, a human operator often becomes the limiting factor in a typical
satellite operation due to time wasted on a data entry that is predefined yet must be input in
real-time to the control interface. These requirements can be seen as an effort to lessen these
issues to make better use of valuable satellite contact and operator time.
GSS-SYS-12 specifies that logs of sent commands, received responses and telemetry be kept
and GSS-Control-7 goes further to specify that the logs be kept in CSV format. These two
requirements serve as a basis for GNBControl’s logging mechanism.
2.2 Overall Design Principle
Software requirements of the GNB platform specify GNBControl to be versatile enough to
offer complete control over all satellite hardware and support usage on multiple missions, yet
allow one operator to perform all necessary operations without being swamped by vast array
of options available to him or her. Thus, the design provides a solution within the application
that allows operators to plan ahead various actions to be taken during the operation, while
simultaneously displaying relevant information and command interface to the operator.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 10
An effort to reuse and adapt the already-existing codes from NICE has been made. To this
end, GNBControl uses the Microsoft Visual C++ compiler as the main compiler for the code
and the Microsoft Foundation Class (MFC) library for the interface. It also makes extensive
use of functions written for NICE. Some changes have been made to the code to accommodate
new designs or fix persistent bugs from the old design.
2.2.1 Queue Class
The idea of a queue has been present since the dawn of time, and an entire discipline of research
called Queuing Theory has been created to study queues in a mathematical manner. In the
case of computer programming, a queue is a data structure defined as a collection of items in
which only the earliest added item may be accessed [10]. Sometimes known as First-In-First-
Out (FIFO) data structure, a queue in this context serves as a data buffer, a region of memory
used to temporarily hold the data before being moving it to another location.
In the case of GNBControl, the idea of a queue is used for storing unspecified number of
user-provided commands at any time in its buffer, until the satellite is in view of the station,
signalling the start of a satellite pass. The queue then can be accessed by GNBControl in FIFO
manner, sending commands to the satellite in the order initially specified by the operator. The
idea is to allow the operator to schedule sequential set of commands well in advance of the pass
at his or her leisure, which then can be sent to the satellite in an autonomous fashion.
The main advantage of this scheme over one without a queue is that a significant portion
of the operator’s time can be freed for other tasks at hand. This can be shown by using two
sequential diagrams of a typical satellite pass, one without using a queue scheme and one with
it. For the purpose of this section, the operator’s time is defined as toperator, time in which the
operator is attending the operation, or the sum of the time between the first command by the
operator and the last response displayed in the interface.
Figure 2.1 describes a typical satellite pass that does not use a queue scheme. Initially,
the operator inputs a command via provided interface, taking top delay s 1 to complete the task.
This inputted command must then be processed before being sent to the satellite, which is
shown on the figure by moving from the Interface to the Application Internals, with a delay
Chapter 2. Generic Nanosatellite Bus Ground Control Application 11
of tapp proc s 1. Once processed, the command is then sent from the application to the satellite,
incurring additional delay of ttmdelay s 1 during transmission. The received command must be
processed by the on-board hardware of the satellite, taking tsat proc 1 to comply. The execution
of the command must be relayed back to the user at the ground station terminal. This involves
relaying the response from the satellite to the application (ttmdelay r 1), process it (tapp proc s 1),
then display it to the user who will read and interpret the data (top delay r 1). The sum of the
above-described sequence corresponds to time in which the operator sends and successfully
receives a response to a command to the satellite, tcmd 1.
An operation consists of multiple commands that must be sent and its response received to
verify the execution of command. Let each time term without the subscripts s and r represent
the sum of both (for example top delay 1 = top delay s 1 + top delay r 1). Also let n represent the total
number of commands in an operation. Hence, when the operator is sending commands to the
satellite in real time without using a queue scheme, toperator can be calculated as below:
toperator =n∑
k=1
tcmd k
=n∑
k=1
(top delay k + tapp proc k + ttmdelay k + tsat proc k)
The sequence described above is changed when a queue is introduced, as seen in Figure 2.2.
The command input by the user and its processing still incurs the time delay (top delay s 1 and
tapp proc s 1) , but once the command is processed, it is not immediately sent to the satellite.
Instead, the command is stored in the application’s command queue, after which the user
is notified of the fact (tapp proc r 1 and top delay r 1). The total delay accrued in this sequence
corresponds to the amount of operator time required to add one command into the command
queue, toperator cmd 1. Hence, the equation to find toperator is changed as follows:
toperator =
n∑k=1
toperator cmd k
=n∑
k=1
(top delay k + tapp proc k)
Removal of ttmdelay in toperator is particularly significant, because ttmdelay can easily become
the dominating factor in a typical pass due to unstable uplink or downlink with the satellite. A
Chapter 2. Generic Nanosatellite Bus Ground Control Application 12
Figure 2.1: Sequential Diagram for a Typical Satellite Pass without a Queue.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 13
Figure 2.2: Sequential Diagram for a Typical Satellite Pass with a Queue.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 14
satellite pass can be completely dominated by transmission delay due to unstable connection,
resulting in significant waste of operator’s time without contributing to the mission if the
operator were to perform the pass without a queue. Storing the set of commands in a queue
instead allows the operation to continue on its own during the next stable pass with minimal
monitoring, allowing the operator to avoid time loss resulting from the transmission delay.
Another valuable asset of a satellite operation is the satellite’s pass time, during which
satellite operations can be performed. If the number of up/downlink stations available for the
satellite is limited, as is the case for SFL’s nanosatellites, visibility of the satellite is limited by
the function of satellite’s orbital parameters and the available station’s coverage.
The required pass time to perform a particular operation can be described as a combination
of commands sent to the satellite and responses received from the satellite for the operation.
Thus, total time required to perform an operation can be defined as the time between the first
command sent to the satellite to the last response received from the satellite, which is the same
definition used previously to calculate toperator. Defining this time as tcontact, the amount of
time required to perform an operation when not using a queue is:
tcontact = toperator =
n∑k=1
tcmd k
=
n∑k=1
(top delay k + tapp proc k + ttmdelay k + tsat proc k)
The operation time is changed significantly when a queue is used. As seen in Figure 2.2, a
major difference in an operation sequence when a queue is introduced is that the application
simply accesses the already-processed commands and sends it to the satellite (ttmdelay r 1), in-
stead of waiting on and processing inputs from the user. The satellite processes the received
command (tsat proc 1) then sends back a response to the ground station (ttmdelay r 1). While the
application can then process the received packets, it can also send its next command in queue
immediately after receiving the response and repeating the above sequence. Defining a sequence
of the above as tcontact cmd 1, an equation for tcontact can be formulated:
tcontact =
n∑k=1
tcontact cmd k
=
n∑k=1
(ttmdelay k + tsat proc k)
Chapter 2. Generic Nanosatellite Bus Ground Control Application 15
Adding this tcontact to toperator when using a queue results in the equation for toperator when
not using a queue. Effectively, the time required to perform an operation has been split into
a part dedicated to operators issuing commands and another part dedicated to applications
transmitting data to and from the ground station. Whereas the previous scheme caused both
the operator and the applications to be delayed due to each other as each command was sent
and received, the queue scheme allows for strict time-wise separation between the two, resulting
in greater available time for both the operator and the operation.
2.2.2 Threaded Classes
It has been stated in the previous section that a queue will store an unspecified number of items
given by the operator at any time. This statement must hold true for commands being issued by
the operator during a satellite pass, where other commands previously queued by the operator
may be being sent and its responses processed. This was never an issue under the previous
design because the operator was forced to wait for the issued command to be sent to the satellite
and then its responses processed before being allowed to send another command. In the current
scheme however, the queue and the interface must be able to function simultaneously, receiving
commands through the interface while also processing responses from the satellite.
This can be implemented with the use of threaded classes. A thread in programming is
defined as an independent stream of instructions that can be scheduled to run as such by the
operating system [11]. Each thread, having a set of instructions it wants to execute, receives a
slice of processor time to perform the instructions, and when the time slot expires or when the
thread begins waiting for an external process to finish, the processor saves the thread’s progress
before moving onto another thread.
The following example attempts to clarify how a thread works: consider a fast food worker,
working alone at a burger joint, surrounded by a drink fountain, a deep fryer, a burger grill
and a cash register. The worker can start the drink fountain and wait until the cup is full, then
move onto the deep fryer and cook up a bag of fries, and then cook up a burger at the grill,
finishing up by taking all these to the front, giving it to the impatient customer and ringing up
the bill. This can be described as a non-threaded operation.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 16
Instead, consider how a fast food worker at a burger joint usually works. He or she would
start the deep fryer and the burger grill long before the customer arrives, for one. Then, when
the customer arrives and makes an order, he or she would start up the drink fountain, but then
would move right to other tasks at hand. He or she rings up the bill, picks up the already-cooked
burger and fries before returning shortly to place them in front of the customer. By then the
drink fountain has filled the cup, which is subsequently given to the customer as well. This is
how a typical threaded operation works, where the drink fountain, the deep fryer, the burger
grill and the cash register are all threads and the fast food worker is the processor.
A Threaded class encapsulates a thread and its instructions as well as providing external
means to initialize it and access the results produced by the thread. Several threaded classes
can operate asynchronously, providing a slice of processor time to each threaded class as needed.
In case of GNBControl, this allows a class dedicated to receiving packets from the satellite to
listen for responses, another to handle the queue operations and yet another to accept operator
inputs at the same time. Note that threads bring some inherent dangers to the application, such
as race conditions due to two or more threads accessing the same set of resources and thread
deadlocks due to resource protection mechanisms. However, careful management of resources
allows both issues to be avoided entirely.
2.2.3 Persistent, Customizable Command Script
During operation, there are cases where a particular set of operations will be repeated with
little or no changes to the user-inputted parameters. While the measure taken by implementing
a queue class theoretically reduces operator’s time using the interface, the reality is that many
real-life operations tend to require the operator at hand to make decisions based on the telemetry
gathered. When this happens, the time advantage of having a queue may disappear entirely.
To mitigate this issue, a command script can be used. The command script is essentially
a file containing a set of commands that both the operator and the application can read. The
script can be tailored for parts of operations where a set of commands must be sent before any
human decisions are made. For example, a typical CanX-2 operation is as follows: upload an
experiment, set Attitude Control Subystem (ACS) settings for instrument pointing, schedule
Chapter 2. Generic Nanosatellite Bus Ground Control Application 17
an experiment based on the experiment’s execution time and then send a clock synchronization
command. Here, uploading an experiment and setting the ACS settings can be lumped together
into a script file well prior to the operation and loaded when the operation begins, after which
the operator schedules the experiment and sends a clock synchronization command manually.
The same script can be reused for the same type of experiments, thereby saving a significant
amount of operator time and also saving the operation time indirectly by removing the operator
element of the operation time, as pointed out in Section 2.2.1.
In addition, GNBControl itself should have the capability to edit a command script, so that
the operator can create, edit and then save a script file on the fly. Ideally, creating a script
should follow the same set of actions that the operator would take during an operation, so that
any learning time required to create a script is mostly eliminated. Similarly, the script itself
should be fairly easy to read, in case some script editing is required without using GNBControl.
This also implies that GNBControl should ideally be robust against typos that may exist within
the script, since human-generated scripts are often riddled with typos.
2.2.4 Achieving Flexibility
One of the greatest changes to be brought by GNBControl is its ability to cater to multiple
missions. It was already mentioned before that two different code bases had to be kept for
NICE, one each for CanX-2 and NTS, two currently on-orbit missions for SFL. This is very
inconvenient as each new mission requires a section of the depository space dedicated to the
ground software source code, and any code maintenance done to one code must be manually
propagated to others as well. There is a great desire to avoid this, and a fair amount of code
flexibility is required for this purpose.
Fortunately, apart from the payload, most of the satellite subsystems such as the On-Board
Computers (OBCs), Power, the Attitude Determination and Control Subsystem (ADCS) and
the Communications Subsystem are not expected to change for the GNB platform. The pa-
rameters within the command format such as the address of a device or a sequence of telemetry
variables may change, but the structural format of the command that contains these parameters
and sequences will remain relatively fixed as defined by the Interface Control Document (ICD).
Chapter 2. Generic Nanosatellite Bus Ground Control Application 18
Thus, the focus will be on being able to freely change these parameters via means of config-
urations files and application-based options menu. Since the structure of the command remains
constant, the functions can be written such that the parameter placements will remain con-
stant throughout the lifetime of the application, while the parameter values will be changing
based on user inputs and configuration values. The overall result is that while each command
can be tailored to a specific satellite via changes in the configuration parameters, the func-
tions handling the creation of these commands will be simpler to implement than that of a
case where the entire structure of the command is prone to change from mission to mission.
In contrast, the complexity of a packet-generating functions for commands requiring user in-
puts and satellite-specific parameters from the configuration file will only be slightly more than
those only requiring user inputs and satellite-specific parameters hard-coded - written such that
only a recompile of the application can change those values. This is because when writing the
function, a hard-coded value is written no different from a variable containing the same value.
The added complexity comes from retrieving the configuration parameter from where it resides.
Thus, with minimal loss to the development time per additional function, support for multiple
missions can be realized.
However, all of the above is based on the assumption that there is a way for the user to
change the non-user parameter values without major changes to the application. Thus an
inherent overhead of implementing an application-wide configuration system that manages all
of the parameter values exists. This is a one-time development cost to be paid up front, which
is hopefully more cost effective than developing and maintaining new ground control software
with each new mission. The line of reasoning was no longer pursued at this point as one of the
more explicit requirements for GNB platform was that spacecraft control software be able to
command two distinct missions on GNB (BRITE and CanX-4/5 mission), thus a measure of
flexibility was inherently required.
2.2.5 Information Tracking
Times available to the ground station for contact with the satellite in orbit are limited, and
operators require quick access to various types of information the control software can provide.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 19
On the most basic level, it would be beneficial to see the most recent command sent to the
satellite, as well as the subsequent reply received and decoded from the satellite. Keeping a list
of commands sent and received in sequence order is also beneficial for the long term operation,
allowing the operators to provide reasonable assessment of the current situation and react based
on the assessment to continue the operation as needed. The information gathered should also
be separable from one subsystem to another, to reduce the hassle of manual categorization
by human hands. At the lowest level, it may be advantageous to show the raw data stream
between the application and the satellite, for the sake of quickly verifying data to and from the
satellite in case of abnormal operational behaviour of the application itself.
Apart from information tracking in general, it is good to keep in mind that this application
also has a queue. There should be a method to display commands currently within the queue,
so that the operator can see what set of commands will be sent to the satellite during the
upcoming passes and can make changes to it as needed.
Most important of all, a log should exist outside of the application. It would record the
same information viewable to the user while the application is running, which should contain all
information on telemetry received as well. As well, requirements explicitly stated the log files are
of .csv format, fixing the choice and the method of logging. Thus, most of the implementation
details for information logging will depend upon what and how the information is displayed.
2.2.6 Subsystem/Device Interface Management
In GNB, numerous communicable subsystems and devices exist, which all must be controllable
by GNBControl as per the requirement. One could potentially display all available commands
in a single interface window, but this scheme will be confusing and hard to navigate for the
operators. Not only that, such implementation would create a massive class containing process-
ing details of numerous packets, becoming quickly unmanageable as it grows proportional to
each new command it needs to process. As well, depending on its mission requirements, not all
subsystems may exist on a particular satellite, rendering some parts of the interface misleading
in terms of the satellite’s capabilities. It is reasonable to assume that only a subset of the
satellite’s capabilities will be needed for each operation. Thus, the interface should be designed
Chapter 2. Generic Nanosatellite Bus Ground Control Application 20
such that a significant portion of GNBControl’s capability is hidden by only displaying part of
the interface that is relevant to the current operation.
Each subsystem also comes with its own sets of parameters that may change with each
mission, and these parameters can quickly become unmanageable if each subsystem has its own
unique way of storing the parameters. Instead, by using standardized lists to store multiple pa-
rameters, each subsystem can have any number of parameters without taxing the infrastructure
established for handling the configuration settings.
Many of the subsystems may have functionalities closely resembling each other in terms of
control - for example, most flight software will come with a Ping command to allow a quick
state check of the device. A manner of standardization to handle these common functions across
different devices will lessen the development and maintenance time for GNBControl.
2.3 Main Architectural Implementation
While GNBControl’s main purpose is to command various subsystems and devices available
on-board the satellite, a significant amount of time was allocated to create an application
following an object-oriented design principle. The majority of the implementation details given
here are specific to GNBControl as a core application, while various subsystems are treated as
“unknown” objects and remain mostly unmentioned here. Implementation of subsystem/device
functionalities available on GNBControl are described in detail on the next section.
Making use of the object-oriented nature of the C++ programming language, classes are
used to separate different functionalities in GNBControl. A class is an expanded concept of a
data structure: instead of holding only data, it can hold data and functions. An instance of a
class is called an object [12]. Functions in a class can only be used when the function’s caller
has knowledge of the class. This creates a relationship model where a set of classes or objects
can be arranged in an inter-connected block diagram to describe its architecture. The general
architecture of GNBControl resembles a tree structure when arranged in this fashion, as seen on
Figure 2.3. It is divided into five major sections: GNBControl Root Interface, Queue Control,
Packet Handler, History Logger and Options, their blocks highlighted in bold.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 21
Figure 2.3: Block Diagram of GNBControl Architecture.
The application begins with a single root interface class, containing the most basic function-
alities of an interface: a window to look at and buttons to click on. These buttons and windows
are associated with several other classes created by the root class, each performing specific
pre-defined tasks. In Figure 2.3, this is represented by lines connecting the GNBControl Root
Interface block with various other blocks, with a diamond shape on the root interface block.
These child classes created by the root also branches out by creating their child classes that also
perform specific tasks. An example of this is the TIP Socket class, which is created by Queue
Control class, but Queue Control itself is created by GNBControl Root Interface class. Though
Chapter 2. Generic Nanosatellite Bus Ground Control Application 22
not shown in Figure 2.3, TIP Socket class also has its own child branch, and other classes in
GNBControl are similarly branched to modularize and reuse functionalities in the application.
While the parent class retains knowledge about its child classes, each child class has no
knowledge of its siblings or the parent class, to enforce each class to be modular and reduce
dependency on its parent or sibling classes. To facilitate communication between these classes,
message handler classes are established between two classes that needs two-way communication.
In Figure 2.3, this is demonstrated by the dotted lines of many classes to the Message Handler
class, which has access to the root interface class.
GNBControl’s Root Interface uses the Microsoft Foundation Class (MFC) library’s CDialog
interface class to create an interface window via a simple-to-use dialog editor, details of which
can be found on the Microsoft Developer Network [13]. The root interface also serves as the
application’s root class, acting as a parent class to other classes used on the application. It
also processes the most generic and often-used commands, Ping and Clock Synchronization
commands, for the convenience of the button placement on the interface. Figure 2.4 shows a
screen capture of the root interface window.
One of the major quirks of the root interface is the abundance of child interface classes in it.
The sheer screen size required to display all commands that need to be available on GNBControl
is too great to be displayed on a single interface window. So instead, GNBControl’s root
interface class provides a tab control object which can be used to select a particular subsystem
that the operators wants to use. The root interface displays the selected subsystem interface
within the pre-defined space. Queue and History interfaces are grouped together in this fashion
on the top right corner, while all subsystem interfaces are located at the bottom half.
Queue Control is both an interface for managing queued items and a class for processing
queue-related jobs. GNBControl’s queue control displays its contents with an arranged list
control class called CListCtrl from the MFC library, a type of object that a programmer can
interact with to enter in or manipulate data to be displayed in a convenient fashion [14]. The
queue also employs several instances of counting semaphores to prevent possible race conditions
created by multiple threads accessing the queue simultaneously. Initial design of GNBControl
had multiple instances of Queue Control, one for each OBC on board the satellite, but this
Chapter 2. Generic Nanosatellite Bus Ground Control Application 23
Figure 2.4: GNBControl Root Interface Screen.
design was quickly abandoned once it became clear that all packet traffic will be directed
through one designated OBC. Figure 2.5 shows a screen capture of the queue interface shown
to the user.
The two Packet Handler classes, Packet Sender and Packet Receiver are used to send and
receive packets to and from the satellite, respectively. Both use the MFC library’s CWinThread
class, which allows both Packet Sender and Packet Receiver to be initialized as a threaded class.
As explained previously on Section 2.2.2, using threads allows the processor to switch from one
task or another as packets become available.
History section has two classes associated with it: History Logger for displaying and logging
history and Packet Display for displaying raw packets. History Logger is used to display and log
any meaningful actions within the application, such as sending and receiving packets. Similarly,
Packet Display is used to display all traffic from and to the application via sending and receiving
of packets. History Logger is known by most of the subsystem interface classes as well as the
Chapter 2. Generic Nanosatellite Bus Ground Control Application 24
Figure 2.5: GNBControl Queue Interface Screen.
queue control and the packet handler classes so that these classes can send information on
actions taken. Packet Display on the other hand only has connections established with the
packet handler classes, which provides Packet Display with raw packet data to decrypt and
display. Figure 2.6 shows the interface for History Logger and Packet Display respectively.
Figure 2.6: GNBControl History Logger and Packet Display Interface Screen.
The Options section is comprised of several different classes. Three important classes are
Options Interface, Options List and XML Configuration Storage. Options Interface is the
Chapter 2. Generic Nanosatellite Bus Ground Control Application 25
central class for all other classes directly related to options section, handling tasks such as ini-
tializing and propagating configuration parameters, creating instances of other options-related
classes and establishing an organized method to browse through all existing configurations.
Options List is a generic class used to display and provide a way for users to modify long lists
of configuration parameters. XML Configuration Storage is used to save and load configuration
parameters as an Extensible Mark-up Language (XML). Other classes created by the options
interface are mainly for displaying configuration parameters specific to a particular subsystem
but do not fit the list format used by Options List. Figure 2.7 is a small portion of the options
interface, showing Options Interface’s tree-like selection list and Options Interface’s parameter
configuration list.
Figure 2.7: GNBControl Options Interface Screen.
The following subsections describe in detail the major implementation issues and features
on GNBControl’s main architecture.
2.3.1 Intra-Application Message Queue
GNBControl’s root interface performs a much greater amount of data processing than other
interface classes in the application. It is the only class with access to Packet Receiver and other
subsystem classes; hence all of the received packets must first pass through the root interface
to get to the appropriate subsystem interface. As well, classes initialized in the root interface
have no knowledge of each other to keep each subsystem separate and prevent deadlocks, thus
any communication between these classes must be directed through the root interface.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 26
To manage the flow of intra-application communication, a Message Queue is utilized. A
message queue is a queue containing messages from other classes with a predefined, unique
identification, and is a part of a class using the MFC library’s CDialog class or CWinThread
class. A class containing a message queue also has a message loop, which is a process that
periodically looks at the message queue and dispatches messages to the respective processing
function based on the previously-mentioned identification. See [15] for more details on how
messages and message queues work in CDialog and CWinThread classes.
However, since classes do not know each other in GNBControl, messages cannot be ex-
changed under normal circumstances. This limitation is circumvented by introducing a Message
Handler class. A message handler is initially generated by a parent class - referring back to
Figure 2.3, this is the GNBControl Root Interface. The message handler is manually given the
knowledge of its parent, but in such a fashion that other classes knowing the message handler
cannot directly access this parent class through it. The message handler also contains a function
that allows other classes to send a message to the message handler’s parent class.
Hence, the parent class creates an instance of the message handler, and then makes it known
to other child classes that need to send messages to the parent class. The child classes can then
send any number of messages to the message handler, which the message handler directs to
the message queue of its parent. Once the message is in the parent class’ message queue, the
message loop eventually dispatches the message to the designated processing function based on
its unique identifier and the parent class can safely process the received message.
Note that if there is no handler for a particular message, then the message can remain in
the queue indefinitely without adverse effects since the message loop will see that the unique
identifier of the said message matches no known message processing function and will not
dispatch it anywhere. Also note that while the words “parent” and “child” were used to
describe the relationship between the classes connected by the message handler, it can facilitate
communication between two classes that have no direct relationship to each other by means of
traversing a tree - a class can pass a message up to the common root class of the two relevant
classes by using a message handler, and then the root class can send the message down the
branch of the other class.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 27
A separation between the parent class and its child classes are achieved, yet they are able to
communicate with each other. This allows both the child and the parent classes to be swapped
and changed with a lighter or more specialized class befitting any situation without disturbing
the overall architecture, providing great flexibility for any future development.
2.3.2 Packet Storage and Routing
Storing packets not only requires memory spaces to keep the packets in, but also direct or
indirect connections to other classes in the application that generates those packets in the first
place so that they can be sent to the storage. It also needs a connection to a class that is
able to direct the stored packets to the satellite. For this reason, all subsystem classes have
knowledge of Queue Control and can talk to it directly, while Queue Control is able to access
Packet Sender class to send out its packets to the satellite.
The actual routing of the packets to the satellite is done by a router application called
MUX, which uses the TCP/IP protocol to connect with various control applications at the
ground station. GNBControl also connects to MUX to send its packets to the satellite. This
connection procedure is handled by the TIP Socket class. TIP Socket was originally a class
containing the connection procedure for TIP, which is essentially a predecessor to MUX and
already in service on the existing ground station at SFL.
Initially, GNBControl was to have two connections to MUX established, one for sending
and another for receiving, hence two classes, Packet Sender and Packet Receiver were added
to the design. Further inquiry about MUX was made during development and it was found
that MUX only allows one connection per application and both the sending and the receiving of
packets must occur under it, hence one class had to handle both the sending and the receiving of
packets. Packet Sender and Packet Receiver classes were kept because it was mostly-developed
at that point. Instead, TIP Socket was given to Packet Sender to ensure that commands being
sent always were given priority over packets being received, and a redirecting mechanism that
redirects any received packets in TIP Socket to Packet Receiver was created in Packet Sender.
The packet sending sequence, as seen in Figure 2.8, can be described as follows: the user
enters inputs to the interface and then presses the send button, which the UI thread reacts by
Chapter 2. Generic Nanosatellite Bus Ground Control Application 28
processing the user inputs and creating a packet. This packet is then sent to the queue control
via a message handler described in Section 2.3.1. The queue control’s message loop dispatches
the message containing the packet to the appropriate function, which sends the packet to the
send queue and notifies the packet sender of the new packet that was received. The packet
sender, when available, then takes the packet out from the queue (represented by the dotted-
line), applies encodings to it and then sends it to MUX using the TIP socket it owns. Note that
the packet is still within the queue at this point, in case the packet is lost during transmission
to the satellite and must be resent.
Figure 2.8: Flow Diagram for Processing Packets to be Sent in GNBControl.
The send queue is a custom-made doubly-linked queue class with pop, push, insert and
remove functions available for other classes to use. This class was written because the initial
belief was that C++’s standard vector library was not sufficient for what was required from
GNBControl’s queue. However, some experimentation has proven that this is not the case.
More on this is detailed in Section 3.3.1.
The send queue resides in the packet sender instead of the queue control, because this allows
the packet sender to have direct access to the send queue without having direct knowledge of
the queue control. The packet sender, when notified by the application’s internal timer, can
Chapter 2. Generic Nanosatellite Bus Ground Control Application 29
vie for access of the queue immediately as opposed to waitng for the queue control to respond.
The packet sender provides a function that the queue control can use to access the send queue.
The procedure for receiving packets is slightly more complicated, as seen in Figure 2.9. As
stated before, the packet sender owns the TIP socket and received messages must go through
the packet sender due to this fact. To allow faster processing of packets, when a new stream
of data from the satellite is received by the TIP socket, it simply copies the received data to a
preexisting buffer in the memory and sends a message to the packet sender with the information
on size and location of the packet within the buffer. This message is redirected by the packet
sender to the packet receiver using the message handler. The packet receiver, when its message
loop dispatches the message, processes the packet by decoding and formatting the data stream
into an expected packet format. The packet is then sent to the receive queue.
Once all of the above is done, the packet receiver sends a message to the root interface (using
the message handler/loop), notifying it that its receive queue now contains packets that need
to be processed. The root interface then removes the packet from the receive queue, processes
it to figure out which subsystem it belongs to, and directs it to the appropriate subsystem for
further processing. At the end of all processing, the root interface destroys the received packet
as a part of the garbage collection process of the application.
While both the receiving and the sending procedures are somewhat convoluted, this setup
is highly likely to be free of deadlocks. The majority of communications are performed by
the message handlers, often forcing classes to create a duplicate of the existing resource before
sending them to another class for processing. The queue is the only resource that can be accessed
by more than one class as it stands; hence one of the four necessary deadlock conditions - circular
wait condition, where two or more classes form a circular chain of waiting on resources locked
down by the next class in the chain - cannot occur.
2.3.3 Queue Script
As mentioned previously during design, command script functionality is desired to minimize
operation time. The Queue Control not only handles functions related to queue, but it also
handles saving and loading of scripted set of commands into and out of the queue. As seen
Chapter 2. Generic Nanosatellite Bus Ground Control Application 30
Figure 2.9: Flow Diagram for Receiving and Processing Packets in GNBControl.
previously in Figure 2.5, two buttons, Save and Load, exist. The save button allows operators
to create a command script file from the current content of the send queue, while the load
button allows operators to load a pre-made command script file to the send queue.
When a subsystem window creates a new command packet based on the user input, it also
creates a command script, a string containing a pre-defined set of keywords that GNBControl
- or a human with knowledge of the keywords - can translate into the command that was just
created with it. This script is saved in a command script queue, which is separate from the
packet queue. Hence, when a command script file is created, the set of keywords that form the
content of the file contains information about the current content of the send queue, which can
then be loaded and decoded by GNBControl to replicate that content whenever desired.
The command script queue is separate from the packet queue because the send queue is
not part of the queue control. The send queue is a part of the packet sender, so it takes time
Chapter 2. Generic Nanosatellite Bus Ground Control Application 31
to access it. Since the packet sender does not need the command script for its operation, the
command script queue is established as a part of the queue control to enable faster access to it
when saving its contents to a file.
Each command script contains enough information to specify what subsystem the command
belongs to. Hence, when loading a new script, each line on the loaded file can be attributed to
a particular subsystem on GNBControl. The line is sent back to the correct subsystem window
in its original form, which it can process as needed.
2.3.4 Managing and Displaying History
Receiving and logging information about the application is always useful for future references,
and History Logger class provides an interface for displaying and processing history entries from
various classes in GNBControl. A majority of entries inputted into History Logger class is from
the queue control, which sends out a new history entry for each attempt to send a packet. All
history entries are displayed in the list control interface in the order of entry generation.
The list control interface has the following fields: Date and Time of the entry received, From,
To, Command, Details, Destination dialog, Command mode and Number of retries. From, To
and Command are fields specific to packets being sent and received by GNBControl. All three
of these fields are given to the History class in a byte-form due to the aforementioned issue, so it
uses the information received from the options list to cross-reference the byte-forms and convert
them into a human-readable - readable by users with minimal knowledge of the programming
language - string output. If the entry does not involve particular destinations or commands
and instead is an internal message, SYSTEM keyword is used on the Command field. Figure
2.6 from the previous subsection shows a set of sample entries on the History class interface.
Details are additional information about the action, provided by the entry provider. Des-
tination dialog denotes this provider - one of the many subsystem windows in GNBControl.
This is the same value used by the root interface to determine which subsystem window the
packet belongs to. Command mode is the current mode the application is in, which determines
the various subsystem interfaces available to the user and changes some parameters to correctly
reflect the mode. This is further discussed in more details on Section 2.4.1. Finally, the Number
Chapter 2. Generic Nanosatellite Bus Ground Control Application 32
of retries is the number of times the same command was repeated in a consecutive fashion. In
History class, this value is incremented every time an entry with the exact same fields is received
consecutively.
The list control object is modified to allow sorting of its elements based on each field type.
The sorting is done at a simple alphanumeric level, where each column of fields is rearranged
from character A to 9 or vice versa when commanded to sort. This mechanism allows the user
to quickly pinpoint a particular set of history entries in the list control as desired.
A CSV format log file is created by History class as well. A new log file is generated when
History class is initialized. To simplify the process, the same information that is displayed to
the operator is recorded on the log file, so each new entry generates a line on the log file. To
allow access to the log file at any time, History class opens the file for writing only when a
new entry is generated and closes it after the entry is inputted into the file, thereby retaining
ownership of the log file only when necessary. If GNBControl is unable to get ownership of the
file because it is open elsewhere, it automatically creates a new log file based on the current
date and time. Similarly, a new log is created when the date changes, so that each log file can
be kept to a manageable size.
2.3.5 Application Options
The sheer number of controllable parameters in GNBControl can easily overwhelm most op-
erators when they are shown at a face value. Regardless of scale, a satellite is still a very
complex system with numerous subsystems that require fine-tuning and minuscule changes
during development and after launch. Add to this fact that GNBControl is planned to support
an unspecified number of satellites, then one can easily imagine that managing parameters for
GNBControl is no trivial matter even for the most seasoned operator. Hence, to hide this
complexity from the operator during an average operation but still ensure that the parameters
are available, Options Interface class is used.
Options Interface is the interface class that the user interacts with to control the application
options. Due to number of options available, it is provided with its own window at the bottom
half of the application that is shown when selected from the subsystems tab control. It uses
Chapter 2. Generic Nanosatellite Bus Ground Control Application 33
its own subset of interface classes that provide fields the operator can edit to control various
parameters throughout GNBControl. Options Interface arranges the classes in a predefined
tree structure, seen in Figure 2.7. Each sub-interface class is displayed on the right when an
appropriate entry is selected from the tree list shown to the left.
Options Interface handles the initialization and propagation of the configuration parameter
values. It keeps an instance of OPTIONS structure. This structure contains all configuration
parameter values in a combination of C variables (integer, unsigned chars), MFC class vari-
ables (strings) and variable-length 2D arrays of string containing any number of related values.
Options Interface initializes this OPTIONS object to a pre-defined default value.
Options Interface can also load and save the configuration to an XML file using XML
Configuration Storage class, an explicitly specific class to GNBControl such that each line of its
load and save function only corresponds to specific parameter value or a list of parameter values.
XML Configuration Storage accepts an OPTIONS object, populating it with values decoded
from the XML configuration file or creating a user-specified XML file based on the OPTIONS
object given. Options Interface uses this class to load its primary default configuration file
config.xml, so that GNBControl is able to have a configuration state that is loaded by default
upon start-up, apart from the configuration state it has when the application is compiled. It is
also possible to state a configuration file path as an execution parameter to further add to the
flexibility of loading a configuration state upon start-up.
Options Interface receives and processes operator inputs as follows: when Options Interface
is first loaded, all its interface windows showing configuration parameter fields are initialized as
well, but hidden from the user’s view. Based on the selection made on the tree structure, the
options interface finds and shows the corresponding window, where the parameter fields can be
changed. The values entered on the field are stored as a part of the window and not as a part
of the OPTIONS object.
When the user saves the changes made by pressing the Apply button, the values stored in
the interface window are pooled by Options Interface, and are used to update the OPTIONS
object. Then it propagates the configuration parameter values to all other subsystems. This
process is described by Figure 2.10. When the options propagation sequence is initiated, Options
Chapter 2. Generic Nanosatellite Bus Ground Control Application 34
Interface first responds by updating its OPTIONS object based on the field entries from its
interface classes. Then, a message containing the memory location of the OPTIONS object
is passed - instead of the OPTIONS object itself, because it is too big to pass around - to
the message queue of the root interface, once again making use of the message handler. The
message loop dispatches the message to the propagation function in the root interface, which
propagates the memory location of the OPTIONS object to all other subsystems that the root
interface knows of. It is up to each subsystem classes to decode and extract useful information
from the OPTIONS object. Note that the root interface also has parameters it stores there, so
it also extracts that information from the OPTIONS object before propagating it.
Figure 2.10: Flow Diagram for Propagation of OPTIONS Object.
The overall process allows Options Interface to remain unmodified when a subsystem class
that makes use of already-existing configuration parameters is added. When a new subsystem
class requires a new set of configuration parameters, some changes are needed to accommodate
the new parameters, but Options Interface still does not require knowledge of the new subsystem
under this setup, keeping its association with other classes in the application simple - only with
the root interface.
Note that when the user selects a different subsystem window and comes back to Options
Interface, all changes are reset to the values stored in the OPTIONS object, to prevent any
Chapter 2. Generic Nanosatellite Bus Ground Control Application 35
confusion regarding the current setting applied. There is no application-wide propagation
involved here, since the OPTIONS object has not been modified. Also note that when Options
Interface is first initialized, it performs the options propagation process so that the subsystems
have the parameter values that they need to function properly.
Options List
As mentioned previously in Section 2.2.6, there is a need for a method to display a long, variable
length list of parameters (the variable-length 2D array of string mentioned previously) within
Options Interface, and creating a class tailored for each list is tedious. Instead, Options List is
used. Options List is an interface class with a modified list control object. It receives a variable
length array containing a configuration parameters list from Options Interface and from it fills
out the list control object. The modified list control allows cell-wise modification of each entry
by simply double clicking the cell and entering in the desired value, as shown in Figure 2.11.
This allows large varieties of configuration parameter lists to be displayed for the operator to
view and modify in a convenient fashion. As well, adding more list-based parameters becomes
much easier as it comes down to simply adding more instances of Options List to Options
Interface.
Figure 2.11: Options List showing ADCS Modes Configuration List being Modified.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 36
2.4 Individual Subsystem Architectural Implementation
There are numerous subsystems on-board the satellite that needs to be controllable from the
ground. As mentioned before, the number of available commands is large enough so that it
would be much cleaner and better organized to provide each subsystem an interface dedicated
to providing control over that subsystem. Hence, GNBControl has numerous subsystem control
interfaces, each directing its commands to a particular subsystem it specializes on. Figure 2.12
shows this relationship.
Figure 2.12: Satellite Subsystems and corresponding GNBControl’s Subsystem Interfaces
GNBControl provides a set of controls for all subsystems by allowing each subsystem to
have an interface window that takes up the bottom half of GNBControl, as seen in Figure 2.13.
All of the subsystem interfaces are arranged into a series of hidden windows overlapped with
each other. Each window is shown based on which tab is currently selected on the tab control.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 37
Figure 2.13: Main Subsystem Interface Window on GNBControl.
The interface windows all use a modified CDialog class called CExtendedDialog, which
allows each window to be moved and docked to any part of the screen as needed, creating
an interface structure that can be modified to suit the operator’s needs. The tab control
and its entries can be modified from the options interface so that some windows are hidden
from the operator. Both of these functionalities are in response to increase in number of
required functionalities from GNBControl over the course of development. There are currently
14 subsystem windows plus the options interface, so up to 15 entries can be on the tab control
at the same time.
For the rest of this section, implementation details on select subsystem windows are dis-
cussed. Others are provided in GNBControl Subsystems Implementation Technical Memo [16].
2.4.1 “Main”
The “Main” subsystem interface is a window built for controlling the bootloader - the most basic
software mode the satellite OBC can be in with minimal commands available - and Canadian
Advanced Nanospace Operating Environment (CANOE) - OBC software “application mode”
that provides full control over the satellite. The main goal is to provide an interface to command
the OBCs, but during development it was noted that many of the devices follow the same
basic format of communication as the OBCs. Currently, it is able to command essentially all
devices on board the satellite, albeit under cruder interface than going through the appropriate
subsystem window. With its capacity as a command interface for the OBCs and any other
Chapter 2. Generic Nanosatellite Bus Ground Control Application 38
devices as needed, the Main interface window is shown as the default window when GNBControl
is first loaded.
The OPTIONS object keeps a large list of commands in configuration, containing human
readable names for commands, corresponding command characters, default destination ad-
dresses and number of binary values denoting which MFC controls in the Main interface to
enable when a command is selected. The Main interface creates its list of commands available
to the user by reading and decoding the parameter list in the OPTIONS object whenever the
options interface propagates it. Other interface dialog classes often rely on this same list to cre-
ate their packets with appropriate command characters and destination addresses. This list of
commands is displayed to the operator via six buttons and a CComboBox control - a dropdown
box control in MFC - as seen in Figure 2.13.
The six buttons on the far left each corresponds to a particular command. The first five
buttons switches the dropdown box to the corresponding command. The “Others..” button on
the bottom enables the dropdown box, providing access to full selection of commands currently
available in the Main interface. Based on the selected command from the dropdown box and
the corresponding configuration, the Main interface enables and disables appropriate parts of
the interface to clarify to users which parameters the particular command can take. Detailed
explanation and usage of various commands available to GNB can be found in the Guide to the
GNB Bootloader [17].
Sending commands to the satellite is quite simple in the Main interface. A generic packet
creation function is able to create an NSP-formatted packet based on configuration parameters
from the options interface and various user inputs in the available fields within the Main interface
window. When the Send button is pressed, the Main interface takes the selected command and
the user inputs from the interface then calls the generic packet creation function to create an
NSP packet with the inputs. The created packet is then sent out to the queue control for
processing.
Receiving commands is not as flexible unfortunately. The current implementation recognizes
a number of OBC-specific commands - such as Peek or Write, have functions implemented to
recognize and decode these commands specifically, and thus have much clearer output at the
Chapter 2. Generic Nanosatellite Bus Ground Control Application 39
end of processing. For any commands without specific processing function, the received reply
goes to a generic packet processing function that simply converts the received packet data to
human-readable array of byte-long hexadecimal values, so that the operator may examine the
contents of the received packet. While this may be sufficient for commands with few bytes of
data in its reply, it is much harder to glean useful information from a reply 260 bytes long.
OBC Switching
There are currently three separate OBCs in a GNB and each OBC can be in a bootloader or
an application mode. Each OBCs mode responds to a particular address - for example, the
HKC in bootloader responds only to address 0x20, while the payload computer in application
mode may respond to all sorts of addresses ranging from 0x40 to higher. As well, each OBC is
slightly different from another, having extra commands or commands that may be interpreted
differently. Due to this, GNBControl must also issue command packets based on the current
mode of the satellite and provide an interface that correctly reflects the current mode. As a
command interface for the OBCs, Main interface is influenced heavily by this.
GNBControl handles this issue by providing a dropdown box containing different modes
GNBControl can be in. Depending on the current mode set, GNBControl switches certain
parameter values to correctly reflect the set of available commands, such as switching addresses
that Ping and Clock Synchronization packets are sent and hiding or showing different tab control
entries. More importantly, the entirety of command list mentioned in the previous section is
replaced based on the current mode GNBControl is in. Modes are definable in the options
interface, as is the list of commands specific to each mode.
The mode switching mechanism is triggered by the set of controls shown in Figure 2.14,
or by receiving a Ping reply, which can be decoded to determine which OBC GNBControl is
talking to and what mode it is in. The root interface gets the OPTIONS object from the options
interface, and propagates it through subsystem classes by calling mode selection function in each
class. Again, it is up to the classes receiving the OPTIONS object to change its parameters to
suit the current OBC and its mode. In case of the Main interface, this is done by switching the
entire command list.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 40
Figure 2.14: OBC Switching Controls.
Note that it is possible to add a mode that has no connection to any particular OBCs. An
experiment or an operation may require the operator to access multiple OBCs, so one can define
a mode with a commands list that contains commands from more than one OBCs, but tailored
such that only the commands that are used for the experiment or operation are present. So
whenever that experiment or operation is planned, GNBControl can be switched to that mode
by the operator manually, so that commands are available regardless of which OBC or software
mode they may belong without having to change from one mode to another.
2.4.2 Attitude Determination and Control System
The ADCS subsystem interface class is dedicated to the application software for the Attitude
Determination Control Computer (ADCC) on board the satellite. Initially the ADCS interface
reused the code that existed in NICE, but with further development of the ADCS subsystem
on board the satellite, GNBControl’s ADCS interface also had to change. The ADCS interface
in current version of GNBControl is much more complex than its predecessor from NICE.
The design goal is to provide a comprehensive control over ADCC’s application software.
ADCS has evolved from CanX-2’s single computer containing all of the HKC, the ADCS and
the payload functionalities, to a three-OBC system with an entire OBC dedicated to the ADCS.
This was done to compensate for the handling of additional devices and operating under stricter
attitude requirements. Consequently, the current ADCS application software for GNB has many
more modifiable parameters than its predecessor.
Figure 2.15 below is the current ADCS interface with the ACS Exchange tab selected. The
control objects in Control Mode static box is used to query or change the current ADCS mode.
The control objects in Special Commands static box is to issue number of ADCS commands
that has no operator parameters, such as resetting the exchange structure (explained below in
ACS Exchange subsection), starting or stopping the control cycle and resetting the software
or hardware. Additions and changes to both the modes and the special commands can be
Chapter 2. Generic Nanosatellite Bus Ground Control Application 41
made in options interface. A list containing name and sub-address/command values for the
mode and the special commands exist in the options interface, which are used to populate the
dropdown box control objects when the ADCS interface is initialized. Packets are appropriately
populated with user inputs / parameters and sent to the queue control when Set/Get Mode or
Send buttons are pressed for these interfaces.
Figure 2.15: ADCS Interface with ACS Exchange.
The ADCS interface has a tab control interface with five different list control objects, each
with a unique functionality specific to a part of the ADCS subsystem. Of these, implementation
details for the ACS Exchange tab are given here.
ACS Exchange
The main feature of the ADCS application software is the existence of the ACS Exchange
structure. As the name suggests, the ACS Exchange structure is the means by which the
Attitude Control System (ACS) exchanges various data and parameters with On-orbit Attitude
SYstem Software (OASYS), which is responsible for various attitude-related calculations on
GNB. This structure is also accessible from ground with an appropriate command, and is in
fact the only way to access some parameters.
Unfortunately, the number of parameters in this structure is massive. Currently around
20 kilobytes worth of parameters are part of this structure. Roughly speaking, this is around
5000 integer values that need to be displayable to the operator on ground. However, the ADCS
application groups the parameters in several blocks of memory as seen in Figure 2.16, where
Chapter 2. Generic Nanosatellite Bus Ground Control Application 42
each block contains a set of parameters with common usage - for example, TLE parameters
are grouped together in a block, while Error parameters are stored in another block. It is
not possible to refer to each parameter in the ACS Exchange structure. Instead, the ADCS
application software keeps a list of memory addresses that specify where each block is located.
Each block, in addition to the memory address, is also associated with a unique eight-byte long
mask that other applications can provide to access the desired ACS Exchange block.
The two examples in Figure 2.16 illustrate briefly of what happens when a read or a write
command is issued to the ACS Exchange structure. When a read command is issued, the ADCS
application first looks at the provided mask value and matches it with the memory address of
the desired parameter in the ACS Exchange structure. Once located, the designated block is
copied to an empty NSP packet. The NSP packet is then sent back to the initial requester of
the read command, and it is up to the receiver to decode the provided block. Similarly, when a
write command is issued, the ADCS again looks at the mask value to find the memory address
of the desired parameter. Then, the data content of the NSP packet is copied directly to the
corresponding block, replacing what was there with the provided content.
This greatly simplifies the processing within the ADCS since the actions described above
for read and write is no different from a simple memory read or write and is treated as such.
However, NSP packets only allow up to 260 bytes of data, and some of the blocks are larger
than 260 bytes, requiring more than one NSP packet to properly process the data. Using the
existing Read or Write command that allows multiple packet-read / write are prohibited in
this case because the location where the ACS Exchange structure exists can only be accessed
directly by the ADCS application software.
To handle this issue, the following mechanism was implemented: the packets are sent with
a sub-command byte (representing read or write command), eight bytes long mask for the set
of blocks being sent, and four bytes long offset denoting the current packet’s byte-wise offset
from the first packet. The rest of the data (247 bytes) are the actual structure data being sent.
The ADCS reads the first packet and establishes a buffer (with default values pre-established)
on its memory based on the given mask. After this, the ADCS relies on the offset value given
by each subsequent packet to place the data in each packet to the appropriate memory location
Chapter 2. Generic Nanosatellite Bus Ground Control Application 43
Figure 2.16: Sample ACS Exchange Structure and Memory Manipulation.
on the buffer. Once all data is received, this buffer is copied to the original ACS Exchange
structure. Note that this process can be cancelled with a special sub-command, which prompts
the buffer to be deleted.
The ADCS interface keeps a list of parameters in ACS Exchange as a configuration pa-
rameter in the options interface to help in providing this functionality. This list contains the
following parameters: name of the block that the parameter belongs to, the name of the pa-
rameter itself, mask of the block, data type of the parameter, and the unit used for the values
in the parameter.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 44
The ADCS interface provides the above-mentioned user-control over the ACS Exchange
structure with a combination of check boxes and a list control object. The operator is shown
a list of parameters in ACS Exchange. Each parameter is given a cell to enter in values and a
check box. One or more rows of the list control object denote a single block, grouped together
with a same block name. When any one of these parameters is selected, all parameters with
the same block name are selected to denote that they belong to the same block, to clarify that
these parameters are being sent together.
Once the parameters are selected and values are entered, pressing the Set Selected button
begins the packet compiling process. The ADCS interface first checks which among the list is
selected and creates a parameter mask based on this selection. Then it reads the values of the
selected parameters and encodes them into a large buffer. Then, both the mask and the buffer
are sent to a function that splits the data in the buffer into appropriately-sized NSP packets
containing the sub-command, mask (for the first packet), offset and 247 bytes of data. These
packets are then sent to the queue control.
Each packet received by the ADCS induces a reply packet back to the ground, containing
the last offset received. Based on this value, the ADCS removes the packets determined to
be sent successfully from the queue. Once all packets have been sent, a packet notifies the
satellite’s ADCS subsystem that all data has been sent, causing the buffer to be written to the
ACS Exchange structure, as explained above.
The ACS Exchange parameters can also be read in a similar manner. Parameters to be read
are selected from the list control object with the block-wise selection as noted above, and Get
Selected button is pressed to compile a packet containing the sub-command, mask and offset.
The difference from Set Selected is that this one does not have any data attached to it. The
compiled packet is sent to the queue control.
The reply from the ADCS is a continuous stream of NSP packets containing the offset and
data. This data is saved to a temporary buffer established within GNBControl until the very
last packet is received. Once the last packet is received, the data is decoded based on the
request mask and the configuration parameters from the options interface. The decoded data
is shown on the value cell of the appropriate parameter on the list.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 45
2.4.3 Device with Similar Access Schemes
In GNB platform, several devices are often built and programmed by the same person. Usually,
these devices have the same or similar external interface to each other, allowing similar codes
to be used to facilitate communication from the ground. GNBControl takes advantage of this
with I2C Interface, a flexible interface class with a very wide range of configurable parameters,
and having each instance of this class correspond to a device.
The name I2C came from its initial development as an interface for devices connected
by Inter-Integrated Circuit (I2C). It is possible to communicate with the devices connected
via I2C in bootloader, but the communication is performed through a special I2C command
encapsulating the actual command to be sent to the device. The I2C interface came to be in
order to provide this capacity to GNBControl. However, many of the devices under this class
are not connected to I2C, and are simply not communicable when the OBC is in bootloader.
The bootloader I2C encapsulation functionalities are disabled for such devices, but the I2C
interface is still viable for these devices when the OBC is running CANOE, which enables
communication with all devices on board the satellite.
Shown below in Figure 2.17 is the I2C interface configured for Battery Charge / Discharge
Regulator (BCDR). The various control objects remain in place regardless of the device being
controlled, but the contents of the dropdown boxes and the list control objects change based
on configuration parameters from the options interface.
Figure 2.17: I2C Interface with Configuration for BCDR.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 46
The Device dropdown box and the On/Off buttons beside it are used to select between
different devices of the same type - for example, there are three reactions wheels on board the
satellite, one per axis - and turn it on or off. The colouring inside the dropdown box changes to
indicate the current state of the device for the convenience of the operator: red means off and
green means on. The packets generated by the On and Off switches are equivalent to that of
the packets generated by the Power interface, albeit using configuration parameters specific to
the device and not from the power switches list that the Power interface uses. The command
reply populates the state of not only the interface of the requested device but also of all other
power switches, including that of the power switches list on the Power interface, as the reply
always contains the full list of switch states so it would be a waste not to make use of it.
The interface surrounding the manual command box functions in a same manner as the
Main interface: the user selects a command from the Command dropdown box and the various
control objects get enabled and disabled based on this selection. An NSP packet is composed
based on the selected command and the given values in the control objects, then is sent to the
queue control for transfer. The returned packets are decoded using pre-existing functions. If
no such function exists, the I2C interface decodes the data as a string of hexadecimal values.
Several parameters can be selected from the list control interface located at the right half
of the I2C interface. The two buttons, Set Selected and Get Selected, are used to either set a
specified value to the selected parameter or to get the currently-set values. The parameters are
configurable through the options interface. This list control object also has an alphanumeric
sorting modification to allow operators to access desired parameters more quickly.
When the OBC is in CANOE application mode, the I2C interface uses the device address
as the destination address on the NSP packet, which CANOE uses to redirect each packet to
the appropriate device. When the OBC is in bootloader mode, the I2C interface checks if the
device allows commands in bootloader mode, and if so, instead creates an I2C command packet,
which encapsulates the NSP packet composed for the device and sends it out.
Currently, there are four device types using the I2C interface: BCDR, Reaction Wheels
(Wheel), Fine Sun-Sensors (FSS), and Rate Sensors (RS). BCDR is currently the only device
with I2C connection. See the corresponding ICD [18][19][20][21] for more details.
Chapter 2. Generic Nanosatellite Bus Ground Control Application 47
2.4.4 Custom Packets
When the development of the Payload OBC began, it was decided that even though GNBControl
doesn’t have requirements for providing control over the Payload computer and its devices, a
way for testers to send customized packets to it on the fly would be useful. Thus the Custom
Packets interface was created for this purpose. Shown below, Figure 2.18 is the current state
of the Custom Packets interface.
Figure 2.18: Custom Packets Interface.
The control objects in the Send static box represent the set of parameters for the NSP
packet. All of the parameters are configurable at will, inputted as hexadecimal values. The
Send button composes the packet based on the given parameters and sends it to the queue
control. The Clock button was created to aid in creating a Clock Synchronization packet, as
converting from Universal Coordinated Time (UTC) to unsigned integer value is difficult.
The returned results are displayed in the list control object in the Receive static box. Along
with the source, the destination, the command and the ACK value, it also displays the entirety
of the data section of the packet in one of the four different display options to the right. By
default, the data packets are displayed in hexadecimal values. Choosing the decimal type
will convert the value into a list of 4 byte integers. The binary type converts the data into
binary values, grouped into a byte. The ASCII type converts each byte of the data into a
character based on the American Standard Code for Information Interchange (ASCII) scheme
and displays it so.
Chapter 3
GNB Time-Tagged Commands
Control Application
The time available to the ground station to communicate with the on-orbit satellite is very
limited. A satellite at Low Earth Orbit (LEO) is only visible to the ground station for about
ten minutes out of a 90 minutes orbital period. Considering how CanX-3 BRITE plans to
observe various stars that are around the earth at widely-varying intervals regardless of the
current location of the ground station relative to the satellite, being unable to issue a command
to the satellite for up to 90 percent of the orbital period is quite unacceptable. Hence, there is
a need for a system where commands can be issued without being processed immediately, and
instead executed when the designated time comes. The role of the GNB Time-Tagged Command
Control, or GNB TimeTag, is the ground side of this system, where users can add, remove and
manipulate a queue of time-tagged commands on the satellite. Time-tagged commands are
NSP packets containing an execution time and another NSP packet within its data.
The other side of the Time-Tagged Command Control system is the Time-Tagged Command
Queue on CANOE. This queue stores the time value and the internal NSP packet until the
designated time arrives. Then the stored NSP packet is sent out as if the packet has just been
received by CANOE’s Communications thread, and then sent out to the appropriate devices
on the satellite.
While the initial intention was to use this capability to perform BRITE’s star imaging
48
Chapter 3. GNB Time-Tagged Commands Control Application 49
campaign over various time periods, the advantage of having a system where the satellite can
be commanded while not in view of the ground station is obvious. Thus, the implementation
for the TimeTag functions on CANOE is such that it can be used for any GNB mission.
Consequently, the GNB TimeTag software on ground is transparent to different missions.
GNB TimeTag’s development cycle lasted about 4 months. It is now in service for the
AISSat-1 mission, which uses GNB TimeTag to schedule its AIS experiments around the globe.
3.1 Requirements
GNB TimeTag’s requirements are defined under [22]. Table 3.1 shows a selection of key TimeTag
requirements.
GNB TimeTag Requirements
TTag.1 TimeTag shall be as automated as is reasonable to achieve. TimeTag should not
require any human intervention to complete its set of everyday tasks.
TTag.2 TimeTag shall be compatible with all GNB missions without requiring customiza-
tion on a mission-by-mission basis.
TTag.6 TimeTag shall display a list of the m scripts in queue to be sent to any spacecraft
and n scripts sent most recently to any spacecraft. m and n shall be adjustable
by the operator. TimeTag shall not artificially limit the size of the queue, m or
n.
TTag.7 To help ensure compatibility with future missions, TimeTag shall not limit the
format of the time-tagged commands being sent to the spacecraft.
TTag.9 TimeTag should have the ability to handle groups of commands and indicate to
the spacecraft when a set of commands are considered part of a group. TimeTag
should have the ability to handle Upload Must Complete flags if implemented on
the spacecraft.
Chapter 3. GNB Time-Tagged Commands Control Application 50
TTag.10 TimeTag shall allow, as an operating parameter, the definition of the space-
craft’s on-board command buffer size. If a script exceeds the size of the on-board
command buffer, TimeTag shall fill the buffer and then subsequently trickle com-
mands as space becomes available (i.e. as the spacecraft commands are executed).
TTag.12 TimeTag shall allow the operations team to manipulate the current on-board
buffer. Manipulations available shall include flushing, editing, appending, read-
ing, and deleting arbitrary commands.
TTag.13 TimeTag shall allow both absolute and relative times of execution to be specified
in its input and shall use ISO-formatted UTC as a time reference in all user
interfaces.
TTag.14 TimeTag shall be capable of displaying the current state of the on-board com-
mand buffer including: number of active commands, number of empty slots, and
a time-ordered sequence of current commands (as read back). A button shall be
provided that allows the operator to request this information and an option shall
exist that allows TimeTag to request this information automatically at the start
of each pass.
Table 3.1: GNB TimeTag Requirements
TTag.1 specifies the main reason for having GNB TimeTag: it is meant to serve as an
automated platform apart from the control software such as GNBControl. While it would
be unreasonable to assume that GNB TimeTag is able to automatically find and schedule
commands without any human intervention, it should at least be designed such that it is able
to receive pass-related information and use it to begin or end its already-scheduled processes.
TTag.2 and TTag.7 highlight the importance of flexibility in GNB TimeTag. As with
GNBControl, some measure of customizability will be required to provide functionalities over
all GNB missions. In addition, the command being time-tagged must be flexible as well, possibly
requiring a complex system similar to GNBControl’s configurable parameters to allow changes
to GNB TimeTag on a mission-basis.
Chapter 3. GNB Time-Tagged Commands Control Application 51
TTag.6 and TTag.14 are requirements for the user interface and keeping track of the infor-
mation to be displayed to the operator. They are quite specific in what must be displayed to
the operator, leading to fairly easy design decisions for GNB TimeTag’s interface.
TTag.9, TTag.10, TTag.12 and TTag.13 are all requirements for specific functionalities the
TimeTag system must have. While TTag.10 and TTag.12 are requirements on basic function-
alities of a queue, the other requirements are more unique and require a special attention to
design. Their design and implementation will be mentioned separately during later sections.
3.2 Satellite-Side TimeTag Implementation
On the satellite, CANOE has a TimeTag thread implemented specifically to handle incoming
time-tagged commands from the ground. The high level architecture is shown below in Figure
3.1.
Figure 3.1: High Level Time Tag Architecture. [23]
The Time Tag thread on board the satellite accepts two types of queuing scheme: one by
directly queuing packets to the queue using TTC ADD command, and another by providing
the queue with a flash file on the satellite containing a set of time-tagged commands using
TTC LOAD command. For both cases, the absolute time values are defined by a 5-byte long
Chapter 3. GNB Time-Tagged Commands Control Application 52
integer in J2000 (standard epoch with 0 point defined at January 1, 2000, 11:58:55.816 Coordi-
nated Universal Time (UTC)), counted by milliseconds. A relative time value can be specified
for the flash file by using an integer value smaller than the converted integer value of the date
January 1, 2005, 11:58:55.816, five years after the start of J2000 time. Note that having the
functionality to queue with a flash file in effect satisfies TTag.9 and TTag.13.
Other commands are implemented as well. TTC GET is a command used to get information
on specific commands in the queue based on their time value, the destination address and the
command byte. TTC FLUSH removes one or more commands from the queue, again based on
the time value, the destination address and the command byte. TTC QSTATE provides basic
information about all the commands in the queue, and TTC SWAP LOG is used to swap the
flash file used to log replies to the time-tagged commands. Further details on these commands
can be found in the TimeTag ICD [23].
3.3 Overall Design Principle
Based on TTag.2 and TTag.7, the first decision made for GNB TimeTag was that it will have
the minimum knowledge it can have of the time-tagged packets, to maximize its flexibility
and maintain simplicity of the interface. The sacrifice comes from legibility of the time-tagged
packets, but the proposed design also separates GNB TimeTag from all the mission specifics by
adding an extra application that accepts human-readable user inputs and converts them into
scripts that GNB TimeTag is able to read. While this increases the number of applications
associated with GNB and adds an extra application for each mission, the development time
and effort put into GNB TimeTag application is greatly reduced by the lack of customizable
parameters to interpret mission specific packets. In addition, more effort can be directed to
providing a much more detailed and operator-friendly interface for each mission while developing
the script generating application instead of attempting to generalize many of the mission-specific
features.
Note that a significant amount of interface design and implementation has taken place for
GNBControl, providing a generous subset of code that can be reused to enhance the exiting
Chapter 3. GNB Time-Tagged Commands Control Application 53
MFC-based interface. It would be a waste for GNB TimeTag to not take advantage of this,
hence the amount of actual design of the interface portion of GNB TimeTag is minimal.
3.3.1 Simplification of Queue Structure
The idea of a queue structure is at least as important to GNB TimeTag as it is to GNBControl.
Given TTag.1, it can be stated that having a queue to store pre-made commands long prior to
the actual satellite pass is highly advantageous. However, during development of GNBControl,
the queue class developed turned out to be unnecessary, as C++ already has an excellent queue
structure - namely vectors - as a part of its standard template library (STL) [24].
Technically, since the queue structure has already been implemented in GNBControl the
same code could be used for GNB TimeTag as well. However, the vector structure from STL,
having gone through multiple revisions and refinements, is much more likely to be efficient
than a queue developed in a period of month or two. As well, the standard container is viable
to go through revisions and refinements in the future while maintaining compatibility with
applications using older revisions. It constitutes a free debug and upgrade (if it happens).
In the end, using vectors as the main queue is a simple matter of defining a structure of the
queue and then declaring vectors of the structure type. A part of the development time may
be allocated to learning how to perform specific operations using vectors, but this is expected
to be of the same order of difficulty as adapting the existing queue structure in GNBControl
for GNB TimeTag’s use.
3.3.2 Knowledge of Contents and Scripting of Time-Tagged Packets
It would be meaningless for an operator to read a temperature of a device in Digital-to-Analog-
Converter (DAC) value. The value would make more sense after a conversion from the DAC
value to a temperature unit is performed. However, a set of parameters is required for an
application to properly encode human-readable inputs and decode byte-stream outputs. This
information may include anything from a set of words and its matching set of hexadecimal
values to a set of equations to convert the DAC values to some known metric unit.
As the GNB system evolves, GNB TimeTag is bound to meet with the same issue that
Chapter 3. GNB Time-Tagged Commands Control Application 54
GNBControl had - dealing with updated or changed set of parameters from mission to mission
basis. In case of GNB TimeTag, this issue is even greater as the entire payload system is
guaranteed to change, and the payload system is GNB TimeTag’s main benefactor. The changes
in the system that GNB TimeTag must face are much more complex than that of GNBControl,
which does not have any requirements to provide control for payload components.
Thus, instead of providing an all-encompassing solution that GNBControl provided with its
diverse configuration system, GNB TimeTag takes a step in a different direction by removing
parts of the design that inherently require extensive customizability, mainly the human-readable
packet decoding procedure. The source, the destination, the command and the data of the time-
tagged packets are all hexadecimal numbers to GNB TimeTag, displaying them as such and
not worrying about what device the address refers to and what action the byte in the command
field would perform. Figure 3.2 demonstrates this.
Figure 3.2: Difference of Knowledge between GNB TimeTag and GNBControl.
To compensate, another application, dedicated to providing a user interface for creating
scripts that GNB TimeTag is able to recognize, is proposed. The application, specific to each
mission, will be as static as GNB TimeTag because it is an application built specifically for
that particular mission. It does not worry about parameters that may change from update to
update either, as any changes can be applied directly to the code prior to code compile. As
Chapter 3. GNB Time-Tagged Commands Control Application 55
well, since it is specific to each mission, the interface itself can be expanded and abstracted to
allow the operator to relate closer to the actual effect the command will have for the mission
instead of looking at them as numbers and parameters being set.
As GNB TimeTag has limited knowledge of the commands issued from the mission-specific
script generator, the scripts may not be as human-readable as command scripts from GNBCon-
trol. At best, these scripts will contain values that can be read and manually translated by
human hands. Hence, GNB TimeTag should have the capability to both read and write these
scripts to allow on-the-fly editing of scripts by the operator as needed. In addition, since the
scripts are more suited to be read by software, the same set of scripts can be used as the list of
commands for the flash file of time-tagged commands used by the TTC LOAD command.
Note that scripted packets are time-tagged packets being sent directly to the TimeTag
queue on the satellite, hence TTC ADD commands. The intent is not to provide control of the
TimeTag thread to the scripting applications, but to allow scripting applications to queue time-
tagged commands to the satellite’s queue. Thus, the script itself only needs to contain time
values and the content of the time-tagged packets without specifying which TimeTag command
to use. It is up to GNB TimeTag to format the received data into a proper TTC ADD command.
GNB TimeTag limits its knowledge to TimeTag-specific commands, which, described in
the TimeTag ICD [23], can safely be assumed to be common to all GNB missions using time-
tagged packets. Thus, configuration parameters for these packets can be minimized to simplify
the development. The time value is another parameter in a time-tagged command, but this has
no configurable parameters that can change the way it is encoded or decoded, thus the code for
this process is assumed to be static. Finally, the actual packet part of the time-tagged packet
is assumed to be a set of hexadecimal bytes of known size, so regardless of the actual function
of the time-tagged packet, it is simply translated into a stream of bytes and displayed to the
operator as such.
The obvious disadvantage to this approach is that the operator does not have a direct view of
the functionality of the packet that is being sent up to the satellite via GNB TimeTag. However,
as per TTag.1, TimeTag is meant to perform its daily tasks in an autonomous fashion with little
or no human intervention, and the benefit gained for having a highly-detailed decomposition of
Chapter 3. GNB Time-Tagged Commands Control Application 56
the packet is diminished by the lack of its use. As well, the packets can still be generated with a
combination of high transparency and abstraction via use of the mission-specific TimeTag script
generator. These script generators, in addition to providing a user-friendly interface to enter
the commands, should be able to decode a time-tagged script it generated back into a human
readable command. Thus, the operator can have a clear view of the effect the time-tagged
packets will have prior to being converted to a script for GNB TimeTag, and pre-existing
scripts can be decoded into a set of commands with fields and numbers meaningful to the
operator.
3.3.3 Information Tracking
As with GNBControl, having visible access to various sets of information is beneficial to the
operator. For GNB TimeTag, two separate queues that need to be displayed exist, one for the
packets GNB TimeTag is set to send, and another for the packets already up on the satellite
and in CANOE’s TimeTag thread. The packets GNB TimeTag is set to send can be shown
in an identical manner as done in GNBControl, while the reply packets to GNB TimeTag’s
time-tagged packet queuing commands will need to be used to maintain information on the
satellite side’s TimeTag queue.
In addition, a log of all actions taken on GNB TimeTag can be created, by implementing
functionality similar to the History interface in GNBControl. On top of any system-wide
messages, the majority of the entries can be based on information stored on the packet queue of
GNB TimeTag, updated whenever a packet is sent out to the satellite. As well, GNB TimeTag
should create CSV files to store logs as per general ground software requirements, just as the
History interface has done so.
3.4 Architectural Implementation
GNB TimeTag’s role as a ground control software is diminished when comparing the number
of commands available to GNB TimeTag and GNBControl. Instead, GNB TimeTag is more
significant as automated software meant to perform its actions on a daily basis, with minimal
Chapter 3. GNB Time-Tagged Commands Control Application 57
control by the operator. The software implementation of GNB TimeTag reflects this fact by
focusing on features that help the overall automation procedure and keeping track of information
resulting from the operation. While there are features dedicated to the commands to the
satellite, these are often by-products of the demands from the automation procedure.
Below in Figure 3.3 is the block diagram for the overall architecture of GNB TimeTag.
Unlike GNBControl’s root interface, GNB TimeTag’s root interface handles the command and
script generation instead of creating and utilizing subsystem classes to do so. The reason is
that for one, GNB TimeTag and its functions are all part of one subsystem - namely, the
time-tagged commands functions. For another, the scale of the command interface for GNB
TimeTag - and consequently the processing details required for the commands - is far smaller
than that of GNBControl. Hence, the root interface class is able to able to display and process
all command functions that GNB TimeTag provides to the user instead of having multiple
windows and having to switch through them. However, this does not mean that the root
interface has no child interfaces or classes of its own. Other classes shown in Figure 3.3 support
GNB TimeTag’s root interface as well. Most of the supporting classes are either from other
applications - namely GNBControl and NICE - or they have high potential to be reused for
other applications following GNB TimeTag, so they have been intentionally separated from the
root interface.
Below in Figure 3.4 is the root interface window of GNB TimeTag. As with GNBControl’s
root interface window, tab control is utilized once again to provide greater amount of display
space, in this case to display the ground commands queue, the satellite time-tagged commands
queue or the system messages from the application. It also uses the message handler class to
communicate with its child classes.
The other classes employed by the root interface and their functions are introduced below.
3.4.1 Queue Display
GNB TimeTag utilizes Queue Display class to display the ground queue, the satellite queue and
the system messages window. The queue display interface uses CExtendedDialog mentioned
previously, allowing the windows to be moved and placed in any desired locations. It has several
Chapter 3. GNB Time-Tagged Commands Control Application 58
Figure 3.3: Block Diagram of GNB TimeTag Architecture.
functions accessible by its parent class to edit the list control object it has within its window.
Hence the queue display class functions exactly like a list control object, except it can be moved.
Also, generating and placing a queue display interface class is much more convenient in terms of
coding, because the list control objects must be placed by hand (or by mouse pointers), which
is imprecise, whereas an interface class is placed by specifying the pixel-location of where it will
be, without requiring any additional codes.
Chapter 3. GNB Time-Tagged Commands Control Application 59
Figure 3.4: GNB TimeTag Root Interface.
3.4.2 Packet Storage and Routing
As with GNBControl, GNB TimeTag utilizes the queue control to store commands issued via
scripts or the command console until it is time to send it up to the satellite. The queue control
has a set of queue-related functions similar to GNBControl’s queue control. While the queue
display handles the displaying of the ground queue to the operator, the queue control is where
the messages to the queue display is generated, adding and removing entries from the display
as the ground queue is updated.
The queue control serves as an improvement to the GNBControl’s own. The class structure
is the same; as the queue control in GNBControl used the packet sender and packet receiver
classes to send and receive the packets, which in turn used the TIP Socket class to establish
communication with MUX, the queue control in GNB TimeTag utilizes a packet handler class to
Chapter 3. GNB Time-Tagged Commands Control Application 60
send and receive packets, which in turn uses the same TIP Socket class that GNBControl used.
The functionalities of the packet sender and the packet receiver classes are merged together into
the packet handler because GNB TimeTag does not expect a high volume of command or reply
packets (unlike GNBControl, which can at times receive up to 32 kilobytes of data per second,
for several minutes), and by implementing the packet handling functionalities in one class, the
packet rerouting from packet sender to the packet receiver that was done on GNBControl can
be avoided. It is also important to note that the packet handler in GNB TimeTag sends one
command and expects one reply, compared to GNBControl’s packet sender and receiver, which
could send one or more packets then receive one or more replies. This fact greatly simplifies
the packet handler class that is implemented for GNB TimeTag, and also makes it more robust
against invalid packets to and from the satellite.
The sending process, illustrated in Figure 3.5, starts via a message from the root interface.
The external prompt can either be a manual command input from the user or from a loaded
script, but the end result is a command packet that is ready to be sent up to the satellite. The
queue control acts upon the command packet by first checking if the socket is connected and if
there exists any packet to send. Then it locks the queue for reading and sends a message to the
packet handler with a pointer to the first packet in the vector queue. At the same time, it sends
a message to the root interface to start the time-out counter that notifies the queue control to
send the packet once more after a set period of time. In the packet handler, the received packet
is sent to MUX using the TCP/IP connection established through the TIP Socket class, and a
message is sent to the root interface containing the description of the packet that was sent and
an indicator to tell the root interface to log this information.
The receiving process is simplified as seen in Figure 3.6, as there is no longer a need to
forward the received packet from the packet sender to the packet receiver. When the data
is received from MUX, TIP Socket again copies the stream of data to a temporary buffer,
and provides the packet handler with the memory address to the buffer. The packet handler
proceeds to decode the received data stream into an NSP packet, and sends the packet to the
root interface via its message queue. When the root interface message queue dispatches the
packet, it is processed appropriately.
Chapter 3. GNB Time-Tagged Commands Control Application 61
Figure 3.5: Sending Packets in GNB TimeTag.
3.4.3 TimeTag Commands
GNB TimeTag is able to handle all six TimeTag commands in the TimeTag ICD [23]. While
small, the commands interface shown in Figure 3.7 provides the full set of TimeTag commands
to the operator. Parts of the interface are enabled or disabled based on the selected command to
correctly reflect the parameters each command requires. Akin to GNBControl’s Main subsys-
tem interface, the selection event from the dropdown box is caught and the currently-selected
command is compared with a list of Boolean parameters to determine which control objects
to enable and disable. Unlike GNBControl, the Boolean parameters list cannot be modified in
options, because the command structure for the TimeTag system is not expected to change.
Each command has a function for creating it and decoding its reply. This was done so to
provide more human-readable details for each command and because each command is unique
Chapter 3. GNB Time-Tagged Commands Control Application 62
Figure 3.6: Receiving Packets in GNB TimeTag.
Figure 3.7: Command Interface in GNB TimeTag.
enough to justify doing this. Hence, the Send button is connected to a function that grabs the
user-inputted parameters in its simplest form (Time and integer for time-related parameters,
unsigned character for command and destination, string for data), checks which commands is
selected, and sends the parameters to the appropriate function for processing. Similarly, when
a reply packet is received by the root interface, it first checks the command byte of the reply
packet and sends the packet to the appropriate processing function specific to the command.
The reply function manipulates the satellite queue display by adding and removing entries
as appropriate. A result of TTC ADD may add an entry, while TTC GET may add multiple
entries scheduled at the same time. A successful TTC FLUSH command may delete one or
more commands, and TTC QSTATE refreshes the display. TTC LOAD has no effect on the
display because the contents of the loaded Flash file are not directly known to GNB TimeTag.
Chapter 3. GNB Time-Tagged Commands Control Application 63
Various messages recorded on the log are generated by the reply functions as well. For
the send functions, the messages are initially stored as a part of the ground queue and then
recorded on the log whenever the packet is sent. For the received packet, the messages are sent
by the reply functions after the packet is processed.
The command interface itself can be hidden when not in use via “Hide” button located
on the bottom left corner, just above the command interface. This emphasizes the fact that
manually commanding the TimeTag queue is not the main function of GNB TimeTag and the
command interface should be unnecessary in nominal operations.
3.4.4 TimeTag Script Language
TimeTag scripts take on a very simple form as seen in Figure 3.8. Each line represents a time-
tagged packet, starting with a time value in ISO 8601 international standard (YYYY-MM-DD
hh:mm:ss.sss) and followed by the packet’s contents in hexadecimal.
2010-06-30 20:02:41.0 41291111223344
2010-06-30 20:05:41.250 41291301B32AC5F1D4E87410
2010-06-30 20:12:41.50 412913FE12A4B2
Figure 3.8: A Sample TimeTag Script.
Due to such simplicity, the loading and the saving of the script file is simplified as well.
When loading, the root interface parses the time value and the data, and then uses them as
parameters to create a TTC ADD command and adds it to the ground queue. When saving,
the root interface goes through the ground queue’s queue display, grabs the string value on
the data column of any TTC ADD entry, also grabs the corresponding entry’s time value from
the ground queue itself (converted to string) and then concatenates the two values to create a
single line of the script file.
The Flash script files used by the TimeTag thread on board the satellite uses a similar
format. The difference is that instead of the ISO 8601 standard, the TimeTag thread expects
a 5-byte long integer in J2000 because this value takes less processing than that of a human-
Chapter 3. GNB Time-Tagged Commands Control Application 64
readable date. For convenience, the operator is shown via a pop-up window a choice to save
the file in Flash script form or the standard human-readable form. If the human-readable form
is chosen, the content of the script file is preceded by a line that says “ISO8601”, denoting that
the time value is of the ISO8601 type. For the Flash script, no marker is given to conserve
space. This marker is used to distinguish between a Flash script and a human-readable script,
decoding the file accordingly when loaded.
The Save and the Load buttons, used to utilize the script functionalities, are located on the
bottom right corner, just above the command interface.
3.4.5 Options
While GNB TimeTag does not require an extensive configuration as GNBControl does, it does
require a configuration, and hence the options interface class is created. The options interface
in GNB TimeTag is an interface on a pop-up window with few options to change the behaviour
of GNB TimeTag. The options parameters listed in this window are straightforward from their
descriptions. The interface of the pop-up window is shown below in Figure 3.9.
Instead of utilizing a configuration file scheme used by GNBControl, GNB TimeTag saves
its configuration settings as a part of the windows registry, using the same code from NICE to
perform this. The advantage is that no separate file is needed to store the configuration, and part
of the parsing is handled by the function that retrieves the registry data. The disadvantage is
that the configuration cannot be transferred from one operating environment to another easily.
For GNBControl, the bigger issue - and the ultimate reason for not using this method - was that
GNBControl had too many changeable parameters for the operator to be expected to re-enter
the configuration when the operating environment changed, so the customized configuration
had to follow the application as well. While one could potentially explore the possibility of
adapting the configuration system in GNBControl to GNB TimeTag, the overhead required to
modify and adapt such a system for GNB TimeTag is not justified by the gain to be had for
doing so.
The propagation of the configuration is not done for GNB TimeTag, because the parameters
stored in the options interface are of the format that can be used directly without any conversion.
Chapter 3. GNB Time-Tagged Commands Control Application 65
Figure 3.9: Options Interface Pop-up Window.
The parameter values are already converted to usable variable types when using the existing
windows function to parse the registry, allowing them to be used as is by the root interface
and the queue control, the two main benefactors of the configuration parameters. The root
interface, the parent of the options interface, uses the configuration parameters by directly
accessing the parsed parameters stored in the options interface. The queue control is given the
memory location of these parameters by the root interface so that it can access them as well
Chapter 3. GNB Time-Tagged Commands Control Application 66
3.4.6 Automation of GNB TimeTag
The automation of daily tasks by GNB TimeTag is achieved by utilizing MUX. MUX allows
its client applications to request for an Acquisition of Signal (AOS) and Loss of Signal (LOS)
data, which it grabs from the connected Tracker application and sends to the requester. This
data is then compared with the current time to determine the AOS and the duration of the
upcoming pass.
GNB TimeTag utilizes this data by normally keeping the ground queue in a “Pause” state,
which prevents packets in the ground queue from being sent out. When the time specified
by the AOS arrives, GNB TimeTag responds by setting the state to “Resume” - which allows
packets to be sent to the satellite once again - and forcing a Ping command to the front of the
queue to confirm the current state of the satellite (if the satellite is in bootloader, there is no
reason to send the packets out, so the queue is paused once again). Once the ground queue
has been emptied or an issue prevents GNB TimeTag from completing the operation, a notice
e-mail is sent out to all subscribed e-mail addresses on the options interface with the current
state of the ground queue and the satellite buffer. MUX is notified of the completion as well to
allow other clients to resume progress.
The Pause and the Resume buttons duplicate the pause and the resume state described
above. It also serves as an indicator to the current state of GNB TimeTag: The Resume button
is pressed while the queue is active, and the Pause button is pressed if not.
The upper part of GNB TimeTag, shown below in Figure 3.10 displays the pass information
retrieved from MUX. This interface also allows operators to set or un-set GNB TimeTag to
perform automated operations or send out completion notice e-mails.
Figure 3.10: Pass Information Display.
Chapter 4
BRITE Target Observation
Scheduler
A mission-specific script generator application was mentioned in Section 3.3.2. BRITE Target
Observation Scheduler, or BRITE Schedule, is one such application, tailored for the CanX-3
BRITE mission as the name suggests. Specifically, BRITE Schedule uses observation schedules
generated by another program called BRITE Target and its knowledge of BRITE and the
imaging payload system to generate a set of time-tagged commands that point the satellite to
the appropriate attitude and start the stellar observation.
As with GNB TimeTag, there is much more leeway for functionalities to have several static
parameters, namely the destination addresses or the command bytes. In fact, there is barely
a need for configuration parameters for BRITE Schedule because most of the configuration
parameters from before were related to packet flows, which is unrelated to what BRITE Schedule
does. As a mission-specific script generator, any changes made to the mission can be reflected
upon BRITE Schedule with a code change and recompilation. By keeping these parameters
static, the design becomes much simpler, hence faster to implement. Note that BRITE Schedule
is only a script generator, not a control application, hence the changes to it only occurs when
there are changes to the payload application code or if there is a major failure in the hardware
that restricts usage of certain hardware, both being rare and infrequent cases.
BRITE Schedule’s development cycle lasted about two months. The internals of the com-
67
Chapter 4. BRITE Target Observation Scheduler 68
mand interface were rewritten afterwards as they were used for BRITE Payload Ground Control,
discussed in next chapter.
4.1 Requirements
BRITE Schedule’s requirements are defined in [25]. A key selection is listed in Table 4.1.
General Requirements
BS 6.1.2 BRITE Schedule shall be capable of interpreting data from BRITE Target repre-
senting the observation targets’ time and position in inertial space to create full
set of command packets to perform the said observation.
BS 6.1.4 BRITE Schedule shall be capable of interpreting and providing human-readable
satellite command outputs from the observation data.
Functional Requirements
BS 6.2.1 BRITE Schedule shall be capable of selecting and interpreting BRITE Target
setup files representing the observation targets’ time and locations to create full
set of command packets to perform the said observation.
BS 6.2.2 BRITE Schedule shall be capable of converting BRITE Target setup files into
script files that can be read by TimeTag to create TimeTag packets to send to
the satellite.
BS 6.2.4 BRITE Schedule shall be capable of generating script files that can be read
by TimeTag, independent of a BRITE Target setup file. In addition, BRITE
Schedule shall be capable of editing already-generated script files, including those
generated from BRITE Target setup files.
BS 6.2.7 BRITE Schedule shall not have any direct uplink or downlink to and from the
satellite.
Table 4.1: BRITE Schedule Requirements
BS 6.1.2 and BS 6.2.1 specify BRITE Schedule must know how to decode the BRITE
Chapter 4. BRITE Target Observation Scheduler 69
Target setup files and glean useful information for scheduling an observation. While this does
not enforce that observations must always be scheduled through use of BRITE Target setup
files, it implies the important role the setup files have for the BRITE observation campaign.
BS 6.1.4 and BS 6.2.2 reaffirms that BRITE Schedule’s task is to generate TimeTag scripts
based on BRITE Target setup files. BS 6.2.7 enforces this by specifying BRITE Schedule to not
communicate with the satellite directly. BRITE Schedule’s position in the mission is strictly
limited to generating scripts. This requirement was created to ensure that BRITE Schedule
will not act upon any data from BRITE Target setup files in an autonomous fashion.
Finally, BS 6.2.4 ensures that some manner of user control is retained via allowing manual
generation and editing of script files. This also means that BRITE Schedule must be equipped
with means to receive user inputs that can be translated into scripts. An interface similar to
GNB TimeTag’s command section or GNBControl’s various subsystem dialogs can be imple-
mented to BRITE Schedule so that users can easily schedule observations and convert them
into scripts.
4.2 BRITE Target
BRITE Target is an application developed by Rainer Kuschnig to support the comprehensive
investigation of a target field and to produce proper setup information for each BRITE satellite
contributing to the observation [26]. While BRITE Target allows scientists to determine and
specify target fields in an intuitive manner, the main feature BRITE Schedule is interested in
is the setup file generation capacity. BRITE Schedule uses this file to plan a set of actions to
be taken to perform the observation. Shown below in Figure 4.1 is BRITE Target’s interface.
Two types of setup file are generated by BRITE Target: one in XML format, and another
in binary format. The XML setup file is the one BRITE Schedule uses for its purposes, while
the binary file is uploaded to the spacecraft for the payload application. A detailed explanation
of the contents of the setup file is located in the BRITE Target Critical Design Review (CDR)
Document [26]. The parameters of particular interest are Reference Target Right Ascension,
Declination, Roll, Exposure Time, and Cycle Time. The Reference Target Right Ascension,
Chapter 4. BRITE Target Observation Scheduler 70
Figure 4.1: BRITE Target Graphic User Interface. [26]
Declination and Roll define the orientation of the imager for the duration of the observation,
translating directly as commands to the ADCS. The Exposure Time is the Charge-Coupled
Device (CCD) exposure time for the imager, while the Cycle Time is the time between the
start of two consecutive exposures. The Cycle Time and the Exposure Time parameters directly
translate as commands to the imager. Other parameters defined in the setup file can affect the
generated script files as well.
Chapter 4. BRITE Target Observation Scheduler 71
4.3 BRITE Payload Imager System
BRITE’s payload is an imaging system used for imaging of various observation fields containing
target stars. It is composed of four major devices: the Instrument On-Board Computer (IOBC),
the KSC-1000 CCD Timing Generator, in-house CCD Header Board and the CCD itself. Of
these, BRITE Schedule cannot command the CCD chip directly. Instead, majority of the
commands generated by BRITE Schedule is directed towards the BRITE IOBC. The overall
relationship between the four payload devices are shown in Figure 4.2. The BRITE IOBC is
able to issue commands to the header board for the imager operation and set exposure timing
through the timing generator, while the two devices communicate directly to the CCD to take
exposures that provide image data to the BRITE IOBC. In addition to the imaging process,
BRITE IOBC also provides memory space for the BRITE Science on-board software - a software
that processes images taken for the observation prior to having them sent to ground [27].
Figure 4.2: Relationship between BRITE Payload Imager System Hardware
For the purpose of BRITE Schedule, the IOBC software functions in a similar manner
as GNBControl’s bootloader software, providing basic memory manipulation, telemetry and
protocol-specific communication with devices. It also provides a specially-tailored command
to allow access and modification of the CCD timing generator and the CCD header board
parameters, which in turn determines the behaviour of the imager payload. As well, it has an
Chapter 4. BRITE Target Observation Scheduler 72
all-encompassing Observation Start command which begins an observation cycle based on the
current state of the IOBC and its parameters. More information about the BRITE IOBC can
be found in the IOBC ICD [28]. In addition, KODAK KSC1000 Timing Generator Manual [29]
contains more information on the timing generator.
4.4 Overall Design Principle
As the third-in-line interface application developed, BRITE Schedule is poised to take advantage
of various features developed and deployed for its predecessors. On the flipside, BRITE Schedule
serves only the BRITE mission, providing room for creating a more unique and efficient envi-
ronment for the operator. The overall design is a mixture of both, using previously-developed
codes and then adding small twists to suit the operator’s needs.
Based on the requirements, there are three main features that need to be designed. One is a
set of functions and interfaces to decode the BRITE Target setup file. Another is for generating
and storing commands for the observation based on either the decoded script file or manual
operator inputs. Finally, the last feature is a function to generate and store the TimeTag script
file upon operator command. The first feature is specific to requirements BS 6.1.2 and 6.2.1,
while the next two features in concert would satisfy BS 6.1.4, 6.2.2 and 6.2.4. Note that BS
6.2.7 is automatically satisfied because BRITE Schedule does not have a direct connection to
MUX.
4.4.1 Handling BRITE Target Setup File
The contents of the BRITE Target setup file are pre-defined by the BRITE Target CDR [26].
One interesting issue is that the number of parameters in the setup file is variable. In particular,
more than one set of parameters about Regions of Interest (ROI) and visibility may exist in a
single setup file. This is shown in Table 4.2. While the first few parameters follow the expected
format, diversion is seen starting at ROI 001 PM. The first setup file ends at that point, but
the second setup file continues on, providing an additional parameter ROI 001 BW and then
providing a second set of region of interest parameters.
Chapter 4. BRITE Target Observation Scheduler 73
Sample BRITE Target Setup Files
TARGET VERSION 4.0.0.11 TARGET VERSION 4.0.0.11
SATELLITE NAME BRITE-AUSTRIA SATELLITE NAME BRITE-AUSTRIA
SETUP ID 080205abcd SETUP ID 080205abce
... ...
ROI TOT NUM 1 ROI TOT NUM 2
ROI 001 LABEL HD 35468 ROI 001 LABEL HD 35491
ROI 001 X1 151 ROI 001 X1 51
... ...
ROI 001 PM 0 ROI 001 PM 20
ROI 001 BW 8
ROI 002 LABEL HD 35492
ROI 002 X1 52
...
Table 4.2: Two Sample BRITE Target Setup Files with Different Parameters
The fact that each setup file may contain varying number of parameters implies that what-
ever structure used to store the decoded contents of the setup file cannot be static and must
account for the changing sets of parameters. However, apart from this issue, writing the actual
decoding process should be fairly simple as the BRITE Target CDR [26] provides the name and
the format used for each parameter in the setup file. BRITE Schedule simply has to use the
provided information to decode and store the setup file for further use.
Each setup file also specifies various date and time on which the target is visible to the
satellite. For BRITE Schedule, an observation corresponds to one visible period of the target,
so each setup file often corresponds to multiple observations. It is up to the ground station and
the operator to determine on which of the visible periods the observation must occur. Hence,
the interface must include a way for the user to select which of the visible periods the setup file
will be used to generate the observation commands.
Chapter 4. BRITE Target Observation Scheduler 74
Note that a large subset of contents from the setup file is meaningless to the operator. Apart
from the visibility information, the operator merely needs the filename of the setup file for
identification purposes, while other parameters of the setup files are mainly for file verification
by the scientists, in case some issue was observed from BRITE Target. Consequently, developing
a customized interface to display the setup files information may be a waste of time from the
developer’s point of view.
4.4.2 Command Interface
Given the number of times command interfaces have been implemented on GNBControl and
GNB TimeTag, using a similar interface for BRITE Schedule would be beneficial in terms of
development. Operators would benefit as well due to the uniformity of the command interfaces
presented. Thus, BRITE Schedule’s command interface is developed using the now-familiar
MFC control objects such as dropdown boxes and list control objects, combined with text
boxes to enter in values and Date and Time boxes to specify time for the time-tagged packets.
As per GNB TimeTag, each command in BRITE Schedule should have a function dedicated
to creating it. Since BRITE Schedule does not communicate with the satellite, a function for
decoding the reply is not needed. The set of IOBC commands BRITE Schedule must implement
are defined in the IOBC ICD [28]. In addition, the ACS Exchange structure must be accessed
to command the ADCS to the designated attitude. Details on ACS Exchange structure and
how it is commanded is located in Section 2.4.2.
As the main goal of BRITE Schedule’s command interface is to create a list of commands
to be converted to scripts, the command interface requires a passive queue with an interface
to show to the user the current state of the queue. Similar structures, functions and interface
objects used for GNB TimeTag can be reused here, minus the mechanisms for preparing and
sending packets to the satellite.
Note that displaying this command list is the extent of any information flow within BRITE
Schedule due to its lack of communication with the satellite, thereby also serving as a general
log for actions taken by the operator.
Chapter 4. BRITE Target Observation Scheduler 75
4.4.3 Generating Observation Commands
The exact set of commands for a setup-file-based observation for one visible period has not yet
been defined. However, the current assumption is as follows:
1. Command ADCS to point spacecraft to desired attitude,
2. Command CCD header board with temperature set point,
3. Setup CCD timer with exposure information,
4. Start first exposure, and
5. Continue taking exposure until end of observation.
The above order of actions, as per the IOBC ICD [28], is subject to change and each entry
shown above may not correspond to a singular command. However, any commands to be used
for the observation via setup files need to be implemented as a part of the manual commands as
well. Hence, to allow simplification of the above, the command generation functions should be
written in a modular fashion such that when it comes to generating a list of commands based
on a setup file, the function handling this task merely has to refer to each command generation
function. Once the exact set of commands is finalized, the implementation on BRITE Schedule
can be changed with ease and have little impact to the overall code.
4.4.4 Generating and Decoding TimeTag Scripts
TimeTag scripts will be generated from the list of commands BRITE Schedule will keep in its
command interface. Since the TimeTag script has already been fully defined in GNB TimeTag,
it comes down to a matter of implementation to the specification.
On the other hand, decoding an already-existing TimeTag script is much more complicated.
Inputting commands to the command list from the command interface is simple because the
user input is already in the application as a part of the command queue. The state TimeTag
script’s data string is in is essentially the highest point of encoding it will be in prior to being
sent to the satellite, requiring a set of decoding functions tailored to each command to decode
it to a human-readable form. Fortunately, since each command can be considered unique, the
process can be hard-coded without any changeable parameters, cutting down a great deal of
development time.
Chapter 4. BRITE Target Observation Scheduler 76
4.5 Architectural Implementation
Overall, BRITE Schedule is a small application, comparable to a moderately sized subsystem
from GNBControl. It does not confer any direct control over BRITE and thus lacks the classes
needed to communicate with MUX. It also does not handle any replies from the devices referred
to by its scripts. At most it has an additional functionality of being able to read and write a
script specific to GNB TimeTag. Hence, the scale of implementation for BRITE Schedule is
limited and quite specific.
Nonetheless, some parts of the code from prior applications are used to further simplify
the development process. BRITE Schedule uses the same type of interface implemented in
GNBControl and GNB TimeTag. The same parent-to-child messaging structure used by GN-
BControl and GNB TimeTag are maintained here as well. BRITE Schedule also uses the tab
control selection scheme to provide more interface space. Other simple functions used to encode
and decode parts of the packet are imported for BRITE Schedule’s use as well. Figure 4.3 shows
the main dialog window of BRITE Schedule, with the Star Field tab selected and a sample file
loaded for script generation.
BRITE Schedule’s overall architecture is very simple, as seen in Figure 4.4. The root
interface of BRITE Schedule creates and displays Star Field and Command classes, while the
two classes handle all of the processing from importing and decoding the BRITE Target setup
files to crafting the set of observation commands into GNB TimeTag script. The message
handler system is once again employed to facilitate communication between classes while keeping
them independent of each other. BRITE Schedule’s architecture is noticeably simpler than
that of GNBControl or GNB TimeTag because it does not send packets to the satellite directly,
eliminating the need for a complex queue control, packet handler or connection handlers for
MUX.
4.5.1 BRITE Target Setup File and Target Field Selection
In BRITE Schedule, Star Field class is used decode the setup file and display its results to
the interface. The same interface is used to select and add a new set of observation commands
Chapter 4. BRITE Target Observation Scheduler 77
Figure 4.3: BRITE Schedule Interface.
to the queue as well. As shown in Figure 4.3, it is composed of two buttons - Select Directory
and Schedule Selected - and three list control objects - Observation Files, Regions of Interest,
and Target Visibility.
To aid in storing the decoded parameters, Star Field class defines a vector structure to
store all parameters in a BRITE Target setup file, formatted appropriately. The structure also
contains within it a structure that stores parameters for any number of ROI and target visibility
times, since as mentioned before, the BRITE Target setup file may contain more than one sets
of data on ROI and target visibility times.
Instead of specifying a single file, Star Field class allows the user to designate an entire
directory. The process starts when the user presses the Select Directory button, which shows
a directory map that the user can choose a directory from. Once the directory is chosen, Star
Chapter 4. BRITE Target Observation Scheduler 78
Figure 4.4: Block Diagram of Classes in BRITE Schedule.
Field class checks for any XML files in the directory. When a file is found, the parsing function
is called to begin the file parsing process. The entire process is described by Figure 4.5.
The individual file parsing process begins by creating an instance of the above-mentioned
vector structure to store all parameters in the file. The parameters in the structure that are
not part of ROI or target visibility times are all guaranteed to be unique within the setup file,
so the parsing function loops through a list of expected parameter names and matches them
with the provided names in the setup file. When a matching parameter name is found, the
parameter’s value in the setup file is parsed and the structure is updated. Though not shown
in the figure, while this decoding is ongoing, each decoded value is added and displayed to the
list control object in Observation Files static box.
Once the parsing function loops through the list of expected parameter names and is unable
to find any more parameters in the list of expected parameters, it begins looking for all ROI
parameters and repeats the process described above, except that it now creates an ROI-specific
structure inside the vector structure for each set of ROI parameters found. During the parsing
process, each ROI parameter is checked to see if it is from a different region of interest than
what was parsed before, and if so, a new structure is created before parsing and storing its
Chapter 4. BRITE Target Observation Scheduler 79
Figure 4.5: Flow Diagram for Parsing BRITE Target Setup Files.
Chapter 4. BRITE Target Observation Scheduler 80
value. This process is repeated for the visibility parameters as well.
When the above processes are complete, the setup files have been completely parsed and its
data in the vector structure that was initialized in the beginning of the process. This instance
of the vector structure is then added to Star Field class’s list of vector structure objects. The
entire process repeats for every file the parsing function finds in the specified directory. At the
end of the process, the list of vector structure objects is filled with general information about
each observation file in the specified directory. The list control object in Observation Files
static box was filled while processing the unique parameters, so the users see the list of vector
structures through this list control object.
The target field selection process begins with the user selecting an observation file from the
list. When one of the entries from the Observation Files list is selected, Star Field class catches
the selection event, checks which file has been selected, and then fills the list control objects in
the Region of Interests and Target Visibility static boxes with the parsed information from the
selected file’s vector structure object.
While the Regions of Interest list control object serves little purpose for the user other than
confirmation of the expected information in the setup file, the Target Visibility list object is once
again selectable by the user. By selecting an entry from the Target Visibility list control object
and then clicking the Schedule Selected button, Star Field class uses the combined information
and its knowledge of the command generation functions to issue several observation commands
to Command class.
4.5.2 Command Interface, Generation, Storage
Command class offers a combination of the command interface, generation and storage func-
tionalities. In addition to providing users a command interface to craft manual observation
commands, Command class also receives commands from Star Field class at the end of its
target field selection process. The user interface is shown in Figure 4.6.
The interface itself is divided into largely two parts. One, contained within the Custom
Commands static box, allows users to input a number of selected commands in a very specific
manner. In addition to the date and time interface for generation of time-tagged packets, it
Chapter 4. BRITE Target Observation Scheduler 81
Figure 4.6: Command Interface.
also contains a now-familiar dropdown box for selecting specific commands and a set of disabled
text boxes that are enabled based on the selected command. A dropdown box and a list control
object surrounded by the Parameters List static box is also enabled or disabled by the selection
of specific commands. Refer to the IOBC ICD [28] for further information on the available
commands.
The set of interface objects within the Parameters List static box was created for Peripheral
Write command. This command allows modification of device-specific parameters through the
IOBC. In case of BRITE, this command allows control over very specific imager parameters.
Command class has complete information of all readable and writeable parameters for the
imager’s CCD timing generator, hence it is able to display them via interface objects in the
Parameters List static box to provide greater context in parameters being changed by the user’s
command. The parameters displayed here work in a similar manner as the ACS Exchange tab
Chapter 4. BRITE Target Observation Scheduler 82
from Section 2.4.2, in that a set of parameters must be sent together, except there are only
ten fixed sets for Peripheral Write. So the dropdown box is used to select a set of parameters
and the list control object displays the selected set, complete with a pre-defined default values
for all parameters so that the user only has to specify the desired change in the list. Refer
to KODAK KSC1000 Timing Generator Manual [29] for further information on all available
parameters.
The interface objects in the Parameters List static box mentioned above are also used for
later-added I2C and GPIO commands. The I2C command is used to provide control over the
CCD Header board. For this command, the dropdown box is used for sub-command selection
instead. The list control object is enabled when either of Get File and Set File commands is
selected, to display to users the available “Files” - in other word, parameters. As with many of
GNBControl’s list control objects, a parameter is selected and then the Send command starts
the command compilation process based on the selected parameter.
When the Send button is pressed, Command class decodes the given parameters from the
interface and calls upon command-specific processing functions based on the selected command.
A command function is implemented for each known command, so each command is processed
in a very specific manner. However, the end result of all command functions is the same: A time
value in string, an NSP-formatted command packet, name of the command and details about
the command. The NSP packet is encoded into a string of hexadecimal values and queued into
a string vector list to be used later to generate a TimeTag script, while the rest of the end
result is made into an entry in the list control within the Command List static box for the user
to view and confirm that the command has been created correctly.
4.5.3 Exporting and Importing TimeTag Scripts
Once the commands are generated and stored in the queue, a TimeTag script based on the
contents of the queue must be created to achieve the primary function of BRITE Schedule as
an observation script generator. This functionality is also handled by Command class. The two
buttons that represent the script-related functions, Export and Import buttons are both part
of the Command class interface.
Chapter 4. BRITE Target Observation Scheduler 83
The TimeTag script generation process begins when the user presses the Export button and
specifies a valid filename to save the script in. This fairly simple process is illustrated in Figure
4.7. The process takes the time value from the list control object in the Command List static
box and appends the corresponding string-encoded NSP packet from the string vector list. The
combined string value of the two is a single command entry in the TimeTag script. This process
is repeated for all command list entries, at the end of which the TimeTag script generation is
complete.
Figure 4.7: Creating a TimeTag Script.
The Import functionality reads the specified TimeTag script line by line, identifies each
command by the NSP command byte, and then directs each line to a script decoding function
specific to the particular command. This is a simple yet effective implementation scheme,
allowing all known commands to be decoded to a human-readable level. For any unknown
commands, BRITE Schedule ignores the entry entirely but notifies the user that it has ignored
the entry.
Note that the current implementation of BRITE Schedule exports the script with ISO 8601
international standard time format. This may not be ideal if BRITE Schedule is used for
creating TimeTag scripts to be uploaded to the satellite. A future plan is to change this to
Chapter 4. BRITE Target Observation Scheduler 84
allow selection between the ISO 8601 and the 5 byte integer value in J2000 form. As for now, it
is possible to circumvent this issue by loading the generated script in GNB TimeTag and then
saving it back into the desired format, as GNB TimeTag offers the choice to save the script in
either ISO8601 or the 5 byte integer value in J2000 form, as shown in Section 3.4.4.
Chapter 5
BRITE Payload Ground Control
BRITE Payload Ground Control (BRITE PGC) is a ground control application that provides a
simple and easy-to-use command interface for the IOBC software. Initially started as an image
downloading tool for debugging and testing purposes, BRITE PGC now provides a complete
interface to all known commands in the IOBC software.
The command interface and around half the IOBC commands have already been imple-
mented during BRITE Schedule’s development. Some commands have not been implemented
in BRITE Schedule because those commands are only used for retrieving data from IOBC. As
well, none of the commands had an implementation for decoding the received replies because
BRITE Schedule never needed them, hence these are additional implementations performed for
BRITE PGC.
BRITE PGC has been under development for one month at the time of writing, its func-
tionalities implemented in lock-step with BRITE Schedule such that each command function
implemented and tested in BRITE PGC is used in BRITE Schedule as well.
5.1 Requirements
While BRITE PGC began without any formally-defined requirement, each function request
from the IOBC personnel eventually led to a set of formalized requirements. These are defined
in the BRITE PGC Requirements Document [30]. A selection are shown below on Table 5.1.
85
Chapter 5. BRITE Payload Ground Control 86
General Requirements
BP 6.1.2 BRITE PGC shall provide to its users the means to issue commands to the IOBC
software.
BP 6.1.3 BRITE PGC shall be capable of communicating with MUX to send the above-
mentioned commands to the satellite.
BP 6.1.4 BRITE PGC shall be able to receive and translate reply packets from the IOBC
software such that a user with minimal programming experience will be able to
read the results.
Functional Requirements
BP 6.2.1 BRITE PGC shall provide the means to issue all commands listed in the IOBC
ICD [28] that are not already implemented in GNBControl.
BP 6.2.2 BRITE PGC will provide the means to issue all commands listed in the IOBC
ICD [28], including those already implemented in GNBControl.
BP 6.2.3 BRITE PGC shall be capable of downloading images from the imager and save
it as a FITS file.
User Interface Requirements
BP 6.3.1 BRITE PGC shall provide a command interface. The command interface should
allow users with minimal knowledge of programming but with knowledge of the
BRITE payload devices to compose commands to the IOBC software.
BP 6.3.2 BRTIE PGC should display any received replies from the IOBC software such
that a user with minimal programming experience will be able to read the results.
BP 6.3.3 BRITE PGC should be able to display the partially-downloaded image from the
imager while the download is still in progress.
Table 5.1: BRITE PGC Requirements
BP 6.3.1, BP 6.3.2 and all of the general requirements define BRITE PGC as a ground
control application to the IOBC subsystem. Essentially, BRITE PGC should function like a
Chapter 5. BRITE Payload Ground Control 87
subsystem dialog window from GNBControl, except with its own communications socket and
its packet parameters specific to BRITE. Unlike GNBControl or GNB TimeTag, it has no
requirements for automation, as its main purpose is to provide manual control of the payload
system apart from its nominal operation. The automated control of the payload system should
be handled by BRITE Schedule’s TimeTag scripts.
BP 6.2.1 and BP 6.2.2 further solidify BRITE PGC’s position as a control application,
but strict requirement for implementation is put for commands that are not already present
in GNBControl, so that BRITE PGC’s development can proceed quickly to provide a usable
version of BRITE PGC earlier in its development. Nonetheless, having all IOBC commands
implemented in BRITE PGC is more advantageous for the user as having to use two command
interfaces to control one subsystem is inconvenient.
BP 6.2.3 and BP 6.3.3 exist to define BRITE PGC’s initial purpose as an image downloading
tool. The Flexible Image Transport System (FITS) file type specification in BP 6.2.3 is a derived
requirement from the BRITE Science Operations and Software Overview Document [31]. BP
6.3.3 exists to allow relatively quick access to even a small part of the image, so that it can be
analyzed and hence speed up the overall debugging and testing process.
5.2 Overall Design Principle
Various parts of the design of BRITE PGC reflect the fact that it only had a singular purpose -
an image downloading tool for the imager system. Its design had gone through two very quick
prototyping processes with two different requirements: initial one for the image downloading
tool and the later one with the added IOBC command functionalities. As it is a prerequisite
to many IOBC software testing processes, the initial design was created very quickly and min-
imal possible changes have been made to the first design to accommodate the second set of
requirements within the shortest period of time possible.
Chapter 5. BRITE Payload Ground Control 88
5.2.1 Image Downloading Module
The imaging downloading process is slightly convoluted. The size of the whole image from the
CCD is bigger than the available memory space in the IOBC. Since BRITE PGC does not
have direct access to the CCD, the only way to download the image is to load a subset of the
image to a memory buffer in the IOBC and then download it to the ground. This procedure is
repeated until the entire image has been downloaded.
In addition, the image from the CCD comes as a 14-bit long pixel array, where each value
represents the light intensity for a pixel. This is not a usable format for any standard image
type, hence requiring some form of conversion before this data can be used to display a coherent
image to the user.
The downloaded image needs to be saved as a FITS file, which is a very specific file format
based on a standard defined by the International Astronomical Union [32]. The saved image
will need to follow this format exactly as the image is processed by another application called
SAOImage DS9, an analysis tool for astronomical imaging and data visualization. More about
DS9 can be found in Joye and Mandel’s paper on it [33].
The IOBC has no capability to pick which row or column section of the images to download
from the CCD due to the design of the CCD. Hence, the overall interface can be very simple,
consisting of a button to start and stop the image downloading process and a way to display
the image being downloaded. Because it takes a very long time to download a single image
from the IOBC (about 45 minutes per full image), it is important to allow partially-downloaded
images to be displayed so that the user can decide to stop the image download in case of any
flaws or errors in the image.
5.2.2 Packet Flow
In BRITE PGC, there is no internal packet queue unlike other ground software introduced
previously. Instead, when it sends out a packet, it will disable the interface until it has received
and decoded a reply, or until the user cancels it. This is simpler to implement than the queue
system and is all that is required for an image downloading module with a singular command.
The lack of a queue system does not mean BRITE PGC can’t receive multiple packets however.
Chapter 5. BRITE Payload Ground Control 89
By making use of the message handler system seen in GNBControl and GNB TimeTag, each
received packet can reside in the message queue until processed.
The actual sending method is the same as that of GNB Control and GNB TimeTag: packets
are sent through an established socket connection to MUX, which sends the packet to the
satellite and returns any received replies back to the corresponding application. The same
classes used to achieve this can be reused for BRITE PGC once again to reduce development
time.
5.2.3 IOBC Control
As noted before, the design for providing control over the IOBC came after the implementation
of the image downloading module. In addition, there was a constant emphasis for speed in
development to provide the tools for debugging as early as possible. Hence, the following sets
of design choices were made.
Since a large subset of functions for IOBC commands have already been implemented in
BRITE Schedule, the same codes are recycled for BRITE PGC. Some additional command
generation functions and all reply decoding functions still need to be implemented, but the
implemented functions can serve as a guide to follow for the functions not yet implemented.
As well, the established user interface from BRITE Schedule can be used for the purpose of
BRITE PGC with minimal modification. Most importantly, the established list of parameters
for the imager from BRITE Schedule can be reused for BRITE PGC.
The packet flow system implemented for the image downloading system is untouched.
BRITE PGC’s use is mainly for manual control of the IOBC while on ground as a debug-
ging and testing tool. Debugging and testing involves a significant amount of user-interaction
with the data produced by the interface, analyzing every command and reply sent and received,
hence nullifying the benefits gained by using a queue.
Finally, as a debugging and testing application, logs are deemed unnecessary. Logs take
time to write and implement, and there is no requirement for one. Since the user is always
expected to be present when the application is in operation, a fairly minimal result displaying
mechanism seems sufficient for the purpose of BRITE PGC.
Chapter 5. BRITE Payload Ground Control 90
Note that all of the above assumes that BRITE PGC will only serve as a debugging and
testing application, not as a nominal operations tool. Its design is missing features shown on
GNBControl or GNB TimeTag that becomes useful in real operation, in exchange for faster
overall development. However, BRITE PGC can still serve as a ground control application
while the satellite is in orbit as long as the user is manually sending the commands. If for some
reason commands must be sent to the IOBC during operation without the use of time-tagged
commands, then GNBControl’s Custom Packets interface can be used to manually craft the
required commands, save it as a command script and load it whenever the operation needs to
be performed.
5.3 Architectural Implementation
When looking at BRITE PGC’s architecture, as shown in Figure 5.1, it is easy to see that its
Command interface - used to provide command input methods for users and decode replies for
sent commands - came after the imaging process design was completed. With the Command
interface excluded from the block diagram, BRITE PGC’s architecture would serve as an image
downloading application. The root interface handles the image downloading process as well as
serving as the parent class to other classes in BRITE PGC. The queue control contains several
empty functions with the same name as those implemented in GNB TimeTag’s queue control,
so that a queue can be implemented with no changes to other classes if desired so in the future.
Packet Handler and TIP Socket classes are the exact same classes from GNB TimeTag with
the code unchanged, handling the flow of the packets from BRITE PGC to MUX. Options
Interface is similar to that of GNB TimeTag’s, but with few added parameters regarding the
image downloading process. The three reused classes save development time without penalizing
the resulting application. The Image Display class is used to display images based on the root
interface’s processing of the received packet.
BRITE PGC’s root interface window is shown in Figure 5.2. The upper half of the interface
is the first iteration BRITE PGC’s interface, while the bottom half containing objects that
compose the Command interface was added during the second iteration.
Chapter 5. BRITE Payload Ground Control 91
Figure 5.1: Block Diagram of BRITE PGC Architecture.
BRITE PGC’s image downloading module uses a very simple-looking interface: A Download
Image button, a Cancel Download button, a Show Image button, a list box control object to
display any messages produced by the operation, and a text box displaying the currently-set
exposure time. This interface is not derived from any other applications, as nothing similar has
been implemented before.
On the other hand, BRITE PGC’s command interface is on par with BRITE Schedule or a
subsystem from GNBControl. As it confers direct control over the BRITE IOBC and decodes
replies from it as well, its set of functions is much closer to GNBControl’s subsystem interface
than it is to BRITE Schedule. It still makes use of various codes that BRITE Schedule used
to compose packets for the IOBC. It also maintains the message handler system, but abandons
the tab-control in favour of displaying all available commands in a single window thanks to
the small number of additional functionalities (namely the image downloading module). The
Chapter 5. BRITE Payload Ground Control 92
Figure 5.2: BRITE PGC Interface.
command interface makes use of the above-mentioned list box object to display its messages as
well to maintain output consistency.
5.3.1 Image Download and Display
The Image downloading process has a strict requirement imposed upon it. The requirement
specifies that the image data must be saved in FITS file format. FITS file format is a very
specific image format that must follow hundreds of rules for its specification, so implementing a
robust code that handles the conversion of imager data into FITS files format could take quite
a while. Instead of implementing a new code, BRITE PGC takes advantage of an open source
code to process the image data into FITS file format. It is called CFITSIO, a library of C
and Fortran subroutines for reading and writing data files in FITS data format [34]. A set of
simple function calls allows creation of well-formed FITS file, eliminating any need for separate
implementation in BRITE PGC.
Chapter 5. BRITE Payload Ground Control 93
The image downloading procedure begins with the user pressing the Download Image but-
ton. This triggers three separate actions. First, an Image Load command specifying the number
of packets to load to memory is composed and sent to the IOBC. Immediately following, the
pop-up window of Image Display class is shown. Image Display class is dedicated to drawing
an image based on the information provided by the root interface. Its drawing canvas is reset
to prepare for the image data to be received. Finally, an empty FITS file is initialized and
created, using a filename based on the current date and time.
The reply to an Image Load command contains the number of packets successfully loaded
to the IOBC’s limited memory space. Based on this information, the root interface sends an
Image Read command, which is responded with a stream of packets containing the above-
mentioned 14-bit-per-pixel image information. The root interface decodes this information into
a two-dimensional array of 14-bit greyscale values, which is inserted into previously-initialized
FITS file. The same information is passed onto Image Display class - pixel by pixel through
a function that is used to draw onto a specific pixel based on the given greyscale value. The
result of processing the data prior to completion is that the FITS file will retain whatever data
it received even if the download process is interrupted and Image Display will continuously
update its canvas with a new set of pixels, allowing the user to see the image download progress
and identify any errors much earlier in the process. Below in Figure 5.3 is the resulting image
on Image Display pop-up window during a downloading process. The above process continues
until the last expected packet (known by the pixel count of the imager) is received, at which
the image downloading process is complete.
The pixel count of the imager and other similar satellite-specific parameters are pooled from
the imager driver’s header files. Hence when its specification is changed, the header file would
be changed and BRITE PGC along with it after a recompile.
5.3.2 IOBC Command Interface
The command interface is very much akin to BRITE Schedule’s Command class in terms of
its functionality. The command interface also has a dropdown box for commands and other
interfaces are enabled or disabled based on this selection. Unlike BRITE Schedule however,
Chapter 5. BRITE Payload Ground Control 94
Figure 5.3: Image Displayed on Image Display while Downloading.
the labels of each control object change with each command selection, as shown in Figure 5.4,
compared to Figure 5.2. This was implemented to keep BRITE PGC’s interface size as small
as possible (so that more area can be dedicated to looking at the image being downloaded) by
using only the minimum set of controls required without losing usability of the interface. Other
than this added functionality, the other visible parts of the interface is identical to BRITE
Schedule’s Command class.
Internally, the command interface behaves in a similar manner to GNB TimeTag. Each
command has a packet encoding and decoding functions to be utilized. The Send button calls
one of the encoding functions based on the selected command and sends the resulting packet
to the satellite. The received reply is decoded by the decoding function for the same command
and its results displayed in the list box control located at the top. The difference is that due to
its lack of a queue, the send action can now be cancelled using a Cancel button. While Send
button is pressed, all interface with the few exceptions are disabled to prevent more than one
command from being sent by accident, as shown in Figure 5.4.
Chapter 5. BRITE Payload Ground Control 95
Figure 5.4: BRITE PGC when Sending a Packet.
Apart from the changing labels, BRITE PGC’s Command interface functions in an identical
manner to BRITE Schedule’s Command interface. Refer to Section 4.5.2 for more details on
how the interface is used, and refer to the IOBC ICD [28] for details on available commands on
the application.
Chapter 6
Conclusions
What has been presented in this thesis is a cycle of design and implementation (sans validation)
of four ground control applications under different requirement constraints: GNBControl, GNB
TimeTag, BRITE Schedule and BRITE PGC. After designing and implementing applications
to serve as a human interface to satellite’s various functionalities, one is continually reminded
of the vast capabilities of a single satellite, and as well the importance of documentation.
GNBControl’s development cycle is complete. All functionalities specified in the requirement
have been implemented. A manual has been written to instruct users on its usage. It has gone
through several prototype stages and is being actively used for various subsystems testing and
debugging. Changes to the code are only made to fix seldom-reported bugs or to add a newly-
requested functionality.
GNB TimeTag’s development cycle is complete - all required functionalities are imple-
mented. Development was easier than GNBControl in part due to its smaller scale and another
part due to recycling of GNBControl’s interface codes.
BRITE Schedule and BRITE PGC are still an ongoing project. While code change is
expected to be limited, further testing and debugging is required for both applications to
ascertain its functions to be in working order. Only the command functions need to be verified
of their correctness, since the interface again uses proven-to-work codes from GNBControl and
GNB TimeTag.
96
Chapter 6. Conclusions 97
6.1 Recommendations for Future
Parts of the interface were continuously reused during development. Tools such as message
handlers, vector structure and MFC interface classes were used for all applications following
each tool’s introduction. Overall application development process is sped up significantly by
making use of pre-existing modules. To this end, a much more modular and structured approach
to programming is recommended for all future development.
For example, a set of commands can be coded such that the process of encoding a command
to be sent and decoding a received command is completely detached from the processing. For
applications on ground, this means that there is a class for decoding and encoding packets for
specific commands and any processing and displaying performed with the data would be in a
separate class. For the flight software codes, this means that any device-specific data telemetry
and manipulation must be done on a separate function apart from the encoding and decoding
function. The current trend in SFL is that device codes are written first so that it can be
tested, while the ground control code is requested and written at a much later date. By forcing
ground control application to be developed alongside each device and share common encoding
and decoding functions, those functions are only developed once and any discrepancies between
the ground control and the device in terms of how the command is encoded or decoded is
eliminated.
It may be advantageous to set up a proper testing platform specific to ground control
software as well. Often the lack of OBCs to test the recently-updated application stopped the
development, as only a limited number of OBCs are available and they are pre-assigned to
select personnel. Some work should be done to provide consistent access to a testing platform
for each application developer so that the development process is not interrupted. Failing that,
perhaps some time should be allocated to developing a software platform to emulate an OBC
application code without actually needing an OBC.
Bibliography
[1] T. Ponick, R. Fleeter, and F. Ponick. The Logic of Microspace. Microcosm Press, 2000.
[2] E. Callibot. CanX-2 System Overview. Technical report, UTIAS Space Flight Laboratory,
2004.
[3] F. Pranajaya, R. Zee, J. Cain, and R. Kolacz. Nanosatellite Tracking Ships: From Concept
to Launch in Seven Months. In USU Conference on Small Satellites. UTIAS Space Flight
Laboratory COM DEV Limited, 2009.
[4] G. Carufel. Assembly, Integration and Thermal Testing of the Generic Nanosatellite Bus.
Master’s thesis, Univeristy of Toronto, 2009.
[5] D. Foisy, T. Tuli, C. Grant, N. Orr, and N. Deschamps. CanX-3 (BRITE) Systems
Overview. Technical report, UTIAS Space Flight Laboratory, 2007.
[6] D. Foisy, T. Tuli, C. Grant, N. Orr, and N. Deschamps. CanX-4/5 Systems Overview.
Technical report, UTIAS Space Flight Laboratory, 2007.
[7] A. Baeattie. AISSat-1 System Summary. Technical report, UTIAS Space Flight Labora-
tory, 2008.
[8] J. Lifshits and J. Cheng. GNB LFFT Test Procedure. Technical report, UTIAS Space
Flight Laboratory, 2010.
[9] D. D. Kekez, M. Short, and N. Deschamps. BRITE and CanX-4/CanX-5 Ground Segment
Software Architecture Requirements. Technical report, UTIAS Space Flight Laboratory,
2007.
98
Bibliography 99
[10] P. E. Black. ”queue”, in Dictionary of Algorithms and Data Structures. http://www.itl.
nist.gov/div897/sqg/dads/HTML/queue.html, April 2007.
[11] B. Barney. POSIX Threads Programming. https://computing.llnl.gov/tutorials/
pthreads/. Last accessed April 19th, 2010.
[12] Juan Soulie. Classes. http://www.cplusplus.com/doc/tutorial/classes/, February
2009.
[13] CDialog Class (MFC). http://msdn.microsoft.com/en-us/library/132s802t%28VS.
80%29.aspx. Last accessed April 2010.
[14] Controls (MFC). http://msdn.microsoft.com/en-us/library/47xcww9x%28VS.80%29.
aspx. Last accessed May 2010.
[15] About Messages and Message Queues. http://msdn.microsoft.com/en-us/library/
ms644927%28v=VS.85%29.aspx, April 2010.
[16] M. Choi. GNBControl Subsystems Implementation Technical Memo. Technical report,
UTIAS Space Flight Laboratory, 2010.
[17] H. Spencer. A Guide to the GNB Bootloader, Version BL-04. Technical report, UTIAS
Space Flight Laboratory, 2009.
[18] G. Bonin and D. Sinclair. BCDRv2 Design Documentation. Technical report, UTIAS
Space Flight Laboratory, 2009.
[19] Reaction Wheel Software ICD. Technical report, Sinclair Interplanetary, 2008.
[20] M.Greene and S.Eagleson. GNB Sun Sensor Interface Control Document. Technical report,
UTIAS Space Flight Laboratory, 2009.
[21] M. Fournier. GNB Rate Sensors Interface Control Document. Technical report, UTIAS
Space Flight Laboratory, 2009.
[22] C. Grant. GNB Ground Software Requirements TimeTag. Technical report, UTIAS Space
Flight Laboratory, 2009.
Bibliography 100
[23] N. Orr and M.M. Dwyer. GNB Time Tag Interface Control Document. Technical report,
UTIAS Space Flight Laboratory, 2009.
[24] vector. http://www.cplusplus.com/reference/stl/vector/. Last accessed May 2010.
[25] M. Choi. BRITE Schedule Requirements. Technical report, UTIAS Space Flight Labora-
tory, 2009.
[26] R. Kuschnig. BRITE Ground Segment Software: BRITE TARGET. Technical report,
2008.
[27] T. Tuli. BRITE Science Onboard Software ICD. Technical report, UTIAS Space Flight
Laboratory.
[28] J. Lifshits. BRITE IOBC Software Architecture and ICD. Technical report, UTIAS Space
Flight Laboratory, 2009.
[29] Kodak. KODAK KSC-1000 Timing Generator, revision 4.0 edition, December 2004.
[30] M. Choi. BRITE Payload Ground Control Requirements. Technical report, UTIAS Space
Flight Laboratory, 2010.
[31] R. Kuschnig. BRITE Science Operations and Software Overview. Technical report, Uni-
versity Vienna Institute for Astronomy, 2007.
[32] Defintion of the Flexible Image Transport System (FITS). http://fits.gsfc.nasa.gov/
standard30/fits_standard30.pdf, July 2008.
[33] W. A. Joye and E. Mandel. New Features of SAOImage DS9. In H. E. Payne, R. I. Je-
drzejewski, & R. N. Hook, editor, Astronomical Data Analysis Software and Systems XII,
volume 295 of Astronomical Society of the Pacific Conference Series, pages 489–+, 2003.
[34] HEASARC, Goddard Space Flight Center Greenbelt, MD 20771 USA. CFITSIO User’s
Reference Guide, version 3.0 edition, April 2009. http://heasarc.nasa.gov/docs/
software/fitsio/c/c_user/cfitsio.html.