design and development of generic nanosatellite …...abstract design and development of generic...

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.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.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.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.1 Image Downloading Module . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.2 Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.3 IOBC Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


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.


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,


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


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.


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


(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.


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


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


Figure 2.1: Sequential Diagram for a Typical Satellite Pass without a Queue.


Figure 2.2: Sequential Diagram for a Typical Satellite Pass with a Queue.


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)


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.


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


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).


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.


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


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.


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


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


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


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


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.


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.


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


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


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


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


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


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


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


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


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.


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.


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


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


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.


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


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


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


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.


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.


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.


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.


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.


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.


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


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].


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


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


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


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


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


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


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.


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


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.


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


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.


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-


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.


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


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


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,


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.


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


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.


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.


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.


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.


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.



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


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


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


Figure 4.5: Flow Diagram for Parsing BRITE Target Setup Files.


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


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


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.


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


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


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.


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.


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.


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.


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.


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.


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


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.


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,


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.


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


[19] Reaction Wheel Software ICD. Technical report, Sinclair Interplanetary, 2008.

[20] M.Greene and S.Eagleson. GNB Sun Sensor Interface Control Document. Technical report,


[21] M. Fournier. GNB Rate Sensors Interface Control Document. Technical report, UTIAS


[22] C. Grant. GNB Ground Software Requirements TimeTag. Technical report, UTIAS Space


Bibliography 100

[23] N. Orr and M.M. Dwyer. GNB Time Tag Interface Control Document. Technical report,


[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


[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


[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.

design and development of generic nanosatellite …...abstract design and development of generic...

Documents