Software for the Canadian Advanced Nanospace eXperiment-4 ... · Software for the Canadian Advanced...

Software for the Canadian Advanced Nanospace eXperiment-4/5(CanX-4/-5) Mission

by

Matthew Leigh Leonard

A thesis submitted in conformity with the requirementsfor the degree of Masters of Applied Science

Graduate Department of Aerospace EngineeringUniversity of Toronto Institute for Aerospace Studies

Copyright c© 2012 by Matthew Leigh Leonard

Abstract

Software for the Canadian Advanced Nanospace eXperiment-4/5 (CanX-4/-5) Mission

Matthew Leigh Leonard

Masters of Applied Science

Graduate Department of Aerospace Engineering

University of Toronto Institute for Aerospace Studies

2012

The CanX-4 and CanX-5 mission currently under development at The University of Toronto Insti-

tute for Aerospace Studies Space Flight Laboratory UTIAS/SFL is a challenging formation flying

technology demonstration. Its requirements of sub-metre control accuracy have yet to be realized

with nanosatellites. Many large technical challenges must be addressed in order to ensure the

success of the CanX-4/5 mission. This includes the development of software for an intersatellite

communication system, integration and optimization of key formation flying algorithms onto the

Payload On-Board Computer as well as the development of a Hardware-In-The-Loop simulator

for full on-orbit mission simulations. This thesis will provide background knowledge of the Space

Flight Laboratory and its activities, the CanX-4/5 mission, and finally highlight the authors con-

tributions to overcoming each of these technical challenges and ensuring the success of the CanX-4

and CanX-5 mission.

ii

Dedication

To Mom and Dad,

The best parents a kid could have, you’ve given me so much. You allowed me to dream, and

gave me the courage to chase them. You’ve watched me fail, but were always there to pick me up

and dust me off. You’ve always accepted me, for who I was, who I am, and who I will be. You’ve

encouraged me to take chances, and always push myself further. You’ve never stopped believing

in me, even when I didn’t believe in myself. You taught me to be tenacious and unrelenting in the

pursuit of my goals. Together you have afforded me with all the tools and skills I need to take on

life’s great adventures. Both of you mean more to me than you can ever know.

Mom, Dad, you’ve always been the source of my strength; I love you, and I hope I’ve made

you proud...

Love always, your son, Matthew

To Justin,

My baby brother, and also, my oldest friend; I know we didn’t always play nicely in the sand-

box when we were kids. But now that we’re older, I can look back and say, I couldn’t have had

a better brother. You were always a willing partner in crime, and always had my back when I

was in trouble with Mom and Dad. You were my teammate, opponent, and occasionally my arch

nemesis. I’m thankful that as the years go by, we seem to grow closer. I feel so honoured to have

had the chance to watch you grow up, from that annoying little brother you used to be, into the

independent man you are today. I can only hope that I’ve imparted some big brotherly knowledge

on you over the years, and want you to know, that I’ve always been, and will always be proud to

call you my brother.

Love, your big brother, Matthew

˜ ad astra per aspera ˜

iii

Acknowledgements

I would like to thank Dr. Robert E. Zee for taking me on as a Masters student and giving me the

opportunity to work at the Space Flight Laboratory. I have gained invaluable experience here, and

I know I will be able to leverage this, and be able to continue to chase my dreams.

I owe an unplayable debt to some of my closest friends. You were always there for me through

life’s ups and downs during my time at UTIAS. Jeff, you’re my best friend, my confidante, my

conscience, and usually the devil on my shoulder. Melissa, you always seem to be taking care of

me, even though I’m convinced I can take care of myself, the food, towels, blankets, for everything,

thank you. Mikey, yes you’re messy, yes you’re late, always, but you’re a great friend, and we’ve

had a lot of fun times over these last two years. Greg, somehow you managed to live with me for

three years and still remain a dear friend, you always did have the patience of a saint. Keri, we’ve

grown so much closer over the years, and besides, who else am I going to have 4AM 90’s dance

parties with? Phil and Char, you guys always welcome me back to London with open arms, more

than a few drinks, and a place to stay. I love you all, and I wouldn’t have been able to finish this

without having such amazing friends to support me along the way. I only hope that one day I’ll be

able to repay all the kindness you have shown me.

Finally I would like to thank all the great people at the Space Flight Laboratory who have made

my two years here fly by. I’ve made some great friends, had some amazing times, have more than

a few new interesting stories to tell, and always, had lots of laughs. I will miss you all as I leave to

start the next chapter in my life.

˜ aut inveniam viam aut faciam ˜

iv

Contents

1 The CanX-4 and CanX-5 Mission 1

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Formation Flying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 On-Board Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.7 Attitude Determination And Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.8 Nanosatellite Protocol (NSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Background 9

2.1 Formation Flying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 UTIAS Space Flight Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Microspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 CubeSats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Generic Nanosatellite Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 The CanX Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.7 Relevant Current Missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.7.1 CanX-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.7.2 AISSat-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Intersatellite Link 16

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 ISL Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

v

3.3 Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1 Sinclair F411 Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2 Generic Firmware Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 ISL Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.1 ISL Flight Software System Requirements . . . . . . . . . . . . . . . . . . . . 21

3.4.2 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.3 OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.4 Software Development Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.5 Engineering Model Software Revision 1 & Board Bring-up . . . . . . . . . . . 26

3.4.6 Engineering Model Software Revision 2 . . . . . . . . . . . . . . . . . . . . . 33

3.4.7 Flight Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4.8 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.9 Intersatellite Link Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.4.10 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4 Payload On-Board Computer 60

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2 Formation Flying Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.1 OBC Target Integration Overview . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.2 Code Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2.3 Memory Footprint Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.4 Execution Optimzations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3 Integration Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5 Hardware-In-The-Loop (HWIL) Simulation 71

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 GPS Simulation Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.5 Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6 Conclusion 85

vi

Bibliography 87

7 Appendix 90

7.0.1 MAC Layer Transmit Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . 90

7.0.2 MAC Layer Receive Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . 92

vii

List of Tables

3.1 ISL C8051F411 Peripheral Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 ISL CC2500 Register Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 ISL Engineering Model Rev 2 Serial Protocol Definition . . . . . . . . . . . . . . . . 35

3.4 Mapping of ISL Telemetry to GFI parameter index . . . . . . . . . . . . . . . . . . . 53

4.1 Matrix vector multiplication optimization results . . . . . . . . . . . . . . . . . . . . 67

4.2 Matrix matrix multiplication optimization results . . . . . . . . . . . . . . . . . . . . 67

4.3 Matrix addition optimization results . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.4 Matrix subtraction optimization results . . . . . . . . . . . . . . . . . . . . . . . . . 67

viii

List of Figures

1.1 CanX-4&-5 exploded view (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 FIONA and RelNav Block Diagram (Source: SFL) . . . . . . . . . . . . . . . . . . . 4

1.3 CanX-4&-5 radio antennas (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 A typical 1u CubeSat, Norwegian NCUBE2 (Source: Bjorn Pedersen) . . . . . . . . 11

2.2 Exploded GNB Architecture (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 GNB Tray Configuration (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 CanX-2 (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 AISSat-1 (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 ISL Hardware Block Diagram (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . 17

3.2 ISL C8051F411 Pinout (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 ISL S-Band Patch Antenna (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 ISL S-Band Patch Antennas Gain Pattern (Source: SFL) . . . . . . . . . . . . . . . 20

3.5 OSI Model Diagram (Source: catalyst.washington.edu) . . . . . . . . . . . . . . . . . 24

3.6 ISL Software Development Plan Overview (Source: SFL) . . . . . . . . . . . . . . . . 26

3.7 Engineering Model Revsion 1 GSE (Source: SFL) . . . . . . . . . . . . . . . . . . . . 32

3.8 Detector Voltage Plot Generated by EM GSE (Source: SFL) . . . . . . . . . . . . . 33

3.9 ISL EM Software Revision 2 Ground Support Equipment Software (Source: SFL) . . 39

3.10 Layers of the ISL Protocol Stack (Source: SFL) . . . . . . . . . . . . . . . . . . . . . 41

3.11 ISL Software State Diagram (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . . 42

3.12 ISL Protocol Stack Application Programming Interface (Source: SFL) . . . . . . . . 45

3.13 Framing of data in the ISL protocol stack (Source: SFL) . . . . . . . . . . . . . . . . 51

3.14 The MAC layer unit tester software (Source: SFL) . . . . . . . . . . . . . . . . . . . 54

3.15 The PHY and MAC layer integration tester software (Source: SFL) . . . . . . . . . 55

ix

3.16 Physical layout of the integration test setup (Source: SFL) . . . . . . . . . . . . . . 56

3.17 The ISL flight software system test software (Source: SFL) . . . . . . . . . . . . . . 58

3.18 Physical layout of the system level test setup (Source: SFL) . . . . . . . . . . . . . . 59

4.1 Dynamic memory allocation process (Source: SFL) . . . . . . . . . . . . . . . . . . . 65

4.2 POBC integration software architecture (Source: SFL) . . . . . . . . . . . . . . . . . 69

5.1 Hardware-in-the-loop block diagram (Source: SFL) . . . . . . . . . . . . . . . . . . . 72

5.2 Spirent Communications SimGen software during a simulation (Source: SFL) . . . . 73

5.3 Hardware in the loop Phase 1 block diagram (Source: SFL) . . . . . . . . . . . . . . 76

5.4 Hardware in the loop phase 2 block diagram (Source: SFL) . . . . . . . . . . . . . . 78

5.5 Startup order required to run a HWIL simulation (Source: SFL) . . . . . . . . . . . 79

5.6 Hardware in the loop phase 3 block diagram (Source: SFL) . . . . . . . . . . . . . . 81

5.7 Closed loop navigation cycle timing histogram(Source: SFL) . . . . . . . . . . . . . . 84

5.8 Control accuracy vs Time plot (Source: SFL) . . . . . . . . . . . . . . . . . . . . . . 84

x

Chapter 1

The CanX-4 and CanX-5 Mission

1.1 Overview

CanX-4 and CanX-5 (Figure 1.1) are an identical pair of Generic Nanosatellite Bus (GNB) based

spacecraft whose primary objective is to demonstrate autonomous formation flight with sub-metre

control accuracy. To date this has not yet been accomplished using nanosatellites [1].

The mission is based on four configurations of two different orbits [2]. These include the along-

track orbit (ATO), in a 500 m and 1000 m configuration. Where an ATO is defined as one satellite,

the ‘deputy’, following the other, the ‘chief’, while both maintain the same attitude. The other

orbit is the projected-circular orbit (PCO) in a 50 m and 100 m configuration. Where a PCO is an

orbit where if observed from the earth one satellite, the ‘deputy’, looks as if it is orbiting around

the other, the ‘chief’. A minimum of ten orbits will be flown in each of the four configurations [2].

The CanX-4 and CanX-5 mission features not only very aggressive control accuracy, but also

aggressive timing requirements with a five second end-to-end closed loop navigation cycle time [3].

This mission is of great importance as it expands the state of the art and will demonstrate

the new technologies needed for future operational formation flying missions. These operational

missions could include Interferometric Synthetic Aperture Radar (InSAR), super-resolution imaging

and ground moving target indication, to name just a few [1].

The new technologies that will need to be developed in order to realize this mission are a new

propulsion system, an intersatellite communication system, some of the most complex guidance,

navigation and control software SFL will fly to date and a Hardware-In-The-Loop simulator, which

allows for on-orbit representative simulations of the entire mission. At the time of writing the

1

Chapter 1. The CanX-4 and CanX-5 Mission 2

CanX-4 and CanX-5 mission is scheduled to be launched on an Indian Polar Satellite Launch

Vehicle (PSLV) in 2013.

Thruster

Figure 1.1: CanX-4&-5 exploded view (Source: SFL)

1.2 Contributions

As Section 1.1 emphasizes, the success of the CanX-4 and CanX-5 mission requires many large

technical challenges to be addressed. The objectives of this thesis are:

• Implementing the guidance, navigation and control algorithms (GNC) on the resource-limited

Payload On-Board Computer (POBC) [1]

• Construction of a software architecture that allows for the integration and control of the

Global Positioning System (GPS) receivers, intersatellite link (ISL), formation flying algo-

rithms and propulsion system on the Payload On-Board Computer (POBC) [1]

• Development of an Intersatellite Link (ISL), which will allow CanX-4&-5 to establish au-

tonomous two-way communication for passing of time sensitive GPS and attitude information

[4]

• Design and implementation of a closed-loop simulation framework to verify overall system


performance, including the aggressive timing and control requirements [1]

A separate chapter will be dedicated to each of these major contributions to the mission, see

Intersatellite Link (Chapter 3), Payload On-Board Computer (POBC) (Chapter 4), and Hardware

In The Loop (Chapter 5).

1.3 Formation Flying

At the very heart of the CanX-4 and CanX-5 mission are the two formation flying algorithms,

RelNav, and FIONA (Figure 1.2). Both of these algorithms have been developed at the University

of Toronto Institute for Aerospace studies by Dr. J. Eyer and Niels Roth M.A.Sc.

The RelNav (Relative Navigation) algorithm estimates relative position and velocity in the

Earth Centered Earth Fixed (ECEF) frame using single-difference pseudorange and carrier phase

observables which are provided from the L1 GPS (Global Positioning System) signal. RelNav is an

Extended Kalman Filter with a fixed time step of five seconds and uses pseudo-relative dynamics

for propagation [5].

The FIONA algorithm computes the necessary control forces and desired attitude given the

output from RelNav, as well as the absolute position and velocity measurements from the GPS

receiver. These control forces are then passed on to the Momentum Management System (MMS)

(Section 1.7) and CNAPS (Canadian Nanosatellite Advanced Propulsion System) (Section 1.4).

FIONA has three modes, formation keeping for fine formation flying, reconfiguration which is used

to transfer between formations, and station-keeping which is used as a coarse formation flying mode

which keeps CanX-4 and CanX-5 from drifting apart [5].

During the operational phase of the mission one satellite will be designated the ‘chief’, while the

other satellite will be designated the ‘deputy’. The ‘chief’ is the lead satellite and is only responsible

for attitude adjustments. While the ‘deputy’ is the follower satellite and is responsible for mimicking

the ‘chiefs’ attitude, as well as performing the thrusts that guarantee that the formation is kept

within the sub-metre control accuracy required.


Figure 1.2: FIONA and RelNav Block Diagram (Source: SFL)

1.4 Payload

CanX-4 and CanX-5 are both Generic Nanosatellite Bus (GNB) spacecraft and have a volume

of 17x13x8 cm3 and a mass of approximately 2 kg available for payloads. The payload for this

mission is the cold gas Canadian Nanosatellite Advanced Propulsion System (CNAPS). CNAPS is

a second generation SFL propulsion system building on the lessons learned from NANOPS, which

was successfully flown on the CanX-2 mission. It employs liquid sulfur hexafluoride (SF6) as its

propellant, and has a maximum capacity of 300 ml [2]. CNAPS has four independent thrusters,

with each of the four thrusters residing on the -X face of the spacecraft in the shape of a plus sign

‘+’ (Figure 1.1). Each thruster will provide a thrust of 5 mN, with a total ∆V of approximately

13 m s−1 available for each spacecraft [2]. CNAPS serves two purposes, firstly it is responsible for

imparting the control forces (thrusts) on the spacecraft that have been commanded by the formation

flying algorithm, FIONA. These thrusts are essential to maintaining the formation. Secondly it

prevents the reaction wheels from saturating by allowing them to shed momentum. This is achieved

by thrusting in such a way that a net torque is imparted on the spacecraft. The torque that is

imparted is calculated by the Momentum Management System (MMS) running on the Attitude

Determination and Control Computer (ADCC) [2]. CNAPS is a passive element onboard the

spacecraft, only doing what it has been commanded to do, prepare for a thrust, thrust and return

telemetry when requested. In order to prevent uncommanded thrusts from occurring CNAPS is

only powered on when needed, and powered off after the thrust was commanded, regardless of the

success or failure of the commanded thrust.


1.5 Communications

Both spacecraft are equipped with a UHF, a GPS and two S-Band radios. The UHF radio and

its four antennas provide near omni-directional coverage and are used as the command uplink to

the spacecraft from the ground station. This 4000 bit per second (bps) uplink is used to issue

commands to the spacecraft, and to upload software patches if required on-orbit [2].

Each spacecraft will have a NovAtel OEMV-1G Global Positioning System (GPS) receiver and

antenna. The OEMV-1G is a low power 14-channel GPS receiver with L1 GPS and GLONASS

(GLObal NAviation Satellite System) capabilities. The receiver will be used to collect absolute

position information and raw data which are used for computing the relative position between both

satellites. The GPS receivers also enable the carrier phase differential navigation algorithm to be

employed onboard CanX-4&-5, RelNav.

One of the S-Band radios and its matching pair of antennas, mounted on opposing faces of the

spacecraft provide near omni-directional coverage and a 32-256 kbps downlink. This downlink, from

spacecraft to ground station, is used to transfer Whole Orbit Data (WOD) and other telemetry for

inspection, debugging and recording.

The second S-Band radio, and its matching pair of antennas, also placed on opposing faces

of the spacecraft (Different faces than the S-Band downlink), also providing near omni-directional

coverage are used for intersatellite communications. This is known as the Intersatellite Link, or

ISL. The ISL provides a 10 kbps link at a maximum distance of 5 km. The ISL is used to pass

crucial, time sensitive GPS and attitude data between the satellites, which allows them to close the

navigation cycle loop.

It should be noted that the standard GNB spacecraft (Figure 2.2) specifies an optional VHF

beacon which is used for identification purposes, this beacon is not being implemented on either

CanX-4 or CanX-5.

Figure 1.3 shows the location of all the aforementioned communication antennas, where Fig-

ure 1.1 shows the location of the communication hardware within the spacecraft. It should be noted

that the images in the figures are rotated 180 ◦ about the x-axis.


Figure 1.3: CanX-4&-5 radio antennas (Source: SFL)

1.6 On-Board Computers

There are a total of three On-Board Computers (OBCs) present on each satellite: a House Keeping

Computer (HKC) which manages overall spacecraft operations, an Attitude Determination and

Control Computer (ADCC) which is responsible for attitude estimation and control, and finally

a Payload On-Board Computer (POBC), which is responsible for managing the formation flying

algorithms and required hardware.

Each OBC is an SFL designed-and-built ‘OBC-300’ and is based around the ARM7TDMI

microprocessor. The ARM7TDMI is a very low power Reduced Instruction Set Computer (RISC)

which employs a three stage pipeline, Fetch, Decode and Execute, which increases instruction

throughput. The ARM7 core is a Von Neumann architecture with a single shared 32-bit data and

code bus. The ARM7TDMI natively supports a 32-bit instruction set, but has a ‘thumb’ mode

which allows it to execute in a 16-bit instruction set mode [6]. The ARM7 family does have native

Digital Signal Processing (DSP) support in both 32-bit and 16-bit modes, implementing ‘multiply-

accumulate’ instructions directly in hardware. The ’multiply-accumulate’ instructions are key DSP

instructions used for writing low-level matrix math operations in the ARM assembly language [6].

Unfortunately the ARM7TDMI does not support floating point arithmetic natively in hardware.

Floating point arithmetic is accomplished instead in software, which is slower than native hardware

support [6]. The ‘OBC-300’ uses a banked memory architecture with 9 address lines giving each

bank 512 KB of memory. The OBC uses two banks for the storage of code and data, which are


named the ‘RAM’ bank and ‘CS5’ bank.

All CanX-4&-5 On-Board Computers run CANOE, the CAnadian Nanosatellite Operating En-

vironment, which is an SFL custom built embedded real-time operating system (RTOS). This

RTOS is a priority based threaded operating system, which means that the scheduling algorithm

uses each thread’s priority to determine when it receives its processing quantum. CANOE sup-

ports many features one would expect from an operating system, timers, message passing, thread

synchronization, hardware peripheral support and interrupts. However CANOE does not support

an active memory management scheme, that is to say that CANOE does not allow for a ‘heap’,

which means no dynamic memory allocation during runtime. All memory management is done by

the compiler at code compilation time, and all data is placed on the ‘stack’.

1.7 Attitude Determination And Control

As was mentioned in Section 1.6 one of the On-Board Computers (OBCs) is used for the Attitude

Determination and Control System (ADCS). The GNB design (Section 2.5) specifies a suite of

ADCS sensors and actuators. These sensors include six fine and coarse sun sensor pairs, one pair

mounted per spacecraft face, a three-axis magnetometer mounted to the spacecraft via an external

boom, and three rate gyros which provide three-axis rate measurements (Figure 1.1). Attitude

control is exerted over the spacecraft by three pairs of orthogonally placed reaction wheels and

magnetorquers (Figure 1.1). Initially the magnetorquers are used for detumbling the spacecraft

after ejection from the launch vehicle. They are then additionally used to allow the reaction wheels

to shed momentum to prevent them for reaching their saturation point. As Section 1.4 highlights,

CNAPS will also play a roll in ensuring the reaction wheels never reach their saturation point.

Once the spacecraft has successfully detumbled it will rely solely on the reaction wheels to provide

three-axis attitude control. Preliminary analysis shows the spacecraft should have a worst case

pointing accuracy of approximately 3 ◦ RMS [7].

The Attitude Determination and Control Computer (ADCC) runs an Extended Kalman Filter

(EKF) for attitude determination and control, this piece of software is called OASYS, On-board

Attitude SYstem Software. Alongside OASYS is software unique to CanX-4&-5 mission, the Mo-

mentum Management System (MMS). The Momentum Management Software is responsible for

examining the current reaction wheel speeds and thrusts commanded by FIONA. It will then pro-

vide CNAPS with information on which combination of the four thrusters to actually fire. As


stated in Section 1.4 this allows the momentum wheels to shed momentum by imparting torques,

thus preventing them from saturation.

1.8 Nanosatellite Protocol (NSP)

The CanX-4/-5 mission employs the Nanosatellite Protocol (NSP) as the default communications

protocol between the satellites and ground stations, as well as for inter-computer and intra-computer

message handling. Currently there are four revisions of the Nanosatellite Protocol, they are all

point-to-point communication protocols originally designed for use with long path, loss-prone low-

bandwidth communications. The two later revisions of the protocol place no restrictions on maxi-

mum size where the minimum valid NSP packet size is 5 bytes in length. This consists of a 1 byte

source address, 1 byte destination address, 1 byte command and a 2 byte cyclic redundancy check

(CRC). The 16 bit CRC helps to detect errors in packet transmission over the different communi-

cation mediums considered, i.e. UHF, S-Band, and serial links. The NSP protocol operates at the

‘transport layer’ of the Open Systems Interconnection networking model (OSI Model)[8].

Chapter 2

Background

2.1 Formation Flying

Formation flying is the active control of relative position, velocity and attitude between two or

more spacecraft. There are no restrictions on the maximum size of any given formation, with

the minimum formation size being two spacecraft. Formation flying missions are becoming an

attractive alternative to monolithic spacecraft missions for several reasons: development times can

be reduced and cost savings can be realized by creating identical smaller spacecraft as opposed to

one large spacecraft. Flexibility, new spacecraft can be added to an existing constellation to replace

defunct spacecraft, or adding additional capabilities. Finally, it allows for a diversification of risk,

if one satellite fails the mission can continue with the rest of the formation delegating the failed

spacecraft’s work load.

Autonomous formation flying is a specialized case of formation flying, where one spacecraft

controls the formation autonomously with no immediate intervention from operators on the ground.

This is made possible by advanced software techniques that allow for spacecraft to switch between

a controller mode, ‘chief’, or a controlee mode, ‘deputy’. In the case of a ‘chief’ spacecraft failure,

another spacecraft can automatically become the new ‘chief’, and the formation can continue to

perform its mission.

2.2 UTIAS Space Flight Laboratory

Founded by Dr. Robert Zee (PhD) in 1998 with funding from Dynacon Incorporated, the Ontario

Research and Development Challenge Fund, and the Center for Earth and Environmental Technolo-

9

Chapter 2. Background 10

gies, the University of Toronto Institute for Aerospace Studies (UTIAS) Space Flight Laboratory

(SFL) played a major role in the design and development of the MOST satellite (Microvariablity

and Oscillations of STars) [9], Canada’s first return to space science since Canada’s Hermes satel-

lite was launched in 1976 [10]. After the success of MOST, and leveraging on the development of

the CubeSat design by Stanford University and California Polytechnic University (Cal Poly) [11]

UTIAS/SFL has become one of Canada’s most vibrant microspace organizations [12]. The Space

Flight Laboratory has continued to grow and gone on to develop two of its own nanosatellite buses,

the Generic Nanosatellite Bus (GNB) and the Nanosatellite for Earth Monitoring and Observation

Bus (NEMO Bus). At the time of writing SFL now has four operational satellites including MOST,

the Canadian Advanced Nanospace eXpirement-2 (CanX-2), the Canadian Advanced Nanospace

eXpirement-6/Nanosatellite Tracking Ships (CanX-6/NTS) and the Automatic Identification Sys-

tem Satellite-1 (AISSat-1), with diverse missions including astronomy, technology demonstrations

and earth observation.

2.3 Microspace

What is being seen now is a trend towards smaller and cheaper spacecraft, or what is known as

microspace [13]. To date there are well over 50 microsatellites and nanosatellites on-orbit [14].

A microsatellite is defined as a spacecraft having a mass of 100 kg or less, and a nanosatellite

having a mass of 10 kg less. These spacecraft have been built by countless organizations around

the world, for academia, government and private industry. The microspace philosophy is derived

from a capabilities driven approach, in contrast to the more conventional requirements driven

design employed by larger spacecraft [9]. These spacecraft often leverage commercial-off-the-shelf

(COTS) components instead of more expensive specially designed radiation hardened components.

Utilizing new COTS technologies gives two main advantages: firstly helping to keep costs down,

and secondly, allowing for rapid integration of new state of the art technology into spacecraft [9].

A microspace spacecraft can be designed, built and launched much more rapidly than their larger

conventional counterparts [13]. For example, the CanX-6 nanosatellite was taken from concept to

launch on only seven months [15].


2.4 CubeSats

Initially conceived in 1999 by Professor Jordi Puig-Suari of Cal Poly, San Luis Obispo and Professor

Bob Twiggs, both of Stanford University, the CubeSat (Figure 2.1) design was an attempt to create

a standardized method for designing picosatellites (satellites under 1.3 kg) in an effort to reduce

overall cost and development time [11]. The new CubeSat design allows for low cost rapid access to

space for relatively small payloads, enabling an entirely new demographic of space consumers. The

specification defines four sizes of CubeSat, the standard 1u, (10x10x10 cm), as well as, .5u, 2u and

3u, with each being a scaled version of the 1u design with dimensions (5x10x10 cm), (20x10x10 cm)

and (30x10x10 cm) respectively [11].

Figure 2.1: A typical 1u CubeSat, Norwegian NCUBE2 (Source: Bjorn Pedersen)

2.5 Generic Nanosatellite Bus

As the Space Flight Laboratory continued to take on new missions of increasing complexity, CanX-

3/BRITE and CanX-4&-5, the need for a standard, yet highly configurable nanosatellite bus arose.

This led to the development of the Generic Nanosatellite Bus, or GNB (Figure 2.2). The GNB is a

20x20x20 cm cube with an approximate 7.5 kg total mass (payload included) which can generate

at least 5 W of power. It has been designed using a stackable tray architecture, where the compo-

nents on each of the trays (Figure 2.3) can be configured for each individual missions own specific

needs[16]. The GNB occupies a volume of 8000 cm3 which is over two and a half times larger than

the 3u CubeSat bus that was used for CanX-2 mission, which was roughly 3000 cm3. This allows


the GNB architecture to provide an approximate payload volume of 1768 cm3 with a payload mass

of 2 kg in the form of a rectangular prism of dimensions 17x13x8 cm [16].

Although the GNB is highly adaptable on a per mission basis, there are however many common

components that are shared on each GNB spacecraft. These include a House Keeping Computer

(HKC) for satellite management, an Attitude Determination and Control Computer (ADCC) for

attitude determination and control, VHF, UHF and S-Band radios and antennas for satellite beacon,

uplink and downlink respectively. The GNB also provides a full complement of sensors and actuators

which allows it to have three-axis control, including sun sensors, a magnetometer, reaction wheels

and magnetorquers.


Figure 2.2: Exploded GNB Architecture (Source: SFL)

Figure 2.3: GNB Tray Configuration (Source: SFL)


2.6 The CanX Program

The Canadian Advanced Nanospace eXpirement (CanX) program is Canada’s first and only nanosatel-

lite space program to date. Started by Dr. Robert Zee at the Space Flight Laboratory in 2001 its

three main goals are to provide graduate students with hands on spacecraft development, enable

low-cost access to space for scientific research and to test new technologies which further enable

new CanX missions [17]. Currently to date there are six CanX missions involving seven CanX

spacecraft, CanX-1, CanX-2 (Section 2.7.1), BRIte-star Target Explorer (BRITE), CanX-4&-5,

NTS and CanX-7.

2.7 Relevant Current Missions

2.7.1 CanX-2

CanX-2 (Figure 2.4) is a three-axis stabilized 3u triple CubeSat (10x10x30 cm, 3.5 kg) technology

demonstration mission launched onboard the Indian Polar Satellite Launch Vehicle (PSLV) PSLV-

C9 on April 28th 2008 as part of the SFL Nanosatellite Launch System (NLS) NLS-4. Its primary

mission was to preform scientific experiments, including [18];

• Performing Low-Earth Orbit Global Positioning System scientific experiments for future mis-

sions (CanX-4 & CanX-5)

• Performing atmospheric science experiments including spectrometry and imaging

CanX-2 was also used as a proving ground for future enabling technologies [18]. One of which is

currently now in use on-orbit on follow up missions, while the latter paved the way for a second

generation nanosatellite propulsion system being used on the CanX-4&-5 mission;

• A new nanosatellite reaction wheel (Now part of the Generic Nanosatellite Bus)

• A novel nanosatellite propulsion system (NANOPS)

Upon commissioning CanX-2 became the first operational CanX program spacecraft, and is still

operating to date [9].


Figure 2.4: CanX-2 (Source: SFL)

2.7.2 AISSat-1

AISSat-1 (Figure 2.5) (Automatic Identification System Satellite-1) is a Norwegian satellite for the

tracking of seaborne assets in Norwegian waters. It is being built by the Space Flight Laboratory

on behalf of the Norwegian government as a technology demonstration of the AIS technology, and

will lead to larger operational missions [19]. AISSat-1 also leverages the GNB design, making it

the second operational mission next to CanX-6 to leverage this design. AISSat-1 was launched on

July 12th 2010 onboard PSLV-C15 as part of NLS 6 and was detecting ships 24 hours after launch

[19]. AISSat-1 is currently flying the same GPS hardware that will be employed by the CanX-4&-5

mission.

Figure 2.5: AISSat-1 (Source: SFL)

Chapter 3

Intersatellite Link

3.1 Introduction

The success of the CanX-4 and CanX-5 mission relies on the ability of the spacecraft to establish

autonomous two way communication which is required for sharing critical time sensitive GPS and

attitude information. The Intersatellite Link, or ISL, is an S-Band transceiver that was purposly

designed and built by SFL to satisfy this requirement. The ISL is comprised of a C8051 microcon-

troller and two Texas Instrument Industrial Scientific Medical (ISM) band transceiver chips each

with their own independent antenna. The ISL has a data rate of 10 kBaud at a maximum distance

of approximately 5 km and employs advanced transceiver chip hardware features such as Forward

Error Correction (FEC) and Cyclic Redundancy Checks (CRC) to ensure successful data transfer

[20].

3.2 ISL Hardware

This section will discuss the hardware components of the ISL that affect the software design.

These components include the microcontroller and transceiver chips, but will not include any of the

analog, passive or power components. The ISL has two natively defined hardware modes, transmit

and receive. Figure 3.1 shows a block diagram of the ISL hardware, this diagram highlights the

transceiver and antenna layout. It is important to note that although the ISL has two independent

transceiver chips (Named U2 and U6) only one of the chips is responsible for transmission (U2).

The signal is routed to both antennas via a power splitter when the hardware is in transmit mode.

In hardware receive mode, each antenna is connected to their own respective transceiver chip.

16

Chapter 3. Intersatellite Link 17

Figure 3.1: ISL Hardware Block Diagram (Source: SFL)

Microcontroller

The microcontroller used on-board the ISL is a Silicon Labs C8051F411 microcontroller (Figure 3.2).

The F411 is a low power pipelined microcontroller aimed at the automotive industry, it has an

internal oscillator clocked at 24.5 MHz with 128 bytes of internal RAM (IRAM), 2 KB of external

ram (XRAM) and 32 KB of flash. The F411 has a full complement of digital peripherals, the

peripherals of interest include; Universal Asynchronous Receive Transmit (UART) serial port,

Serial Peripheral Interface (SPI), four 16-bit timers, on-board core temperature sensor, external

interrupts and a 12-bit analog to digital convertor (ADC). The F411 supports non-intrusive, full

speed, in-circuit debugging using the Silicon Laboratories 2-Wire (C2) interface [21].


Figure 3.2: ISL C8051F411 Pinout (Source: SFL)

Peripheral Usage

UART Used to communicate with the Payload On-

Board Computer (POBC)

SPI Used in a 3-wire master mode with manual chip

select to command both CC2500 transceiver

chips

Timers Used to control baud rates for serial ports i.e.

(UART, SPI)

Temperature Sensor Used to monitor the ISL’s internal temperature

External Interrupts Used by the CC2500 chips to indicate transmis-

sion or reception of an L1 frame

Analog to Digital Convertor Used by the ISL to monitor various telemetry

points to help diagnose potential problems with

the unit

Table 3.1: ISL C8051F411 Peripheral Usage


Transceivers

The ISL has two separate Texas Instruments CC2500 very low-power Industrial Scientific Medical

(ISM) band 2400-2483.5 MHz transceivers. The CC2500 chips are aimed at low-power consumer

electronics, wireless controllers and RF enabled remote controls [22]. The CC2500 transceivers

offer a highly configurable baseband modem with a configurable data rate of up to 500 kbaud. The

CC2500 offers multiple modulation schemes including OOK (On-Off Keying), 2-FSK (2 Frequency-

Shift Keying), GFSK (Gaussian Frequency-Shift Keying) and MSK (Minimum-Shift Keying). The

64 byte transmit and receive FIFOs (First In First Out Queues) and the transceiver chips themselves

are controlled by a 4-wire slave SPI bus [22]. The transceivers will use a data rate of 10 kbaud as

defined in the hardware requirements for the ISL.

Patch Antennas

As mentioned previously the ISL employs two independent SFL designed S-Band patch antennas

(Figure 3.3). The antennas are placed on opposing faces of the CanX-4 and CanX-5 spacecraft,

the +X face and -X face (Figure 1.3). These two independent antennas allow for greater spatial

coverage which serves to improve the link quality, and allow for a near omni-directional gain pattern

(Figure 3.4). Figure 3.4 provides a visualization of the gain pattern for the ISL, it can be observed

that there is omni-directional coverage with a minimum gain of approximately -8 dBi.

Figure 3.3: ISL S-Band Patch Antenna (Source: SFL)


Figure 3.4: ISL S-Band Patch Antennas Gain Pattern (Source: SFL)

3.3 Bootloader

Like all SFL electronic devices the ISL is required to run a bootloader so that the device can be

powered-on into a known good state. A bootloader provides a means of communicating with other

components via NSP and allows for new application code to be programmed into flash memory.

This is extremely useful as it allows for software patches to be uploaded while the spacecraft are

on-orbit. All SFL bootloaders are now required to implement the Nanosatellite Protocol (NSP)

and implement the NSP defined ‘ping’, ‘peek’ and ‘poke’ commands.

3.3.1 Sinclair F411 Bootloader

Originally the ISL was going to use a custom version of the Sinclair Interplanetary F411 bootloader

which is currently used on SFL’s reaction wheels. This bootloader was chosen because at the time

no other stable F411 bootloader existed and this bootloader already had flight heritage on SFL

spacecraft. However due to the nature of the modifications, the Sinclair bootloader would have

to go through the qualification process again. This coupled with the creation of the new Generic

Firmware Interface (GFI) bootloader which supports the F411 microcontroller ultimately led the

ISL away from using the Sinclair F411 bootloader.


3.3.2 Generic Firmware Interface

With the creation of the new Generic Firmware Interface (GFI) bootloader which supports both

C8051F411s and C8051F580s the decision was made to use this as the bootloader for the ISL. This

decision was made for two main reasons; firstly because no changes to the GFI were needed, meaning

that there was no additional qualification process needed for running the GFI on the ISL. Secondly

because there is an internal push at SFL to run a single bootloader on as many SFL components

as possible. This change of bootloader would affect the overall design of the ISL application code

as there is a disparity in features that the GFI provides over the Sinclair bootloader, i.e. the GFI

parameter system. Also, the hooks that the ISL application code needs to use to tie into the

GFI are also different from the Sinclair bootloader hooks. Both of these changes are minimal, but

highlight the importance of knowing which bootloader the ISL application code will be interacting

with.

3.4 ISL Software

3.4.1 ISL Flight Software System Requirements

Before any design can actually take place, the requirements of the ISL as a whole system have to be

defined. The requirements serve two purposes: firstly they define what the system must actually do,

and secondly, they provide a testing checklist and a metric to gauge when the system is complete.

The base from which all the ISL requirements are derived is that, ‘the ISL must provide an attitude

independent communications link between CanX-4 and Canx-5’. The following is the complete list

of the ISL system level requirements where shall implies a strict requirement, and should implies a

desire.

1. The ISL should provide an attitude independent lossless communications link at a distance

of up to 5 km [23]

2. The ISL shall provide a communication link with a data rate of at least 10 kBaud [23]

3. The ISL shall be able to provide any of the on-board telemetry on demand (Low Noise

Amplifier voltage, Linear Regulator voltage, Power Amplifier voltage, Detector voltage and

internal F411 core temperature) [23]

4. The ISL shall have only two modes ‘Receive/Idle’ and ‘Transmit’ [23]


5. The ISL default mode shall be ‘Receive/Idle’ [23]

6. The ISL shall allow for on-orbit configuration of transceiver chip registers, get and set, (In

engineering units where possible) [23]

7. The ISL shall communicate with the Payload On-Board Computer (POBC) with a baud rate

of 115,200 kBaud [23]

8. The ISL shall be a valid Nanosatellite Protocol (NSP) device [23]

9. The ISL should use a previously qualified bootloader [23]

3.4.2 Literature Review

In order to properly design the flight software a literature review was needed first in order to

establish the current state of the art. This literature review would not focus on other intersatellite

communication systems as a whole, but focus instead on the communications protocol that they

implemented. This was for two reasons, the ISL hardware had already been designed and built and

therefore could not be changed. Secondly the communication protocol was the only component of

the ISL system left yet to be specified.

The literature review revealed that the idea of establishing interconnectivity between satellites

was not new, in fact it had been successfully demonstrated by radio amateurs in 1975 [24]. The

National Aeronautics and Space Administration (NASA) also pursued intersatellite communications

that same year, with a follow up mission the Lincoln Experimental Satellites (LES) in 1976 [24].

Unfortunately due to the age of these Intersatellite Links very little relevant information could be

applied to the SFL ISL due to the major paradigm shift in networking that took place in 1978 and

1984. The Open Systems Interconnection Model, or OSI Model for networking was first published

in 1978, with another redefined standard being published in 1984 [25]. This new layered approach

to communication protocol stacks has become the standard approach used in the networking and

telecommunications industries today [26].

Further review revealed many different low level protocols that are currently being used on-

orbit, to date X.25/LAP-B, TCP/IP, ATM (Asynchronous Transfer Mode) and even IEEE 802.11

have flight heritage [27][28].

• X.25/LAP-B is a protocol suite for packet switched wide area networks i.e. the public switched

telephone network (PSTN) [29]


• TCP/IP is one of the most popular wide area networks to date (i.e. the ‘Internet’). It

provides end to end connectivity and specification of how data should be formatted, addressed,

transmitted and routed [30]

• ATM is a time division multiplexed protocol designed to bridge the gap between computer

and telecommunication networks, however it has fallen out of favour and been mostly replaced

by TCP/IP [31]

• IEEE 802.11 is the set of standards for defining wireless local area networks (WLAN) i.e.

(WiFi) [32]

All of these protocols and standards share a common theme in that they are terrestrial based,

none of them were designed explicitly for spaceborne applications. The majority are based on wide

area networks servicing a multitude of simultaneous users across large physical distances, different

cities, countries, or even continents. These protocols suites also have sizable implementations that

are not suitable for the resource limited flight hardware of the CanX-4 and CanX-5 mission. They

also include advanced features such as flow control, collision avoidance and lossless delivery of data.

While these features are indispensable in the terrestrial based applications they support, they only

serve to add complexity and slow down end to end transmission time. Again this is not suitable for

the CanX-4/-5 mission as one of the requirements is a five second end to end closed loop navigation

cycle, which includes ISL transmission time. Therefore any added delays due to these advanced

features would prove to be counterproductive.

Although none of these existing protocols proved to be suitable for the CanX-4 and CanX-5

mission, as they are too large and too slow. They do however share something else in common that

can be of use, they are either protocol stacks based on the OSI model, or define a standard which

fits into a layer of the OSI model. For example, TCP/IP specifies four of the seven OSI Model

Layers (Data Link Layer, Network Layer, Transport Layer, and Application Layer) [26][30]. Where

IEEE 802.11 defines the physical standards for wireless communication, which is the first layer or

‘Physical Layer’ of the OSI Model [26][32].

With the information gained from the literature review a preliminary design could now be

produced, and it would be based on the OSI Model which to date is the current state of the art in

intersatellite communications.


3.4.3 OSI Model

The literature review determined that the current state of the art for intersatellite communications

is built using the OSI Model. The OSI Model is a product of the Open Systems Interconnection

effort to characterize and standardize the functions of a communication system in terms of abstract

layers [26]. Each layer is a collective group of related functionality, each layer services the layer

above it, and is serviced by the layer below it [26]. The OSI Model defines seven layers, but

practically speaking only five or less are implemented. Figure 3.5 shows the complete seven layer

OSI model and how information flows ‘down’ the stack when being transmitted, and how it flows

‘up’ the stack when being received.

Figure 3.5: OSI Model Diagram (Source: catalyst.washington.edu)

Each of the layers shown in Figure 3.5 serves a unique purpose, and is responsible for segmenting,

framing or converting the data according to the protocol implemented in that layer;

• Layer 1: (Physical Layer) is responsible for defining the electrical and physical specifications

for the particular medium used in communication i.e. this layers is responsible for the actual

transmission and reception of ‘bits on the wire’ [26]

• Layer 2: (Data Link Layer) is responsible for data transfer between two network entities and

physical addressing of these entities [26]

• Layer 3: (Network Layer) is responsible for logical addressing of network entities, path deter-

mination, and providing the means to transfer variable amounts of data from one entity to


another [26]

• Layer 4: (Transport Layer) is responsible for providing an end-to-end connection, and data

transfer reliability including flow and congestion control [26]

• Layer 5: (Session Layer) is responsible for establishing, managing, and terminating the con-

nections between local and remote applications [26]

• Layer 6: (Presentation Layer) is used to convert data from machine dependent, to machine

independent (little to big endian, or vice versa) as well as data encryption if required [26]

• Layer 7: (Application Layer) is the end user application and consumer of the data as such

the OSI Model places no specifications on this layer, other than it exists [26]

As mentioned before typically only five layers or less are actually implemented, usually the

layers 5 and 6 (Session and Presentation) are not implemented.

3.4.4 Software Development Plan

Once the ISL software requirements have been defined and the literature review completed a plan

for the software development process can be completed. This plan breaks the development of the

ISL software down into three distinct phases, or iterations. Iteration 1 is the initial revision of the

Engineering Model software as well as the board bring-up process. Iteration 2 is an extension of

the first revision of the Engineering Model software. This software will extend the functionality of

the first EM software, and be a stepping stone for the third and final phase, which is the creation

of the ISL Flight Software. At each iteration not only does embedded software for the ISL have to

be created, but unique Ground Support Equipment (GSE) software has to be created, or existing

software leveraged. Figure 3.6 shows both the embedded software and GSE software that needs

to be developed at each stage in the ISL software development life cycle. Each piece of software

shown in Figure 3.6 will be described in detail later in this chapter.


Figure 3.6: ISL Software Development Plan Overview (Source: SFL)

3.4.5 Engineering Model Software Revision 1 & Board Bring-up

During the construction of the ISL software development plan it became apparent that two different

versions of software were required, a Flight version and an Engineering Model (EM) version. The

EM software serves two main functions; it is a verification tool used to confirm the overall hardware

design of the ISL is operational and within specifications, also known as board bring-up. Secondly

it allows the user to control the radios in a way not indicative of on-orbit operations in order to

perform in depth testing of the unit. The EM software would not tackle the added complexities

of the two independant receiver capabilities of the ISL. For the EM boards basic hardware testing

only one of the CC2500 chips would be operational at any time. The EM software assumed for the

purposes of this basic thermal testing that if one transceiver chip was functional over temperature,

that both would be functional.For the flight models a more rigorous testing regime will be used to

verify both transceiver chips operate within specification over temperature.

The software development process for the EM software was done following the Agile software

development model. The Agile model is based on iterative and incremental development where the

requirements and developed software evolve with the project over time [33]. The Agile software

model lends itself to rapid prototyping and quick deliverables, with a new release at least every one

to four weeks [33]. All software development for the ISL is done in the Silicon Laboratories IDE

using the ‘C’ programming language.

The first stage in the EM development was for the author to become familiar with all the


hardware discussed in the previous sections. This was required as the author had no prior experience

with either the C8051 microcontroller family or the Texas Instruments transceiver chips.

The next step in the EM software was defining the requirements of the software. These would

define what the software must accomplish in order to successfully verify that the EM boards are

working within spec over initial temperature testing. The base requirements for the first version of

the EM software were:

• Initializing the microcontroller and all the required peripherals, UART, SPI and ADC

• Initializing one of the CC2500 transceiver chips

• Being able to command the CC2500 into either a continuous transmit or receive mode

• Being able to report all hardware telemetry points in realtime

The next phase of the EM software was to split the board bring-up process into two distinct

phases. First the microcontroller would be brought up followed by the transceiver chips. This

was chosen as the logical order in which to proceed because the microcontroller was required to

communicate with the ISL over the UART serial port, and the microcontroller was also the master

SPI device in the microcontroller transceiver chip hardware arrangement.

In order to bring up the microcontroller and verify that it was working properly a minimal

amount of boiler plate code was needed in order to power on the ISL and perform basic serial

communicate with the unit. This included:

• Setting the microcontroller to use the internal oscillator clocked at 24.5 MHz

• Enabling the missing clock detector interrupt

• Disabling the watchdog timer

• Configuring the UART serial port at a data rate of 115,200 kBaud

• Enabling interrupts

Once this was completed additional functionality was then added to verify that the radio fre-

quency (RF) power stages were working properly. Thus, the analog to digital convertor was brought

up next. This allowed the gathering of internal ISL telemetry, which included:

• The voltage being supplied to the Low Noise Amplifier (LNA V)

• The voltage being supplied to the microcontroller and transceiver chips (LR V)

• The voltage being supplied to the Power Amplifier (PA V)


• A voltage which is proportional to the final RF output power. This allows the ISL to determine

if the power amplification chain is working correctly (DET)

• The internal temperature of the C8051 core (TEMP)

In addition to the telemetry gathering features, new interrupt based reporting functionality

using the UART was required. This was because the existing functionality simply sampled each

telemetry point and saved it to RAM. While this allowed for the verification of the hardware

telemetry points, it did so only by using the real-time C2 debugger interface. The new reporting

system was required because real-time reporting and permanent storage of on-board telemetry is

essential to the thermal verification processes employed at SFL. The new reporting functionality

consisted of continually transmitting the raw telemetry out on the UART port as soon as the ADC

sampling was complete.

Once this was completed attention was turned to the bringing up the CC2500 transceiver chips.

This required configuring the microcontrollers Serial Peripheral Interface (SPI). The ISL is a 5-wire

SPI configuration, a Master-Out Slave-In (MOSI) line, a Master-In Slave-Out (MISO) line, a clock

line (SCLK) and finally two chip select lines (CS 1) and (CS 2). The F411 architecture provides

hardware support for the MOSI, MISO and SCLK lines. However due to the nature of the dual

slave devices (Both CC2500 chips) on the same SPI bus, the chip select is not supported natively

in hardware. This means that the ISL software must manually toggle the chip select lines in order

to select which transceiver chip it wishes to communicate with. The ISL software must safeguard

against the possibility of both chip select lines being selected at the same time as this would result

in a collision on the MISO line. Several key functions are required in order to properly communicate

with the CC2500 chips:

• Driving a transceiver chip select line low and waiting for the ready to accept command

response i.e. ‘enabling’ a transceiver for SPI communication

• Transmitting and receiving bytes of data via the Serial Peripheral Interface (SPI)

• Driving a transceiver chip select line high and waiting for the not ready to accept command

response i.e. ‘disabling’ a transceiver for SPI communication

After the Serial Peripheral Interface (SPI) software was completed and verified by polling the

status byte from both transceiver chips, programming of the transceiver chip registers took place. As

mentioned in Section 3.2 the CC2500 transceivers are highly configurable with over 30 read/write


registers controlling their operation [22]. While many of the registers maintained their factory

default settings, the rest had to be re-programmed. Since the transceivers reset to their factory

default state on power-up this re-programming must take place on every hardware power cycle,

twice, once for each CC2500 chip on-board the ISL. The registers that were required to be changed

are explained in Table 3.2.


CC2500 Registers

Register New Value Effect

0x0002 0x06 Tells the transceiver to signal a transmission

complete or successful reception event by puls-

ing a GPIO (General Purpose Input Output)

line

0x0006 0x3C Sets the fixed packet length of the transceiver to

64 bytes

0x0007 0x04 Tells the transceiver to append the 2-byte Re-

ceived Signal Strength Indicator (RSSI) and

Link Quality Indicator (LQI) to each received

packet

0x0008 0x44 Enables Cyclic Redundancy Check (CRC) and

data whitening

0x000D 0x5C High byte of carrier frequency control (Carrier

is 2.41 GHz)

0x000E 0xB1 Middle byte of carrier frequency control (Carrier

is 2.41 GHz)

0x000F 0x3B Low byte of carrier frequency control (Carrier is

2.41 GHz)

0x0011 0x93 Sets the transceiver chip data rate to 20 kBaud

(Realized data rate is half of this due to Forward

Error Correction (FEC))

0x0012 0x03 Enables mandatory 30/32 sync word bits de-

tected prior to reception

0x0013 0xA2 Enables Forward Error Correction (FEC)

0x003E 0xFE Sets the default transmit power to full power

(1 dBm)

Table 3.2: ISL CC2500 Register Values


The final step in the EM Rev 1 software and board bring-up was to actually command the

CC2500 chips to transmit and receive thus closing the loop between two units. This last piece of

software was written so that a unit could be placed into either a transmit state or a receive state

indefinitely. This commanding was done via the UART serial port by sending either the character

‘r’ or ‘t’ for receive and transmit respectively. A hardware power cycle was needed in order to

reset the transmitters into their default idle state. The transmit and receive functionality was not

interrupt based, but based on polling of the transceiver chips status byte. Although the transceivers

chips were setup to use RSSI, LQI, and CRCs (Table 3.2) they were not checked or used in any

manner in this version of the software. The telemetry reporting system of the software was changed

to give it a dual purpose, it would continue to provide real-time on-board telemetry from the unit.

But it would no longer continuously transmit on the serial connection when it was done an ADC

conversion. Instead it would now report the telemetry only on either a successful transmission or

reception of a packet. This allowed for a visual confirmation via the Ground Support Equipment

(Section 3.4.5) that the link was actually closed and the two ISL units were actually communicating.

Although at this point the communication was only unidirectional. Verification that both receive

and transmit functionality was in fact working on both ISL units could be confirmed by simply

reversing the roles each ISL played, i.e. the transmitter becomes the receiver and vice-versa.

The successful completion of this software and board bring-up enabled preliminary thermal

qualification and the overall hardware design to be tested and verified. Upon the conclusion of this

testing the ISL hardware was shown to be within its specification both at room temperature and

on-orbit temperature ranges.

Engineering Model Ground Support Equipment

As described in Section 3.4.5 the first revision of the ISL Engineering Model (EM) software was

designed to use a basic UART serial connection. The user would simply command an ISL into

an indefinite transmit or receive state and then receive telemetry from the radio. As such no

Ground Support Equipment (GSE) in the form of a serial communication terminal needed to be

created. The user was free to pick their own serial terminal of choice for communication with

the ISL EM software. Figure 3.7 shows a simple freeware serial terminal application which was

used to communicate with the ISL EM software during its development. This terminal program

simply enumerated all available COM ports and allowed a variable buad rate connection to be


established, it supported two way communication as well being able to display received data in

either hexadecimal or ASCII formats. The terminal software connects to the ISL with a buad rate

of 115,200 using 8 data bits, no parity bits, 1 stop bit and no handshaking.

Figure 3.7: Engineering Model Revsion 1 GSE (Source: SFL)

However, in order to connect the ISL to a computer serial port, a single piece of GSE was

required. This is an SFL based TTL (Transistor to Transistor Logic) to RS-232 convertor. This

would allow the computer to communicate with the ISL using the RS-232 protocol.

Also mentioned in Section 3.4.5 is the fact that EM software would simply write raw on-board

telemetry values to the terminal. A dump file of raw values in this form is not helpful for determining

if the telemetry points are within specification, or if there are trends occurring in the data. A simple

C++ program was written which would read in these dump files, parse them, and create a comma-

separated values (CSV) file for each of the five unique points (LNA V, LR V, DET, PA V and

TEMP). These files could then be loaded into a graphing program of choice such as MathWorks

MatLab, or Microsoft Excel for visualization and data manipulation. This type of simple parser was

chosen because it leveraged on existing data manipulation and graphing tools in order to produce

rapid results, instead of writing custom data manipulation and graphing GSE software, which

would take a considerable amount of time. Figure 3.8 shows a sample plot of ‘Detector Voltage

Vs. Telemetry Point Index’ that was generated in Microsoft Excel from the output CSV file of


the C++ GSE parser. This type of plot is highly useful because it allows for quick visualization

of trends within the ISL hardware and quickly allows verification that the ISL hardware is within

specification. Figure 3.8 is not meant to convey any meaningful information on the telemetry that

was gathered, but rather give an idea of what these plots look like.

Figure 3.8: Detector Voltage Plot Generated by EM GSE (Source: SFL)

3.4.6 Engineering Model Software Revision 2

After the successful completion of the thermal qualification process the current version of the

Engineering Model (EM) software and its supporting Ground Support Equipment (GSE) was not

sufficient in order to thoroughly characterize the RF performance of the Intersatellite Link (ISL).

Or to perform the required Long-Form Functional Tests (LFFT) which are needed for thermal

acceptance. The deficiencies that needed to be addressed in the second revision of the EM software

and its accompanying Ground Support Equipment became the new requirements for this version

of the software, as per the software development plan:

• Real-time decoding and reporting of on-board telemetry in engineering units (Voltage and

degrees Celsius)

• Real-time calculation of Bit Error Rate (BER) and Packet Error Rate (PER)

• Provide statistics on the number of packets received

• Transmission of a known number of bits in a known random byte pattern

• Addition of the ability of the ISL to transmit an unmodulated carrier

• Ability to dynamically switch between either CC2500 chips so that both transceivers could

be tested for functionality


• Ability to put the ISL into any mode without a power cycle (With the exception of unmod-

ulated carrier mode)

• Real-time calculation of the CRC failures in packet reception

• Ability to provide statistics on the RSSI and LQI. Both instantaneous and average, and the

ability to graph these statistics in real-time

• Ability to read and write registers on the transceiver chips

• Ability to record in real-time packets being received by the ISL

• Ability to log on-board telemetry to file in real-time

The points above highlight the need for not only additional functionality to be added to the

ISL Engineering Model software, but for the creation of ISL specific Ground Support Equipment

software due the real-time nature of the data processing now required.

Within the ISL Engineering Model software, functions that dealt directly with hardware can

be reused, i.e. configuring the microcontroller and its ports, the UART driver, the SPI driver and

Analog to Digital Convertor (ADC) driver. The main ISL Engineering Model application software

would need to be rewritten and a protocol for a new two-way communication between the Ground

Support Equipment and the ISL would have to be defined. The ISL Engineering Model software

would now have to implement a state machine in order to handle the new modes. Finally, the ISL

Engineering Model software needed a more flight indicative interrupt based implementation instead

of the polling method previously used. This move towards an interrupt based solution would be

used as a prototyping stepping stone of the transmit and receive functions needed for the final ISL

flight software.

Since the ISL needs to be configurable on the fly with the ability to read and write CC2500

chip registers and send back telemetry to be decoded in real-time, a simple protocol needs to be

established. This is defined in the form of an unencoded variable length packet based protocol.

Each packet starts with a unique one byte character identifying the type of packet. Once identified

the total number of bytes expected in the packet can be determined solely based on the type, where

valid packet sizes are 1-65 bytes inclusive. As mentioned previously this protocol is not encoded.

This means that no framing bytes are used to signal the beginning or end of a packet, and there

are no special byte patterns that can be used as escape sequences. Due to minimal number of

packet types, and the small amount of data per packet adding any type of encoding would serve

no purpose. Table 3.3 gives an overview of the new protocol and the structure of each packet.


ISL Engineering Model to Ground Support Equipment Protocol

Command Length Pattern Description

‘Reset’ 1 0x68 Resets the currently selected

CC2500 chip registers

‘Receive’ 1 0x72 Sets the currently selected

CC2500 chip into receive

mode

‘Transmit’ 1 0x74 Sets the U2 CC2500 chip into

transmit mode

‘Unmodulated Carrier’ 1 0x75 Sets the U2 CC2500 chip to

transmit an unmodulated car-

rier

‘Chip Select’ 1 0x63 Toggles the active CC2500

chip between U2 and U6

‘Continuous Transmit’ 1 0x77 Toggles the U2 CC2500 chip

between continuous transmit

and normal transmit mode

‘Register Read’ 2 0x76〈1-byte

address〉

Request the value from the

register address on the se-

lected CC2500 chip (Request)

‘Register Return’ 2 0x76〈1-byte

value〉

Responds with the value re-

quested in the ‘Register Read’

command (Response)

‘Register Write’ 3 0x70〈1-byte

address〉〈1-byte

value〉

Sets the specified register with

the new value on the selected

CC2500 chip

‘Telemetry’ 4 0x74〈1-byte

ID〉〈2-byte value〉

Sends the raw telemetry

point, which is decoded by its

unique telemetry identifier

‘Payload’ 65 0x70〈64-byte

payload〉

Forwards a packet that was

received from the CC2500

chip

Table 3.3: ISL Engineering Model Rev 2 Serial Protocol Definition


It should be noted that some of the commands share the same ‘Pattern’ byte, this is allowed

because of the type of command. The ISL will never query the GSE software for a register value,

therefore the GSE software will always know this packet is a response to a previous request. This

also works in reverse, the ISL software knows that the GSE software would not be sending it

telemetry, instead the ISL knows the GSE software is commanding it to transmit.

Once the new protocol had been defined and tested the new interrupt based transmit and

receive functions could be written. The external interrupts on the F411 were configured to trigger

on the rising edge of a signal from the CC2500 GPIO line, which had previously been configured

for interrupts (Table 3.2). The CC2500 raises an interrupt whenever a packet has been transmitted

or received successfully. However the CC2500 has no way of signaling which of these two cases

occurred. The ISL EM software must use its own internal state to determine if the signal is

reception or transmission.

The new implementation also uses what Texas Instruments calls a ‘burst access’ which allows

for large amounts of data to be transferred over the Serial Peripheral Interface without having to

toggle the chip select lines on a byte by byte basis [22]. This new method of data transfer helps to

decrease overall lag in the ISL as it allows the transmit and receive FIFOs to be emptied or filled

in a single, quicker, ‘burst access’. In addition, new safeguards were put in place in the event that

the CC2500 experienced a Transmit FIFO underflow, or a Receive FIFO overflow. The former is

when the transmitter unexpectedly runs out of data to transmit, i.e. only 60 bytes were provided

when 64 were expected. While the latter occurs when there is not enough space left in the Receive

FIFO to accommodate the entire packet. Both of these scenarios put the CC2500 in a state where

it can no longer transmit or receive until the error is corrected. These new safeguards check to

see if the CC2500 is in one of these error states, and if it is, sends the necessary commands to

clear the FIFOs and reset the CC2500’s internal state machine, successfully protecting against the

transceiver chips from becoming unresponsive.

As shown in Figure 3.1 the ISL has two CC2500 transceiver chips, only one of which is actually

responsible for transmitting (U2). However the new ISL EM code allows for dynamically changing

which transceiver chip is active, allowing a user to switch from U2 to U6. If for some reason the

user commanded U6 into a transmitting state, damage to the hardware could occur because this

was not the intended use of U6 CC2500 chip. Therefore mechanisms had to be put in place in

the new Engineering Model software which would not allow the CC2500 chip U6 to ever be placed


in a transmit state. So whenever the active transceiver chip is U6, all transmit command packets

are dropped in the UART driver onboard the ISL Engineering Model software, thus ensuring that

U6 will never be commanded into a transmit state. Similar mechanisms were put in place in the

Ground Support Equipment software as well, whenever the user selected the U6 transceiver chip

the GSE software would not allow for transmit commands to be sent to the ISL Engineering Model

Software. Both error checking mechanisms were tested and successfully prevent U6 from being

commanded into a transmit state.

As previously stated one of the requirements of the new ISL Engineering Model software is the

ability to command the radio to and from any state without needing to power cycle the ISL. The

only caveat to this is with regard to the ‘Unmodulated Carrier’ mode. If the ISL is commanded into

this mode it must be power cycled in order to properly reset all of the hardware. This is required

because there is no way to undo the changes required in the CC2500 registers which place it into

this special case mode [22].

With the completion of the second revision of the ISL EM software the necessary functionality

was now present to allow the RF characterization and Long-Form Functional Tests (LFFTs) to

be completed. Both are necessary steps in the thermal acceptance campaign required for all flight

hardware.

Engineering Model Ground Support Equipment

In order to make use of the extra functionality provided by the new ISL EM software and fulfill

the new requirements, additional EM Ground Support Equipment (GSE) software was needed.

As the only existing GSE software was no longer applicable this meant an entirely new system

could be architected. As almost all of the new requirements were for real-time data analysis and

visualization a move away from C++ was warranted. This was due to the large amount of effort

and time required to make usable Graphical User Interface (GUI) programs with C++, even when

using the Win32 or MFC frameworks. The platform that was chosen was Microsoft’s .Net languages,

specifically C#.Net. C# offers a wide variety of benefits for creating non-computationally intensive

programs including:

• A drag and drop interface for creating content rich Graphical User Interfaces (GUIs)

• An object oriented language with full access to all of Microsoft’s Application Programming

Interfaces (APIs)


– Easy access to serial port classes

– Built in graph controls for data visualization

– Classes for time based events and file handling

• Event driven architecture

• Automatic garbage collection

• Easily deployable applications with the only prerequisite being Microsoft’s .Net runtime

The development of the ISL EM software made use of the Rapid Application Development

(RAD) model, which encourages minimal planning in favour of rapid prototyping. This allows

the planning and requirements phase to be interleaved with the actual software development. This

methodology was chosen because like the Agile method used for the ISL EM software, it is a quicker

method of development for relatively simple software. This coupled with the fact that it allows for

almost immediate integration of new features and big fixes made it the ideal methodology.

The ISL EM software was built in phases using the RAD model. Each phase was the imple-

mentation of a distinct feature or requirement (Requirements 3.4.6). This phase would then be

released to the users where they would provide immediate feedback on the release. This feedback

would then be rolled into the new release along with the next feature to implemented. This allowed

the users to start the RF characterization and become familiar with the application before the final

software was released.

Figure 3.9 shows the completed version of the ISL EM software during an LFFT. Some of the

highlights of the new EM software include:

• Ability to save the entire ‘COM Rx Buffer’ to file for post processing (Top right corner of

Figure 3.9)

• Automatic logging to file of all on-board telemetry values every 10 seconds

• Enumerates all connected COM ports and offers variable baud rate connections ( Top left

corner of Figure 3.9)

• Uses a multi-threaded dispatch and decode architecture to guarantee no payload packets from

the ISL are dropped

• Provides instantaneous and average telemetry for RSSI and LQI, including graphing the last

100 instantaneous RSSI and LQI points as well as their averages (Bottom half of Figure 3.9)


• Allows for the payload packets from the ISL to be displayed in either ASCII or hexadecimal

formats

• Guards against commanding the U6 CC2500 transceiver chip into a transmit mode

Figure 3.9: ISL EM Software Revision 2 Ground Support Equipment Software (Source: SFL)

3.4.7 Flight Software

Design

After the completion of the two EM revisions of the ISL software, the design of the flight software

can proceed. It is based on the OSI Model (Section 3.4.3). The OSI Model specifies the functionality

that each layer must provide, but it does not specify how that functionality is provided. It also

defines a seven layer communication model, but it is not a requirement that a design must implement

all seven layers. Therefore the design for the flight software chooses which layers are applicable to

the CanX-4 and CanX-5 mission, and defines the requirements for the protocol stack.

The method for determining which layers are required for the ISL protocol stack, and which

can be omitted, is to start at L1 (Physical Layer) and work up the OSI Model layer by layer until


a layer is reached that defined features that are not required by the CanX-4/-5 mission.

Starting at L1, the ‘Physical Layer’ is responsible for physical bit transmission and reception.

This layer is clearly required because without the ability to transmit and receive bits, the very

building blocks of digital communication, data transfer is not be possible.

L2 is the ‘Data Link Layer’, or (Media Access Control Layer) it is responsible for transferring

data between two network entities. This layer is also required because the CanX-4/-5 mission is

a peer-to-peer communication system, which by definition means the transfer of data between two

entities.

L3, the ‘Network Layer’ is responsible for providing logical addressing and a mechanism to

transfer variable amounts of data from one entity to another. This layer is needed because the

ISL system requirements state that ‘The ISL shall be a valid Nanosatellite Protocol (NSP) device’.

This is the very definition of the Nanosatellite Protocol (NSP).

L4, the ‘Transport Layer’, this layer is responsible for end-to-end connections and reliability,

which means flow and congestion control. As Section 3.4.2 highlighted, this is one of the main

reasons why none of the protocols that were found in the literature review were suitable candidates

for the ISL. The addition of the data reliability services offered at this layer greatly increases the

complexity of the protocol, which increases code size, required buffer size, and end-to-end data

delivery time. All of these violate either the timing constraint placed on the closed loop navigation

cycle time, or the physical limitations of the F411 microcontroller. Since this layer will be omitted

from the protocol stack the flight software will have to look at other ways to handle dropped or

corrupted packets.

Layers 5 and 6 add additional functionality such as connection management and data encoding,

neither of which is required for the ISL.

Layer 7 is defined as the end consumer of the data services provided by the lower layers in

the protocol stack, without a consumer the data would be useless and there would be no point

in communication. In the case of the ISL, the consumer of the data is the Payload On-Board

Computer (POBC). For completeness this layer is included in this document, but it will not be

included in the ISL protocol stack because it is external to the ISL.

Therefore the ISL protocol stack will be a three layered stack consisting of OSI Layers, Layer

1, Layer 2 and Layer 3, or as they will be referred to in the ISL protocol stack, PHY, MAC and

NSP respectively. Figure 3.10 shows the layout of the ISL protocol stack. Figure 3.10 also shows


two additional modules at L3, the ‘ADC’ and ‘GFI/API’ modules, these modules will be explained

shortly.

Figure 3.10: Layers of the ISL Protocol Stack (Source: SFL)

The ‘ADC’ module is the analog to digital convertor software which allows the ISL to monitor

its hardware telemetry points. This is in response to ‘The ISL shall be able to provide any of

the on-board telemetry on demand (LNA V, LA V, DET, TEMP, PA V)’ requirement. The ADC

module runs at this layer because the entry point for any external system into the ISL is at L3.

Therefore moving this functionality into any other layer would be unwarranted as it would only

push it further away from the consumer of the data.

The ‘GFI/API’ module is the main and only entry point into the ISL, all requests and responses

to the ISL must pass through this module. This includes requests for telemetry from the ADC

module. For all intents and purposes to the outside world, this is the ‘ISL’. All ISL NSP commands

are implemented in this module, including the commands that allow for the fulfillment of ‘The

ISL shall allow for on-orbit configuration of transceiver chip registers (In engineering units where

possible)’ and ‘The ISL shall be able to provide any of the on-board telemetry on demand (LNA V,

LA V, DET, TEMP, PA V)’ requirements. Where the actual telemetry for the latter requirement

is provided by the ADC module.

Once the overall physical layout of the protocol stack is complete the internal state-machine of

the ISL software can be defined. The two main driving system level requirements ‘The ISL shall have

only two modes ‘Receive/Idle’ and ‘Transmit’’ and ‘The ISL default mode shall be ‘Receive/Idle’’

place restrictions on this state-machine. Figure 3.11 shows the ISL software state-machine.


Figure 3.11: ISL Software State Diagram (Source: SFL)

As can be seen from figure 3.11 the ISL does only have two modes, and ‘Receive’ is the default

mode, thus fulfilling the aforementioned requirements. It is important to notice that upon a packet

reception the ISL automatically transitions back into ‘Receive’ mode. It is even more important to

notice that the only way into the ’Transmit’ mode is via an external transmit command issued by

the Payload On-Board Computer (POBC), and upon transmission the ISL automatically transitions

back into the ‘Receive’ mode. This behaviour is a deliberate design choice based on the fact that

the underlying ISL hardware is a radio. If the ISL could spuriously or autonomously transition

itself into ‘Transmit’ mode, or even worse, get stuck in ‘Transmit’ mode there is the possibility of

jamming the other radios on-board the spacecraft, most likely the other S-Band transceiver. Or

even worse, due to the increased current consumption of the ISL in ‘Transmit’ mode, completely

deplete the spacecraft battery.

At this point only a few of the ISL system level requirements have not been fully addressed, the

two requirements regarding the ISL data rates, one for the over-the-air interface, and the other for

Payload On-Board Computer (POBC) connectivity have not been mentioned because they should

have no effect on the design of the ISL software. Meaning there should be no coupling between the

ISL software and the physical data rates at which the hardware is operating. Any such dependency

would tightly couple the ISL software to its hardware, which goes against the software engineering

principles of modular and reusable code.

This leaves only one requirement yet to be fulfilled, arguably the most important requirement,

‘The ISL should provide an attitude independent lossless communications link at a distance of up

to 5 km’. This requirement affects the design of the protocols used in both the PHY and MAC


layers of the ISL protocol stack. As mentioned before L3 is going to use the already existing SFL

NanoSatellite Protocol (NSP).

The first step in defining the protocols used in L1 (PHY) and L2 (MAC) is defining the interface

between all of the layers. Establishing an interface before designing the protocols ensures that there

is loose coupling between each of the layers, allowing for the possibility of reuse in future radio

development. For example, if the interface between the MAC and PHY layer makes no assumptions

about the underlying hardware used in the PHY layer, a completely new transceiver chip could

be seamlessly integrated. This would be achieved by writing a PHY layer for the new chipset

that implements the proper interface. In this example, a next generation ISL that uses an X-Band

transceiver would require only the rewriting of the PHY layer and could leverage the other two layers

with no change. By the same token, if a new mission called for a constellation of three satellites,

the MAC layer could be rewritten to handle message addressing instead of broadcasting, again no

changes to any other layer would be required. By defining an interface first, the implementation

details are made abstract and thus a black box is created at each layer. This is known as the

software engineering principle of ‘programming to an interface, not an implementation’.

The PHY layer of the ISL protocol stack is responsible for dealing directly with the CC2500

transceiver chips. It provides an interface for the MAC layer to be able transmit and receive

L2 frames. As well as providing services to the MAC layer it must also provide the ability for the

‘GFI/API’ module to get and set registers on either of the CC2500 transceiver chips. The functions

that the PHY layer must implement in order to meet the MAC layer’s needs are;

• Initialize each CC2500 chip’s registers with the predetermined values required for the CanX-

4/-5 mission (Table 3.2).

• Transmit an L2 frame received from the MAC layer over the over-the-air interface.

• Receive an L1 frame from the over-the-air interface and pass it up to the MAC layer.

• Explicitly and implicitly place the CC2500 chips into receive mode. Where an explicit transi-

tion into receive is done after a transmission, and an implicit transition is done after a receive

(Figure 3.11).

The functions that are required by the ‘GFI/API’ module’s needs are;

• The ability to get and set register values on either CC2500 transceiver chip.


The MAC layer of the protocol stack is responsible for taking a valid NSP packet and segmenting

it into L2 frames, which will then be passed to the PHY layer for transmission. It is also responsible

for receiving multiple L2 frames from the PHY layer and reassembling them into a valid NSP packet,

which will then be passed to the NSP layer for forwarding to the Payload On-Board Computer

(POBC). Therefore the only two functions that the MAC layer is required to implement are;

• Ability to disassemble an NSP packet and forward the L2 frames down the stack.

• Ability to reassemble L2 frames into an NSP packet to forward up the stack.

The ‘GFI/API’ module of the protocol stack is responsible for validating incoming and outgoing

NSP packets. It will verify that the NSP packet is meant to be transmitted over the over-the-air

interface, as well as verify that a received NSP packet is valid via the CRC. The functions that the

‘GFI/API’ module is required to implement are;

• Determine if an incoming NSP packet should be transmitted over the over-the-air interface,

or interpreted as a command destined for the ISL.

• Validate reassembled NSP packets from the over-the-air interface via their CRC and forward

them if valid.

Figure 3.12 shows the ISL protocol stack and the interface for each layer. This is a Unified

Modeling Language (UML) diagram which defines the interface in terms of a functions name, scope

(global or local) and arguments(name and type). This diagram was made for the ‘C’ programming

language and as such uses C standard types and the ‘*’ character to denote a pointer.


Figure 3.12: ISL Protocol Stack Application Programming Interface (Source: SFL)

The L3 functions are:

• nspPacketRx - This function is a callback that is called from L2 upon successful reassembly

of all L2 frames in a transmission into an L3 packet. This function validates the L3 packet

using the L3 Cyclic Redundancy Check (CRC) and forwards the packet out on the UART

serial interface if it is valid, or drops the packet if the CRC is not valid.

• serialNspRx - This function is a callback that is called by the GFI when it receives an NSP

packet over the serial interface that is not a recognized GFI command. This function analyzes

the packet, if addressed to the ISL it interprets the command, if not addressed to the ISL it

is forwarded out over the air.

The L2 functions are:

• transmitL2Frame - This function is called by L3 when it wants to transmit an L3 packet over

the air. This function breaks down the L3 packet into L2 frames and passes those frames on

to L1 for forwarding over the air.

• initializeMAC - This function is used by L3 to initialize the MAC layer and register the

nspPacketRx callback function. The MAC layer initializes all its internal variables and stores

the callback function pointer.


The L1 Functions are:

• setReg - This function is used to set a register on the CC2500 transceiver chips.

• getReg - This function is used to get a register value from the CC2500 transceiver chips.

• initializePHY - This function is used by L2 to initialize the CC2500 transceirver chips and

the PHY internal variables.

• enablePacketHandlers - This function is used by L2 to enable the packet handling routines

in the PHY layer and register a callback function that is called whenever L1 receives a frame

from the over-the-air interface.

• transmitL1Frame - This function is called by L2 when it wants to transmit an L2 frame out

over the air.

• listen - This function is called by L2 at the end of a transmission session to power off the

ISL’s RF power amplifier stage.

ISL Protocol Stack Requirements

After the physical structure of the protocol stack has been laid out and the interfaces between each

layer have been established the software requirements for the entire protocol stack can be defined.

The requirements are for the newly designed stack as a whole, but are comprised of requirements

for each specific layer.

1. L2 shall abort reception of any incoming packets (including, if necessary, the flushing of any

accumulated frame buffers) upon the command to transmit [34]

2. L2 shall drop any L2 frames that are not a plausible part of an L3 packet, statistics on this

shall be kept[34]

3. The ISL shall provide statistics on the number of L3 packets received over the over-the-air

interface with a correct L3 CRC [34]

4. The ISL shall provide statistics on the number of L3 packets received over the over-the-air

interface with an incorrect L3 CRC [34]

5. The ISL shall provide statistics on the number of L3 packets it is requested to transmit [34]

6. The ISL shall provide statistics on the number of frames received with a correct L1 CRC [34]

7. The ISL shall provide statistics on the number of frames received with an incorrect L1 CRC

[34]


8. The ISL shall provide the Received Signal Strength Indicator (RSSI) and Link Quality Indi-

cator (LQI) for the last frame received for each antenna [34]

9. The ISL shall drop L3 packets that are too large to transmit. Althought the NSP protocol

places no restriction on maximum packet size, due to the hardware limitations of the F411

an upper limit was imposed on NSP packets being sent to the ISL. Statistics on this shall be

kept [34]

10. The ISL shall listen to, and respond to, NSP packets addressed to it that arrive over the

serial (UART) link. These packets will be used for gathering telemetry, setting up the ISL,

and issuing ISL commands [34]

11. The ISL shall forward over the radio link any NSP packets that arrive on the serial (UART)

link, and are not addressed to the unit. These packets shall be forwarded only if the CRC of

the NSP packet is correct (the latter is used to ensure that the destination address is correct)

[34]

12. The ISL shall ignore packets addressed to it that arrive over the over-the-air-interface. This

is because it was decided that each spacecraft shall only be allowed to command its own ISL.

[34]

13. The ISL shall only transmit one packet at a time [34]

14. Upon reception of the last L1 frame of an L3 packet on the over-the-air interface, the ISL

shall transmit the reassembled packet on the serial link. There is no requirement that the

ISL be able to receive or transmit a different NSP packet until this is complete [34]

15. Reassembled NSP packets that arrive at L3 shall not be transmitted on the serial (UART)

link if the NSP Cyclic Redundancy Check (CRC) is not correct. Statistics shall be kept on

dropped packets [34]

16. The maximum sized NSP packet that ISL can handle shall not be greater than 250 bytes [23]

17. The ISL should use the Forward Error Correction (FEC) and Cyclic Redundancy Check

(CRC) provided by the CC2500 chip [23]

3.4.8 Implementation

Once the design and requirements for the protocol stack have been completely laid out, the imple-

mentation can take place.

The PHY is the starting point. This is because it is the first layer in the stack, and also because


the EM software serves as a prototype on which to build. In fact, the EM software implements in

one form or another, all of the functions that the L1 flight code needs. The transmit and receive

functions can be taken almost as is from the EM software, although the L1 frame size has increased

from the 62 bytes used in the EM software, to the maximum size of 64 bytes. Small changes to the

receive software are also needed in order to gather the telemetry defined by the ISL protocol stack

requirements, RSSI and LQI. The get and set register functions need to be rewritten to meet the

new interface, and the ability to explicitly command the radio into a receive state needs to be added

as well. In order to implement the ISL software state machine the external interrupt handlers for

the CC2500 transmit/receive line had to be written so that if the ISL is already in a ‘receive’ or

‘Rx’ state that it would never leave this state, and if it was in a ‘transmit’ or ‘Tx’ state it would

then go to an idle state, where it would remain until commanded back into ‘receive’.

This happens for two reasons, firstly due to the nature of the state machine of the CC2500

chips themselves. After a successful reception of a packet the CC2500 state machine then flows to

an idle state, so in order for the ISL to meet its own state machine requirements it must command

the CC2500 out of its idle state back into its ‘receive’ or ‘Rx’ state, this is said to be an implicit

state change as the ISL hardware never leaves receive mode. The second reasons for this is that the

PHY layer is responsible solely for transmitting and receiving one packet at a time. The underlying

hardware of the ISL requires the F411 to toggle a general purpose input output (GPIO) pin to

actually put the hardware into a receive or transmit state i.e. toggling the low noise amplifier or

power amplifier on or off. When the PHY it is transmitting it has no idea of the number of packets

it will be requested to transmit in a row. This is why the PHY layer exposes a function that

transitions it from idle back into receive, once the MAC layer has finished asking the PHY layer to

transmit all of necessary L2 frames, it can then put the ISL back into ‘receive’ (thus conforming to

the ISL software requirements and successfully implementing the ISL state machine). This is said

to be an explicit state change as the ISL hardware has gone from transmit to receive.

It should be noted that four bytes of total framing takes place at L1. During transmission the

CC2500 prefixes the frame with two bytes of preamble. Upon reception the preamble bytes are

removed while two bytes are appended to the end of the frame, the RSSI and LQI.

The MAC layer is more complicated to implement. This is because a method for disassembling

a valid NSP packet for transmission by the PHY layer, and reassembling multiple PHY layers

frames back into an NSP packet needed to be defined and implemented. Does the protocol make


use of ACK’s (acknowledgement) or NACK’s (negative acknowledgement), sliding windows or even

frame retransmission? How are the NSP packets disassembled and framed in such a manner that

they are properly reassembled again? How are the L2 frames reassembled bearing in mind that the

MAC layer will be receiving packets from two separate CC2500 receivers? The answers to these

questions define how the ISLs communicate over the over-the-air interface with each other.

As previously mentioned, the CanX-4/-5 mission has very aggressive timing constraints on its

closed loop navigation cycle time, which is 5 seconds. If the MAC layer protocol implements ACK’s

or NACK’s this would mean that the number of packets required for a transmission would double,

as every packet transmitted would require another packet specifying successful or unsuccessful

reception. Automatically this increases transmission time, and this is without factoring in extra

computational time required for a more complicated ACK/NACK based protocol. If the receiving

ISL merely sends a request at the end of a transmission session indicating which L2 frames are

missing, this again would increase the transmission time, as you would always send one more

frame than required to specify if any frames were missing. This also does not take into account

the additional time required to retransmit any of missing frames. As can be seen, any of these

features which might help the ISL establish a more reliable communications link are not feasible to

implement within the closed loop navigation cycle time constraint, this is because the link is too

slow. For example, the ISL is expected to transmit no more than 550 bytes of data at one time

[23]. At a data rate of 10 kBaud (Specified by the ISL hardware requirements), this transmission

takes approximately 500 ms (ignoring signal propagation time). If the ISL had to retransmit all

of the frames, assuming that all frames were dropped during transmission, it would take over 1

second to successfully close the loop. This represents 20 percent of the closed loop navigation time,

which does not even take into account processing delays required for NSP packet disassembly and

reassembly. However it should be noted that although there is no specific requirement on how much

of the cycle time the ISL can consume, it should close the link as quickly as possible. Clearly it

can been seen that the main driving force of the MAC layer is in fact the closed loop navigation

cycle time. Simulations have shown that the FIONA/RelNav algorithms can withstand up to a

10 percent ISL dropout rate, that is to say, if no data is available via the ISL 10 percent of time,

the sub-metre control accuracy constraint is not negatively affected. Therefore the MAC layer will

take the approach of transmitting the data as fast as possible, and if the data is not successfully

received, the FIONA/RelNav algorithms can simply drop that navigation cycle. This means that


the MAC layer protocol will not implement any of the reliability features described previously. It

will instead only provide a mechanism for NSP packet disassembly and reassembly, and will simply

‘broadcast’ these disassembled frames with no feedback from the receiving ISL. Although proven

via simulation this 10 percent dropout rate fault tolerance will be tested with flight hardware via

the Hardware In The Loop Simulator.

It can be shown from the hardware requirements that the ISL can establish a link that provides

better than 90 percent success. Thereby validating the decision to use ‘broadcasting’ at the MAC

layer. The required bit error rate (BER) of the ISL hardware shall be no worse than 10−5 [35].

The probability that a message will successfully arrive at the receiver can be calculated by (1 −

BER)total number of bits. Assuming a transmission of 600 bytes, 550 bytes of data, plus an assumed

50 extra framing bytes added at the PHY and MAC layer yields (1 − 10−5)4800, which results in

the probability of a successfully received message of approximately 0.9531. This is a 95.31 percent

chance that the packet will be received properly, which is greater than the 90 percent shown to be

required in simulations, thus validating the design decision.

In order to decide what framing needs to take place at the MAC layer, the minimum amount

of information required to reassemble an NSP packet from multiple L2 frames needs to be de-

termined. Obviously knowing in which order to arrange the L2 frames is essential, therefore a

sequence number is required. As all L1 frames are a fixed size, the size of the payload inside the

L1 frame cannot be implicitly determined, thus an L2 payload size is required. As the MAC will

be reassembling multiple L2 frames into a single L3 packet, a mechanism for determining which L3

packet a received L2 frame belongs to is required. Therefore a one bit alternating packet identifi-

cation flag will be used. As mentioned previously, the MAC layer will be receiving frames from two

independent transceivers, with the possibility of receiving the same frame from both. A mechanism

for determining which frame to use is required if two identical frames are received. Also mentioned

previously is that the PHY layer upon reception of an L1 frame adds two framing bytes of its

own, RSSI and LQI, which are measures of the received signal strength, and how easily the modem

could demodulate the baseband from the carrier, respectively. These two L1 framing bytes will be

used by the MAC to determine which L2 frame to use, with priority going to the frame with the

strongest RSSI. This means that an L2 transmit frame and an L2 receive frame are not identical,

with the L2 receive frame having two extra framing bytes, the framing bytes appended at L1. Thus

an L1 and L2 receive frame are identical. These five items, sequence number, payload size, packet


ID flag, RSSI and LQI, represent the minimum amount of framing information required to properly

reassemble multiple L2 frames into an NSP packet.

Figure 3.13 shows the flow of data and the framing that takes place at each layer during

transmission and reception of an NSP packet. Care should be taken to note the differences between

a transmit and receive frames at both the MAC and PHY layers.

Figure 3.13: Framing of data in the ISL protocol stack (Source: SFL)

As described in the previous section, and illustrated in Figure 3.13 the MAC layer implements

the most critical algorithms in the ISL software. Two sections in the Appendix (Chapter 7) will

provide a pseudecode overview of how NSP packet disassembly and reassembly take place.

Although the ISL will have the NSP layer implementation provided to it by the bootloader. It

does still need to implement some functions at this layer, such as implementing the custom ISL

NSP commands. This is the ‘GFI/API’ module of Layer 3, the following list are the commands the

ISL defines, if the ISL receives an unknown command it will NACK and increment the unknown

command counter.


• Get/Set a CC2500 transceiver chip register value.

• Get/Set the output power of a CC2500 transceiver in dBm.

• Get/Set the centre frequency of a CC2500 transceiver chip in MHz.

As defined in the requirements, if a packet arrives at the ISL that is not addressed to the unit,

it will forward the packet out over the over-the-air interface. Upon completion of the transmission

the ISL will send an NSP packet to the device that requested the transmission informing them that

the ISL has completed transmission, and is now again ready to transmit.

The ADC module simply cycles through all of the hardware telemetry points and samples their

value, these raw values are then stored using the GFI parameter system.

As described, the closed loop navigation cycle time is the main driver in defining the ISL MAC

layer protocol. However, F411 hardware is the main driver in the implementation of the protocol

stack. As the ISL protocol stack has to share the F411 hardware with the GFI, the code space

available to the ISL protocol stack is cut in half from 32 KB to 16 KB, while the available RAM is

also cut in half, with only 1 KB being available to the entire ISL protocol stack.

3.4.9 Intersatellite Link Telemetry

The ISL makes use of the GFI parameter system for the storing telemetry. Table 3.4 shows where

each telemetry point is stored in the GFI parameter system. This telemetry can be accessed at

any time using the GFI ‘Get Parameter’ command. The GFI defines 16 parameters available for

application code, starting at GFI parameter index 16, and ending at index 31.


ISL Telemetry Points

GFI Parameter Index ISL Telemetry Point

16 Number of L1 packets received with a correct L1 CRC

17 Number of L1 packets received with an incorrect L1

CRC

18 Last RSSI for transceiver U2

19 Last RSSI for transceiver U6

20 Last LQI for transceiver U2

21 Last LQI for transceiver U6

22 Number of invalid L2 frames received

23 Raw PA V telemetry ADC reading

24 Raw LNA V telemetry ADC reading

25 Raw LR V telemetry ADC reading

26 Raw DET telemetry ADC reading

27 Raw TEMP telemetry ADC reading

28 Number of L3 packets the radio has been asked to

transmit

29 Number of L3 packets received with a correct L3 CRC

(NSP CRC)

30 Number of L3 packets received with an incorrect L3

CRC (NSP CRC)

31 Number of invalid/unrecognized commands the radio

has received

Table 3.4: Mapping of ISL Telemetry to GFI parameter index

3.4.10 Testing

The development of the ISL flight software incorporates a rigorous testing regime that is comprised

of unit, integration and system level testing. This is done to ensure the final quality of the ISL

protocol stack.


Unit Level Testing

Since the PHY layer is based mainly on existing functionality, it has already been thoroughly tested

and shown to be stable. However the changes made do warrant a requalification. This process

consists of a small piece of embedded software that tests the PHY layers ability to transmit, receive

and properly change state.

The MAC layer protocol is also unit tested to make sure that it is performing correctly. The

MAC algorithms are tested in isolation from the hardware. A PC based C++ unit tester has been

written, this unit tester simulates the L3 and L1 layers. It asks the MAC layer to disassemble a

packet, print the L2 frames to the screen, reassemble the packet and verify that the pre-disassembled

packet and the reassembled packet are identical. Figure 3.14 shows the C++ MAC layer unit tester

during a test campaign.

Figure 3.14: The MAC layer unit tester software (Source: SFL)

Integration Level Testing

Once the MAC and PHY layers had been unit tested and shown to be operating as designed, the

two layers were integrated with each other. With these layers the ISL should be able to take a

non NSP packet, disassemble it, transmit it over the air, receive it, reassemble it and forward it

on. Leveraging the previously built Engineering Model Ground Support Equipment software as a

starting point, a C#.Net integration test application was built, (Figure 3.15). From the figure, the


top panel manages the connections to the three ISL units needed for unit testing. The bar on the

right hand side shows a graph in real-time of the number of test cases passed and the number of

test cases failed. Finally, in the middle of the figure is the main console window which displays to

the user the current test under execution, what was received, and if the test passed or failed.

Figure 3.15: The PHY and MAC layer integration tester software (Source: SFL)

The physical layout of the integration test requires three ISL units: A device under test (DUT),

this is the unit actually being tested, and two tester units. The engineering model ISL units (EM

ISLs) were used as the two tester units. These tester ISL units run custom embedded software that

merely forward an L1 frame over the over-the-air interface. These two units are required because

the ISL has two transceiver chips, and control over the input into each of these transceivers is

essential to the testing process. This helps validate the MAC and PHY layers ability to properly

handle data coming from two independent sources. It also allows for control over exactly which

L1 frame goes to which transceiver chip, U2 or U6. This allows for simulation of frame dropouts


and poor reception at an antenna due to spacecraft attitude. Figure 3.16 shows the physical layout

of the integration test setup. It is important to note that three units are required because simply

splitting the signal from one EM unit into both U2 and U6 on the DUT does not allow for ability

to send different packets to each transceiver chip, nor drop a packet to either receiver via software,

as it would have to be done at the hardware level which would not allow for full automation of the

integration test setup.

Figure 3.16: Physical layout of the integration test setup (Source: SFL)

The integration test campaign is composed of 18 specific tests. These are defined to be repre-

sentative of the on on-orbit conditions that the ISL would encounter. These tests are based around

three different scenarios of six separate tests. The six tests include:

1. Transmission of frames into transceiver chip U2 only

2. Transmission of frames into transceiver chip U6 only

3. Transmission of frames into both transceivers simultaneously

4. Transmission of frames into transceiver chip U2 while injecting an appropriate frame into U6

at random intervals (Simulating poor reception on U6)

5. Transmission of frames into transceiver chip U6 while injecting an appropriate frame into U2

at random intervals (Simulating poor reception on U2)

6. Interleaving L1 frames into transceiver chips U2 and U6 randomly to make a complete L2

transmission (Simulates needing to use both receivers together to reassemble a complete

packet i.e. poor reception on both receivers simultaneously)

These six tests were done in three different test campaigns, including:


1. Transmitting all the L1 frames in order (Nominal operations)

2. Transmitting some of the L1 frames in order, then restarting the transmission of all the L1

frames in order (Simulates a complete loss and reestablishment of the communication link)

3. Transmitting L1 frames in order and purposely dropping only one L1 frame at random (Tests

the ISL’s ability to recover from dropped frames while not losing the communication link)

The integration test software takes these 18 individual tests and runs them in a completely

random order. This is to remove any coupling of the order of the tests being run, to the success

or failure of that test. After the 18 tests are run, the order is re-randomized, and run again. This

cycle continues indefinitely until the user stops the testing process manually.

System Level Testing

Once the NSP layer is added the ISL can now move into the final stage of formal testing. The NSP

layer did not go through any of the same testing that the other layers where subjected to because

NSP is an already established protocol and it is implemented by the Generic Firmware Interface

‘GFI’ that went through its own qualification process.

The system level testing process of the ISL is meant to test the complete end-to-end communica-

tion link. Again, another C#.Net application was created, this application forwards a well-formed

NSP packet to an ISL that then transmits it over the air to a second ISL. The application waits for

the receiving ISL to forward it the received packet, where it then compares the forwarded packet

with the received packet, to verify that they are identical. This process repeats indefinitely and

upon the completion of each test the receiving and transmitting ISLs swap rolls. Figure 3.17 shows

the system level testing software, while Figure 3.18 shows the physical layout of the test setup. In

this setup only flight models of the ISL are used (FM ISL). During system level testing the ISL

showed a packet delivery rate of between 99.9 and 99.99 percent. One would expect the results in

a laboratory setting to be 100 percent, this is not the case for the ISL as its frequency range is

also in the same range as other equipment in the laboratory such as cordless phones and wireless

routers which interfere with the signal. These results are very promising because they show delivery

success rates which are well above the minimum 90 percent packet delivery success required by the

formation flying algorithms.


Figure 3.17: The ISL flight software system test software (Source: SFL)

Similar to the unit level testing software Figure 3.16, the system level testing software is straight

forward. As before, the top bar manages the connections to the each Flight Model (FM) Device

Under Test (DUT). While the right side bar displays the number of tests passed and failed, and the

main console window shows which unit is transmitting, which unit is receiving, what was received,

and if the test passed or failed.


Figure 3.18: Physical layout of the system level test setup (Source: SFL)

Not shown in Figure 3.18 is the attenuation between Flight Model ISL 1 (FM ISL 1) and Flight

Model ISL 2 (FM ISL 2). This is because the test setup is independent of attenuation, any amount

of attenuation can be placed between the two ISLs. This allows system level testing to be done at

any range up to and including the 5 km maximum ISL range. The attenuation used during the

test in Figure 3.17 was 40 dB, which translates to a relative separation distance of approximately

350 metres.

3.5 Conclusion

At the time of writing, the ISL has now been integrated into the Hardware-In-The-Loop simulator

(Chapter 5) and is now undergoing full mission level simulations. These mission simulations have

helped in tracking down any lingering bugs and have given confidence in the overall design of the ISL

software. During these simulations the ISLs perform with a packet delivery rate of approximately

99 percent which is greater than the 90 percent required, thus successfully closing the navigation

cycle loop between CanX-4 and CanX-5.

Chapter 4

Payload On-Board Computer

4.1 Introduction

The Payload On-Board Computer’s or (POBC’s) main responsibility is running the formation flying

algorithms FIONA and RelNav. This also includes the management of the hardware connected

to the POBC, such as the GPS receivers, the ISL (Intersatellite Link), and CNAPS (Canadian

Nanosatellite Advanced Propulsion System). The POBC is an SFL designed and built ‘OBC-300’

which is used primarily on the Generic Nanosatellite Bus (GNB) missions, and is based on the

ARM7 processor. The ‘OBC-300’ uses a banked memory architecture with only two banks of

512 kB available, one for code and the other for data. The POBC runs the CAnadian Nanosatellite

Operating Environment (CANOE), which is an SFL custom built embedded real-time operating

system (RTOS) which consumes more than half of 512 kB code space.

4.2 Formation Flying Algorithms

4.2.1 OBC Target Integration Overview

The formation flying algorithms, FIONA and RelNav, were first realized in the MathWorks MAT-

LAB environment. These MATLAB scripts were then converted to the C programming language

for further development, testing and upgrades. This conversion created versions of the FIONA and

RelNav algorithms that were targeted for a X86 based PC target, not the ARM7 based OBC target

where they would ultimately need to reside.

The FIONA and RelNav algorithms had to go through at least one more conversion process

60

Chapter 4. Payload On-Board Computer 61

before they would be ready for flight. This is the conversion of the PC based implementation to

the OBC based implementation. From the very beginning of the process it has been known that

considerable amounts of change are needed for these algorithms. This is because the POBC only

has approximately 200 KB of free code space left, whereas the FIONA/RelNav PC based algorithms

are approximately 400 KB in size, thus a significant memory footprint reduction is required. The

OBC target integration is split into several phases, the first phase is migrating the algorithms to

the ARM7 environment and verifying that they will compile under the Rowley Crossworks Inte-

grated Development Environment (IDE). This is followed by multiple rounds of memory footprint

reduction. These rounds of memory footprint reduction target the easiest reductions first, and defer

making larger structural changes to the code for as long as possible. This iterative process is chosen

because the risk of adding new bugs into the software greatly increases with the complexity of the

changes required. The final phase is performance benchmarking of the FIONA/RelNav algorithms

to make sure that they are meeting the aggressive timing constraints imposed by the CanX-4 and

CanX-5 mission. Performance optimizations are made to the algorithms on an ‘as necessary basis’,

following the same principle as the memory footprint reduction: easy small changes first, then

moving towards more complex optimization strategies.

4.2.2 Code Migration

The code migration process is a simple but necessary step in the overall integration task. This step

involves moving only the required source and header files into a specific POBC CANOE Rowley

Crossworks project file for the CanX-4/5 POBC. This is to say that the CANOE operating system

and formation flying algorithms are compiled and loaded together onto the POBC. Minor work

such as resolving include paths and directories is needed. As all compilers implement the ANSI

C standard to varying degrees of compliance, other minor adjustments to the code are needed to

reconcile the differences between the Microsoft Visual C++ compiler and the Rowley Crossworks

compiler. After the successful migration of the code to the new OBC target project, the code

can successfully be compiled. However due to the large memory footprint of the formation flying

algorithms they cannot link, as they are now approximately 100 KB too large to fit into the code

memory bank of the POBC. It should be noted that the X86 versions of formation flying algorithms

are approximately 400 KB in size, where the new ARM7 versions were only approximately 300 KB.

This is due to the fact that the X86 versions had supporting code that was used to execute and test


the formation flying algorithms that was stripped out during the migration process. The reduction

in size can also be attributed to the fact that the X86 and ARM7 targets, although both 32 bit

RISC machines, use very different machine level code.

4.2.3 Memory Footprint Reduction

Once the migration process is complete, the formation flying algorithms memory footprint have

to be reduced by at least 100 KB. A careful examination of the formation flying code is needed

in order to identify key areas where memory usage can be reduced, with minimal structural or

functional changes to the code. After this inspection, five major improvements have been identified

as an ideal starting point as they promised a large reduction in memory usage while making no

alterations to the algorithms structure. These changes are:

• Turning on the compiler optimizations for code and data space. This is done on a per file

basis, but is not the default setting.

• Moving large global variables from the code bank to the data bank of the POBC. This is

achieved by adding preprocessor directives to the variables to be place in the data bank. This

is required because by default the complier places everything in the code bank.

• Removing the ‘static’ storage-class specifier from variables that do not need to be static in

nature. Throughout the formation flying algorithms almost all local function variables were

declared as ‘static’. This is unnecessary as these values did not need to maintain their values

between function calls. Using this storage-class specifier instructs the compiler to allocate

application persistent memory for each variable, as opposed to using the stack for these local

variables which greatly reduces the memory footprint.

• As the CANOE operating system does not provide the ability for dynamic memory allocation,

all memory allocation must be done at compile time, and done assuming a maximum capacity.

For example, if a vector is only 4 elements in size the majority of the time, but could have

the possibility of being 15 elements in size, it must be declared as size 15, thus wasting

36 bytes of memory assuming a double precision floating point element type. Aggregated

over the entirety of the formation flying algorithms, this results in a large amount of wasted

memory. Many of the vectors and matrices used throughout these algorithms were oversized

and savings are realized by properly sizing them.

• FIONA and RelNav had debugging, testing code and variables left in the implementation


from the PC based testing environment. Most of this code is now useless as it relies on the

presence of a screen for debugging. All of this code has been removed.

Completion of this phase of the memory footprint reduction results in the overall size of the

formation flying algorithms being reduced by 60 KB. While this is a major step in the integration

process, another round of reductions is required in order to meet the target of a reduction in size

of 100 KB.

The next phase in the memory footprint reduction requires more aggressive changes in order

realize the 100 KB target. Again, the formation flying algorithms are studied in greater depth,

this time focus is placed on possible structural or functional changes. Although these changes can

increase the risk of unintentionally adding bugs back into the system, the risk can be mitigated

with regression testing using the Hardware-In-The-Loop simulator (Chapter 5). The changes that

have been identified are:

• In the implementation of the formation flying algorithms, both FIONA and RelNav each have

their own matrix and vector math library. This library uses the same types, and provides

nearly the same functionality. These two libraries consequently have been consolidated into

a single library used by both FIONA and RelNav.

• Several very large and complex algorithms have been identified because their implementations

can be rewritten, or have functionality removed without negatively impacting the overall

formation flying performance.

This round of memory footprint reductions results with a savings of another 70 KB. This now

brings the total memory footprint reduction up to approximately 130 KB, which is more than the

initial goal of 100 KB. At this stage in the integration process, the formation flying algorithms can

now compile, and link in the CANOE POBC project, meaning that for the first time ever, they

can be loaded onto flight hardware.

New Memory Allocation Scheme

During the memory footprint reduction, efforts have been made to realize a new method of mem-

ory allocation, providing the ability for ‘dynamic’ memory allocation at compile time, in essence,

providing the capabilities of a heap while using only the stack. This has been explored because as

mentioned before, all matrices and vectors are defined as the same type and are declared to hold


the largest possible vector or matrix used inside the formation flying algorithms. This is a huge

waste of memory. Even though the memory footprint reduction resulted in properly sized matrices

and vectors, there is still a potential for even more savings. The new memory allocation scheme

continues to use a common matrix or vector interface, but uses the advanced C language feature

known as ‘incomplete types’. Meaning that a structure of type ‘vector’ or ‘matrix’ cannot be cre-

ated explicitly, as the size of the object is not defined. Instead a preprocessor macro is written that

creates an anonymous structure with the same layout as the interface, but defines the size, thus

allowing a user to create a vector of the required size, and allow generic access to it through the in-

complete interface type. This is achieved by casting the anonymous structure to the interface type.

This leverages the way the C language casts structures, on a field by field basis until a difference

is found. Since the anonymous structure and the interface do not differ in underlying data type

layout, only array size, this casting is successful. Figure 4.1 shows the complete process. Although

this process has not been implemented for the formation flying algorithms as it was deemed too

large of a risk, due to the massive amounts of code change required, it is however a tool that could

be used for new projects moving forward.


Figure 4.1: Dynamic memory allocation process (Source: SFL)

4.2.4 Execution Optimzations

Once the formation flying algorithms can be loaded and tested on the POBC, metrics can be

gathered on their performance, specifically execution time. This is a critical metric because the

formation flying algorithms are the largest consumer of the 5 second closed loop navigation cycle

time. During profiling of the execution time, it has been shown that occasionally the cycle time

would be greater than the 5 seconds required. Note that an even more stringent desire of 4 seconds

was placed on the system. A strong desire is a goal, but not an actual requirement of the system.

A 4 second closed loop cycle time is desired because it provides 20 percent margin, where the 5

second requirement provides none.

The initial optimization focuses on the matrix operations in the math library, this is due to the

underlying way that the formation flying algorithms store matrices. The values of each element in

the matrix are stored in a 1-dimensional array, i.e. [Row ‘1’ elements, Row ‘2’ elements ... Row ‘n’

elements]. Due to this type of storage, a macro was defined that decodes row and column indices


into the single index of the element in the 1-dimensional array. This macro uses one multiplication

operation, one addition operation and two subtraction operations, to retrieve a single element.

Given that matrix multiplication on a computer is an O(n3) operation, this leads to a realization

for decreasing execution time. If the number of instructions needed to retrieve an element from

a matrix is reduced, the execution time for matrix multiplication, and other O(n2) and O(n3)

operations can be significantly decreased. The math library functions that have been identified for

optimization are:

• Matrix multiplication

• Matrix vector multiplication

• Matrix addition

• Matrix subtraction

• Vector transpose vector multiplication

• Vector transpose matrix multiplication

• Calculation of the outer product

The optimization consists of completely rewriting the algorithms so that they do not use the

element retrieval macro. Instead they can be written with the knowledge of the underlying data

structure in mind, leveraging the fact that the data is stored in a sequential 1-dimensional array.

A small C++ program has been written that serves as a benchmarking tool. A copy of the

original and optimized algorithms run on the same data set and are timed using the high precision

timers available on the PC. This program serves a dual purpose, not only does it perform the

benchmarking, but it compares the results of the original algorithm versus the optimized algorithm

to validate that the new algorithms are functioning as expected. The following tables show the

results of the optimizations for some of algorithms, where ‘n’ is number of rows and columns in

the matrix (square matrix). The benchmarking is done for three cases: with an ‘n’ of 0 (trivial

case), an ‘n’ of 14 (average case) and an ‘n’ of 25 (worst case). Each version of the algorithm is

benchmarked 10,000 times to produce an average execution time. The average execution times are

displayed in milliseconds.


Matrix Vector Multiplication

n=0 n=14 n=25

Base 0 ms 3 ms 11 ms

Optimized 0 ms 3 ms 11 ms

Table 4.1: Matrix vector multiplication optimization results

Matrix Matrix Multiplication

n=0 n=14 n=25



Table 4.2: Matrix matrix multiplication optimization results

Matrix Addition

n=0 n=14 n=25



Table 4.3: Matrix addition optimization results

Matrix Subraction

n=0 n=14 n=25



Table 4.4: Matrix subtraction optimization results

As has been demonstrated, the optimized algorithms are at least on par, if not significantly

faster than the original versions, with the optimized matrix multiplication algorithm executing in

less that 60 percent of the time required by the original in the worst case scenario. One thing to

note is that these benchmarking results have been acquired using an X86 based PC, the actual

time savings realized on the POBC are different due to the different machine level languages used.

Regardless of the timing discrepancies between POBC and PC, the reduced number of instructions

used per matrix operation does result in an overall shorter execution time. To date the math


library optimzations have been shown to decrease the execution time by approximately 30 ms per

closed loop navigation cycle.

A final stage for optimizing the execution time of the matrix math operations has been ex-

plored. This is the writing of the aforementioned algorithms in pure ARM7 assembly, utilizing

the digital signal processing (DSP) functionality provided by the ARM7 processor. Unfortunately

the formation flying algorithms use a C floating point as the base element type for matrices and

vectors, but the specific ARM7 processor used on the ‘OBC-300’ does not support native floating

point arithmetic. This means that the DSP functionality can only be exploited for matrices or

vectors of base element type integer.

4.3 Integration Software

Not only does the POBC need to run the FIONA and RelNav algorithms, it must also communi-

cate with, or control the other essential formation flying subsystems: GPS receiver, ISL, CNAPS,

Momentum Management Software (MMS) and the Payload Power Board (PPB). As shown in Fig-

ure 1.2 many of these subsystems are inputs or outputs of the RelNav and FIONA algorithms,

therefore a software integration architecture is required. This software controls the flow of data

and the execution order of all of the required subsystems. Since CANOE is a threaded real-time

operating system it has been decided to design the software using multiple threads to spread out

the tasks. Thus a thread is created to communicate with the GPS receiver, OASYS, CNAPS, the

MMS and the main algorithm responsible for calling RelNav and FIONA. Figure 4.2 shows the

architecture of the integration software for both satallite modes, ‘chief’ and ‘deputy’.


Figure 4.2: POBC integration software architecture (Source: SFL)


Although not implemented directly as shown in Figure 4.2, it should be noted that this ar-

chitecture has been used as the starting point by other members of the Space Flight Laboratory

to actually implement the controlling software on the POBC. As this architecture was not imple-

mented as shown, Figure 4.2 is meant to show the general concept of a managing thread for each

formation flying subsystem.

Chapter 5

Hardware-In-The-Loop (HWIL)

Simulation

5.1 Introduction

The success of the CanX-4 and CanX-5 mission hinges on the critical formation flying subsystems,

however a method for verifying the performance of these subsystems on the ground is a non-trivial

task. Testing all the dynamic interconnections and performance of each formation flying subsys-

tems requires a simulation environment that can provide real-time realistic on-orbit conditions.

The subsystems that must be verified are the formation flying algorithms, the GPS receivers, the

intersatellite link (ISL), CNAPS and the attitude determination and control system (ADCS). Not

only will a full mission simulator provide validation that CanX-4&-5 are meeting the closed loop

navigation cycle timing and sub-metre control accuracy requirements, but allows for debugging

of the formation flying aspects of CanX-4 and CanX-5 as a system. A closed loop simulator is

chosen as the ideal method of fulfilling the need for a full mission simulation. In order to realize

this closed loop simulator, GPS simulation hardware is required as the formation flying algorithms

depend on GPS data for navigation. The closed loop consists of a truth model that feeds the GPS

simulator hardware the motion data of both CanX-4 and CanX-5. The GPS hardware then feeds

the appropriate L1 GPS signals to the receivers on-board each spacecraft. This, along with infor-

mation from the ADCS and ISL flow into the formation flying algorithms. The calculated thrusts

from the formation flying algorithms are then forwarded to the truth model, where it updates each

spacecrafts’ attitude, position and velocity information, and feeds the new information to the GPS

71

Chapter 5. Hardware-In-The-Loop (HWIL) Simulation 72

simulator, thus closing the loop. The development of the hardware-in-the-loop simulator would

took place in three phases:

• Phase 1 consists of writing preliminary truth model software, interfacing the truth model with

the GPS software (no GPS hardware would be involved), and including PC based formation

flying algorithms. This is an open loop simulation.

• Phase 2 consists of adding a real-time PCI timer card for timing synchronization between

the truth model and the GPS simulation hardware. The GPS receivers are also added, thus

closing the loop

• Phase 3 consists of adding software to simulate the ADCS, CNAPS and Payload Power Board

(PPB) subsystems, and moving the formation flying algorithms to the POBC, which is added

to the loop, along with the actual ISLs

Figure 5.1 shows a high level block diagram of Phase 3 of the hardware-in-the-loop simulator.

The ‘Truth Model’ block represents a PC running the truth model, and simulated ADCS, CNAPS,

and PPB subsystems. The ‘GPS Hardware Simulator’ block is a PC and GSS6700 GPS signal

generators which is generating the GPS signals. The ‘CanX-4’ and ‘CanX-5’ blocks represent the

spacecraft, POBC, ISL and GPS receivers. A more detailed interconnection diagram is presented

later in this chapter.

Figure 5.1: Hardware-in-the-loop block diagram (Source: SFL)


5.2 GPS Simulation Hardware

As the formation flying algorithms use GPS data in order to compute their positions and velocities,

external hardware is needed in order to simulate the required GPS signals. This hardware was pur-

chased from Spirent Communications, and it consists of a PC running proprietary SimGen software

(Figure 5.2), which is responsible for controlling two GSS6700 GPS signal generators. One signal

simulator is required for each spacecraft. These signal generators are responsible for generating the

L1 GPS signals required by the CanX-4/-5 GPS receivers. The GSS6700 are physically connected

to each of the two GPS receivers using standard RF cables. The GSS6700 signal generators also

provide external synchronization capabilities by providing a 1PPS (One Pulse Per Second) output.

Figure 5.2: Spirent Communications SimGen software during a simulation (Source: SFL)

5.3 Phase 1

Phase 1 consists of creating the truth model and interfacing it with the Spirent SimGen position

application, as well as interfacing the truth model with the PC based versions of the formation flying

algorithms. In this phase, the truth model, formation flying algorithms and the SimGen application

reside on the same PC and run in an open loop, no hardware configuration. This means that there


is no GPS hardware present in this phase. As such no feedback is given to the truth model from the

SimGen application, which is what is meant by open loop. SimGen allows for four different types of

interfacing with external software systems, IEEE-488, TCP/IP, RS-232 and SCRAMNet. TCP/IP,

also known as ‘sockets’, is chosen as the interface that the truth model implements to communicate

with SimGen. This is due to the fact that the other types of interfacing require additional hardware

or cables, and also because the Space Flight Laboratory already has its own Local Area Network

(LAN) using both Ethernet and WiFi which provides TCP/IP communication.

Since both the truth model and formation flying algorithms run on the same computer, two

interfacing options are available, again using TCP/IP, or using ‘Named Pipes’ for inter-process

communication. Named Pipes are chosen as they offer a more lightweight form of inter-process

communication when compared with TCP/IP. A named pipe is essentially a full duplex shared file

between two separate processes running on the same physical machine. Like the sockets chosen as

the interface between the truth model and SimGen, it is a client/server architecture, where both

client and server can read or write a stream of bytes.

Once the interface between the truth model and the PC based formation flying algorithms has

been chosen the necessary changes can be added to the formation flying algorithms. The changers

are relatively minor: upon startup the formation flying algorithms attempt to connect to a named

pipe that has been created by the truth model, the truth model being the server and the formation

flying algorithms being the client. Once a successful named pipe connection is established, the

formation flying algorithms send an updated attitude target and commanded thrust data from the

deputy via the named pipe to the truth model upon completion of every navigation cycle.

The truth model is written in console C++, this is because it is not meant to be an embedded

application and therefore can make use of the object oriented extensions to the C language that

C++ provides. The truth model takes the new attitude and thrust data, and uses that with both

spacecrafts’ current attitude, position and velocity to integrate the effect of the thrust and change in

attitude for both spacecraft. The truth model is also simultaneously propagating both spacecrafts’

attitude, position and velocity and sending this motion data to SimGen at a frequency of 10 Hz, or

every 100 ms. The motion data that is required to be provided by the truth model to SimGen is:

• Linear position vector (X,Y,Z)

• Linear velocity vector (X,Y,Z)

• Linear acceleration vector (X,Y,Z)


• Linear jerk vector (X,Y,Z), where linear jerk is defined as the derivative of linear acceleration

with respect to time

• Roll, pitch and yaw

• Angular velocity vector (X,Y,Z)

• Angular acceleration vector (X,Y,Z)

• Angular jerk vector (X,Y,Z), where angular jerk is defined as the derivative of angular accel-

eration with respect to time

• SimGen motion type (Used to specify how the message should be interpreted by SimGen)

• Motion time stamp (At what precise moment in time the spacecraft is at this position with

this attitude)

• Vehicle ID, either CanX-4 or CanX-5

The truth model is able to handle both tasks simultaneously because it is a multi-threaded

application, making use of the ‘C++ Boost Libraries’ for threading support. The truth model

has a main thread that is the main entry point to the application, a thread that is responsible

for propagating the attitude, position and velocity and forwarding it to SimGen every 100 ms,

and a thread that is responsible for communicating with the formation flying algorithms to receive

new commanded attitudes and thrusts. In order to ensure that the messages arrive on time, as

SimGen requires a motion data message to have been successfully received at least 100 ms before

the motion time stamp in the message, all threads in the truth model are given the highest priority

class and thread priority recommended by Microsoft. Meeting this strict timing requirement is of

critical importance due to the fact that if a motion data message is not received by SimGen on

time, SimGen starts to extrapolate the spacecrafts trajectory on its own. This extrapolation is

done using a different model than the CanX-4/-5 truth model, and results in position and velocity

discrepancies between the truth model and SimGen.

In order to actually communicate with the SimGen application the truth model employs TCP/IP

sockets as described above. In order to remotely command the SimGen application, two socket con-

nections are required, a TCP/IP socket, and a UDP socket. The UDP socket is a fast connectionless

socket that provides no guarantees about dropped packets, or packets arriving in the correct order.

This fast UDP socket is used to transmit the motion data, as per the SimGen manual. The TCP/IP

socket is a slower connection oriented socket that guarantees lossless, in order transmission of data.


This socket is used to send command messages to SimGen, these messages are needed in order

to remotely arm a scenario, preload initial parameters (attitude, position and velocity), start the

scenario, end the scenario and rewind the scenario. This socket can also be used to query the state

of the scenario, i.e. if it is currently armed, running, or the current scenario time.

At this point a successful open loop simulation exists, the formation flying algorithms can

effectively communicate with the truth model, and the truth model is able to provide the SimGen

software with the motion data it required. Figure 5.3 shows a block diagram of Phase 1 of the

hardware-in-the-loop simulator. As can been seen from Figure 5.3, no information flows from the

SimGen software to the FIONA/RelNav algorithm which would actually close the simulation loop,

thus making Phase 1 an open loop simulator.

Figure 5.3: Hardware in the loop Phase 1 block diagram (Source: SFL)

5.4 Phase 2

The main goal of the second phase in the hardware-in-the-loop simulator, is to actually close the

navigation loop by integrating the GPS hardware. This integration of GPS signal simulators and

receivers requires moving the SimGen application from the truth model PC to a PC provided by

Spirent. Even though the truth model and SimGen application are no longer on the same machine,

they can still communicate using sockets. The new IP address of the SimGen PC needs to be

provided to the truth model on startup, as ‘localhost’ is no longer valid.


Closing the loop also requires adding several new physical connections to actually bring the

hardware into the loop. The SimGen PC needs to be connected to the Space Flight Laboratory

internal network this is achieved using an Ethernet cable. The SimGen PC also needs to be

connected to the master GSS6700 signal generator via USB. The master GSS6700 is then connected

to the slave GSS6700 via USB. The master GSS6700 is also connected to a PCI timer card installed

on the truth model PC, or ‘Remote PC’ as it is now known. This ensures that both PCs and the

GPS signal simulation hardware stay in sync. The master and slave GSS6700s are then connected

to one of the GPS receivers using a standard RF cable. The GPS receivers are connected to the

formation flying algorithms, running on the ’Remote PC’, by serial cables, thus closing the hardware

loop (Figure 5.4).

The flow of information in Figure 5.4 is as follows, the truth model forwards SimGen UDP

packets containing motion data for each spacecraft. SimGen interprets this data and sends its

own information to each GSS6700 which allows the signal generators to update their GPS signals.

These GPS signals then flow into each of the GPS receivers where the L1 GPS signal is decoded

into meaningful GPS data. That data is then forwarded to the FIONA/RelNav algorithms. The

formation flying algorithms calculate any required thrusts and updated the truth model if a thrust

is required.


Figure 5.4: Hardware in the loop phase 2 block diagram (Source: SFL)

In order to actually utilize the newly connected hardware, several software upgrades to the

truth mode are required:

• Writing of an integrated device driver for the new PCI timer card. This driver is responsible

for detecting the timer card, initializing it, and registering an interrupt that is fired on the

reception of a 1PPS signal from the master GSS6700 signal simulator. This driver is said

to be integrated because its implementation is integrated directly into the truth model code.

The truth model is able to function with or without the presence of the PCI timer card,

by employing a ‘#define’ that allows for compilation with or without this integrated driver

support

• A new thread is created that allows the truth model to send information back to the formation

flying algorithms, this is needed in order to allow for the truth model to command changes

in the formation flying algorithms, i.e. changing from fine to coarse navigation, or changing

from one formation to another formation. This is accomplished by creating another named

pipe between the truth model and the formation flying algorithms. This approach is taken

as it is a simpler design to have each communication thread have its own communication

medium instead of trying to arbitrate access to a shared medium across multiple threads


• Adding the ability for SimGen configuration commands to be sent from the truth model

to the SimGen PC via the TCP socket. This functionality is required for both startup,

and at specific time intervals, these intervals being specified by a simulation time tag. The

truth model nows allow the user to specify the location of two files containing the startup

commands, and the time tagged commands, as command line arguments, and ignores them

if not provided.

After the successful completion of these hardware and software upgrades, actual hardware-in-

the-loop simulations can be run in a closed loop environment. This allows for simulations to be

run that aid in the debugging and validation of the formation flying algorithms. Figure 5.5 shows

the order in which the software packages must be started in Phase 2 in order to run a simulation,

as well as the dynamic interconnections that are created between the packages for communication.

Figure 5.5: Startup order required to run a HWIL simulation (Source: SFL)


5.5 Phase 3

Phase three of the hardware-in-the-loop simulator involves migrating the formation flying algo-

rithms to the actual Payload On-Board Computers (POBCs), that now implement a version of the

control software described in Chapter 4. The ISLs are also added to the loop as well as software

for simulating the ADCS (or OASYS, On-board Attitude System Software) and CNAPS subsys-

tems. Figure 5.6 shows the complete block diagram of the final phase of the hardware-in-the-loop

simulator.

The flow of information in Figure 5.6 is as follows. The truth model forwards motion data in the

form of UDP packets to the SimGen software. SimGen then interprets this motion data and sends

updated information to the GSS6700 signal generators. The signal generators then update their

L1 GPS signals. This updated L1 GPS signal is processed in the GPS receivers on-board CanX-4

and CanX-5. This GPS information is forwarded to the POBC. Next, the ISLs exchange GPS

and attitude information. This information is used in the POBCs to calculate thrusts and send

messages to CNAPS, OASYS, and PPB simulators, the simulated subsystems respond. Finally the

POBC sends its thrust target to the truth model where the new thrust is accounted for, and the

process repeats.


Figure 5.6: Hardware in the loop phase 3 block diagram (Source: SFL)

Once the POBCs are added to the loop, the ISLs and GPS receivers can be directly connected

to them in a flight indicative manner. Each POBC then needs to be connected to the ‘Remote

PC’ using a serial connection. In order to communicate with the truth model, the POBC uses an

intermediary Space Flight Laboratory piece of Ground Support Equipment called TIP (Terminal

Interface Program). TIP is a a piece of software that allows for the routing of Nanosatellite Protocol

(NSP) packets using a variety of transmission mediums, including TCP/IP and serial. Phase three

also required large upgrades to the truth model in order to properly communicate with the POBCs

and simulate the OASYS, Payload Power Board (PPB) and CNAPS subsystems. These upgrades

included:

• Removing all the named pipes that are used to connect the truth model to the PC based

formation flying algorithms

• Removing any code that commands the formation flying algorithms as this is now routed

through TIP


• Creating a multi-threaded TIP interface class that is responsible for creating TCP socket

connections to TIP and handling bidirectional NSP communications. The user provides the

IP address and port number of the specific instance of TIP it wishes to connect to. A total of

four socket connections are needed, one to allow the POBC to communicate with the truth

model, one for the simulated OASYS subsystem, one for the simulated CNAPS subsystem

and finally one for the simulated PPB subsystem. This class makes use of the ‘C++ Boost

Libraries’ to employ a separate thread that is responsible for the actual dispatching and

receiving of messages. This class offers the truth model the ability to queue up multiple NSP

messages for transmission while simultaneously receiving NSP messages from the POBC. This

is achieved using a separate receive and transmit buffer and thread synchronization methods

so that the truth model thread does not accidently overwrite the dispatcher thread. Even

though this class manages four underlying connections, it provides a single transmit and

receive interface to the truth model. The truth model is be able to inspect the received

packets and determine their source and what appropriate actions are required. This class

is able to inspect the destination address of a packet in its transmit queue, and determine

which socket to physically route that packet to. As an aside, due to the multi-threaded

architecture for dispatching and receiving NSP packets, a bug has been found in the ground

support NSP library, one of the functions inside this library has been discovered to be not

thread safe. What is meant by not thread safe is, that the state of an internal buffer can be

corrupted if a specific function inside the library was preempted by another thread, which

then makes a call to that same function. The reason that this is created as a ‘C++’ class

is because this functionality is required for each spacecraft, CanX-4 and CanX-5. Therefore

inside the truth model, two instances of this class are created, one to connect to the TIP that

is communicating with CanX-4, and one to connect to the TIP that is communicating with

CanX-5

• As Phase three uses flight hardware, it also uses NSP for messages between subsystems, as

this is the standard intra and inter-computer communication protocol. A message pump for

decoding incoming NSP messages is needed. This message pump decodes the messages based

on their destination and command, and then issues the proper reply using the TIP interface

class. The message pump is also responsible for simulating the CNAPS, OASYS and PPB

subsystems. When a message is received at the truth model that is addressed to one of these


subsystems, the truth model replies on behalf of that subsystem

• Due to the large amount of dynamically created NSP messages, and the prolonged period

of time over which the simulations are run, sometimes in upwards of a week, a method for

mitigating memory leaks is required. This is realized through the use of the ‘C++ Boost

Libraries’ ‘Smart Pointers’ class. The truth model does not use a raw NSP message pointer,

but instead uses a smart pointer of type NSP message. Theses smart pointers employ a

reference count that automatically releases the allocated memory when it detects that the

reference count is zero, i.e. nothing has a handle to the pointer anymore.

Results

Upon the completion of Phase three of the hardware-in-the-loop simulator, full mission simulations

can now take place. These simulations incorporate flight hardware, and are the best possible rep-

resentation of on-orbit data and conditions possible. This allows for debugging of the formation

flying subsystems, and validation of compliance with the requirements. Figure 5.7 shows a his-

togram of closed loop navigation cycle times for a simulation of approximately 6 hours. As can be

seen CanX-4 and CanX-5 are meeting the requirement of 5 seconds or less. Although the strong

desire of a 4 second cycle time is not always being met, the majority of cycles are executed in 4

seconds or less. It should be noted that there are no cycle overruns, i.e. cycles over 5 seconds.

Figure 5.8 shows a plot of control error magnitude versus simulation time. Again, it can be seen

that CanX-4 and CanX-5 are meeting their requirement of sub-metre control accuracy. The solid

horizontal blue line represents the one metre accuracy constraint. The only times when they are

not meeting this requirement is when they are in the process of reconfiguring to a new formation,

which can be seen as the zones of non-compliance in the plot. Although during the simulation the

formation does come close to violating the sub-metre constraint, it does not actually violate it.


Figure 5.7: Closed loop navigation cycle timing histogram(Source: SFL)

Figure 5.8: Control accuracy vs Time plot (Source: SFL)

Chapter 6

Conclusion

The CanX-4 and CanX-5 mission is an aggressive mission that paves the way for future operational

formation flying missions on the nanosatellite scale. These missions could include Interferometric

Synthetic Aperture Radar (InSAR), super-resolution imaging and ground moving target indication.

This is achieved by proving the technical feasibility of the required enabling technologies. This thesis

has highlighted some of the major technical challenges, and the author’s contributions to addressing

these challenges in order to ensure the success of the CanX-4 and CanX-5 mission.

The design, development and testing of all the real-time embedded software for an autonomous

two way intersatellite communication system. This system is essential for closing the navigation

cycle by providing reliable data transfer of critical, time sensitive GPS and attitude information.

The Intersatellite Link (ISL) is continuing to not only meet, but exceed its requirements and has a

packet delivery success rate between 99.9 and 99.99 percent.

Designing a software integration algorithm for some of the most complicated Guidance Naviga-

tion and Control software and hardware that the Space Flight Laboratory has produced to date.

Performing optimizations on key formation flying algorithms to reduce their execution time and

memory footprint, and developing a novel memory allocation scheme which can be leveraged by

future Space Flight Laboratory missions.

Finally, developing all the software for a complete hardware-in-the-loop (HWIL) simulator which

has proved to be invaluable for tracking down bugs in the formation flying algorithms and providing

confidence that all the formation flying subsystems are meeting their requirements.

With the completion of these tasks full end-to-end mission simulations using flight hardware

and conditions mimicking those expected on-orbit can proceed. This simulations will help to ensure

85

Chapter 6. Conclusion 86

that the CanX-4 and CanX-5 mission will be a resounding success.

Bibliography

[1] M. Leonard, N. Roth, G. Bonin, and D. R. Zee, “The CanX-4 and CanX-5 Nanosatellite

Formation Flying Mission.” Abstract Submitted to the Small Satellite Conference, 2012.

[2] N. Roth, “Navigation And Control Design For The CanX-4/-5 Satellite Formation Flying

Mission,” M.A.Sc., University of Toronto Institute for Aerospace Studies, 2010.

[3] N. Roth, “FIONA and RelNav Test Requirements.” Unpublished work, 2012.

[4] M. Leonard, L. Stras, G. Bonin, and D. R. Zee, “Intersatellite Link Software for the CanX-4&-5

nanosatellite Formation Flying Mission.” Unpublished work, 2012.

[5] M. Leonard, N. Roth, G. Bonin, L. Stras, and D. R. Zee, “Hardware-In-The-Loop (HWIL)

Simulator for the CanX-4&5 Nanosatellite Formation Flying Mission,” 2012. Presented at the

CASI Astro Conference (Quebec City, Quebec, Canada).

[6] “ARM7TDMI Revision: r4p1,” 2004. ARM Limited.

[7] S. Eagleson, K. Sarda, J. Grzymisch, and A. Philip, “Attitude determination and control:

CanX-4/-5 subsytem critical design review document,” tech. rep., Universty of Toronto Insti-

tute for Aerospace Studies Space Flight Laboratory, 2007.

[8] D. Kekez, “Nanosatellite Protocol (NSP) Version 3.” SFL Internal Document, 2007.

[9] G. Bonin, “Power System Design, Analysis, and Power Electronics Implementation on Generic

Nanosatellite Bus (GNB) Spacecraft,” M.A.Sc., University of Toronto Institute for Aerospace

Studies, 2009.

[10] “Hermes: Demonstration Satellite that Opened the Door to New Services that now Benefit

Canada and the World,” 2008. World Wide Web Reference.

87

Bibliography 88

[11] S. Lee, “CubeSat Design Specification Rev. 12,” tech. rep., Cal Poly, 2009.

[12] R. Zee, “Presentation: Space Flight Laboratory.” 2012.

[13] L. David, “CubeSats: Tiny Spacecraft, Huge Payoff,” 2004. World Wide Web Reference.

[14] “List of Cubesats,” 2012. World Wide Web Reference.

[15] R. Zee, “The CanX-6-NTS Mission,” 2011. World Wide Web Reference.

[16] A. Phillip, “Attitude sensing, actuation, and control of the BRITE and CanX-4/-5 satellites,”

M.A.Sc., University of Toronto Institute for Aerospace Studies, 2008.

[17] “Canadian Advanced Nanospace eXperiment Program,” 2012. World Wide Web Reference.

[18] “CanX-2 Nanosatellite Requirements Document,” 2003. CanX-2 Team, Unpublished work.

[19] R. Zee, “The AISSat-1 Mission,” 2011. World Wide Web Reference.

[20] A. Beattie, “BRITE and CanX-4/CanX-5 Intersatellite Link Requirements.” Unpublished

work, 2007.

[21] “C8051F410/1/2/3 Rev 1.1,” 2008. Silicon Laboratories.

[22] “SWRS040C,” 2010. Texas Instruments.

[23] M. Leonard, “CanX-4/CanX-5 Interatellite Link Software Requirements.” SFL Internal Doc-

ument, 2011.

[24] R. Fuhrmann, “Intersatellite Link Design Issues,” M.Sc., University of Colorado, 1985.

[25] “Open Systems Interconnection,” 2012. World Wide Web Reference.

[26] “OSI Model,” 2012. World Wide Web Reference.

[27] K. Kusza and M. Paluszek, “Intersatellite Links: Lower Layer Protocols for Autonomous

Constellations,” tech. rep., Princeton Satellite Systems, 2000.

[28] D. Cinarelli, V. Fabbri, and P. Tortora, “Analysis of Inter-Satellite Communication Protocols

and their Effects on Satellite Formation Control,” tech. rep., Universita di Bologna, Flori and

ALMASpace S.R.I, Flori, 2011.

Bibliography 89

[29] “X.25,” 2012. World Wide Web Reference.

[30] “Internet Protocol Suite,” 2012. World Wide Web Reference.

[31] “Asynchronous Transfer Mode,” 2012. World Wide Web Reference.

[32] “IEEE 802.11,” 2012. World Wide Web Reference.

[33] “Agile Software Development,” 2012. World Wide Web Reference.

[34] M. Leonard, “CanX-4/CanX-5 Interatellite Link Protocol Stack Design & Requirements.” SFL

Internal Document, 2011.

[35] A. Beattie, “BRITE and CanX-4/CanX-5 Intersatellite Link Requirements.” SFL Internal

Document, 2007.

Chapter 7

Appendix

7.0.1 MAC Layer Transmit Pseudocode

PROCEDURE TransmitNSPPacket(nspPacket, length)

IF (length > MAX NSP LENGTH OR length < MIN NSP LENGTH ) THEN

RETURN

END IF

numberOfFrames← d(length÷MAX PAYLOAD SIZE)e

currentPayloadSize← 0

DO

IF (currentPayloadSize + MAX PAYLOAD SIZE ≤ length) THEN

currentPayloadSize← MAX PAYLOAD SIZE

ELSE

currentPayloadSize← (length− currentPayloadSize)

END IF

L2Frame.SequenceNumber ← numberOfFrames

L2Frame.PacketIDFlag ← PACKET ID FLAG

L2Frame.PayloadSize← currentPayloadSize

L2Frame.Payload← next currentPayloadSize bytes from nspPacket

CALL Transmit L2 Frame(L2Frame)

90

Chapter 7. Appendix 91

currentPayloadSize← (currentPayloadSize + MAX PAYLOAD SIZE)

WHILE((numberOfFrames← numberOfFrames− 1) > 0)

CALL Receive Mode

FLIP PACKET ID FLAG

RETURN

Chapter 7. Appendix 92

7.0.2 MAC Layer Receive Pseudocode

PROCEDURE ReceiveL1Frame(L1Frame, length)

IF (L1Frame.SequenceNumber > MAX SEQUENCE NUMBER OR L1Frame.PayloadSize >

MAX PAYLOAD SIZE OR length > L2 RX PACKET LENGTH) THEN

NumberOfInvalidL2Frames← (NumberOfInvalidL2Frames + 1)

RETURN

END IF

IF (L1Frame 3 CURRENT NSP PACKET) THEN

CALL Flush Receive Buffers

END IF

IF (L1Frame.RSSI > CURRENT RSSI AT L1Frame.SequenceNumber) THEN

IF (CURRENT RSSI FOR L1Frame.SequenceNumber = INVALID RSSI VALUE) THEN

L2PacketSize← (L2PacketSize + L1Frame.PayloadSize)

END IF

CURRENT RSSI AT L1Frame.SequenceNumber← L1Frame.RSSI

APPEND L1Frame.PayloadSize bytes from L1Frame.Payload to currentNSPPacket

END IF

IF (L1Frame.SequencNumber = 0) THEN

lastPacketIDflag← L1Frame.PacketIDFlag

CALL Packet Reassembled(currentNSPPAcket)

currentNSPPacket← NEW BUFFER

END IF

RETURN

Software for the Canadian Advanced Nanospace eXperiment-4 ... · Software for the Canadian Advanced...

Documents

Transcript of Software for the Canadian Advanced Nanospace eXperiment-4 ... · Software for the Canadian Advanced...