DESIGN AND IMPLEMENTATION OF

THE TERRESTRIAL AND SPACE

TELECOMMUNICATION ELEMENTS

OF THE STUDENT NANOSATELLITE

OF THE UNIVERSITY OF LIEGE

Jonathan PISANE

Thesis submitted in partial ful�llment of the requirements for the degree of

Master in Electrical Engineering

at the Applied Science Faculty of the University of Liège.

Advisor: Prof. Jacques Verly

Co-advisor: Luc Halbach (Spacebel)

Academic Year 2007-2008

Acknowledgments

I wish to thank my adviser Prof. Jacques Verly for his continuous support and adviceduring the whole academic year, and for the opportunity he o�ered me of realizing a veryinteresting thesis.

A big thank you also to Luc Halbach for his availability, his precious pieces of advice,especially technicals, throughout this thesis, and for having made me discover the worldof ham-radio.

I also want to thank all the members of the OUFTI team, Stefania Galli, PhilippeLedent, Amandine Denis, Jean-François Vandenrijt, Prof. Gaëtan Kerschen, Prof. PierreRochus, Prof. Jacques Verly, and Luc Halbach for the wonderful project we are buildingtogether.

What else to say but thank you to my parents, my sister, and my brothers, fortheir continuous support, not only during this thesis, but also during my entire studies,whether they were far away or by my side.

Thank you all my friends for having endured me everyday, and for the good times wehave had together this year... and all the other ones.

Last but certainly not least, a huge thank you to you, Gaëlle, for having been besideme during those �ve years.

Abstract

OUFTI-1 will be the �rst nanosatellite from the University of Liège (ULg), andalso the �rst nanosatellite made in Belgium. OUFTI-1 takes place within the frame-work of a long-term program called Leodium (Liège in Latin), the goal of whichis to develop a series of student satellites for scienti�c experiments. The futureOUFTI �eet will be controlled via the latest digital ham-radio communication tech-nology, the D-STAR protocol. Putting D-STAR aboard a satellite requires a com-plete understanding of the D-STAR technology. We use a two-pronged, fail-safestrategy. On the one hand, we install a D-STAR ground-based repeater connectedto a gateway computer allowing access to the Internet, thereby providing worldwideradio/Internet connectivity. On the other hand, we are developing a satellite systembased on acquired experience. We present the complete unraveling of the mystery ofD-STAR using a combination of documents, theoretical consideration about GMSK,and practical measurements on our equipment. The present thesis describes in ex-trema details of the transmit and receive chains of a generic D-STAR transceiver.Our view of the transmit chain consists, besides voice coder and radio-frequencyangular modulation, of a digital-to-phase deviation converter for which we realize acomplete simulation. Similarly, our view of the receive chain consists, besides voicedecoder and radio-frequency angular demodulation, of a phase deviation-to-digitalconverter for which we realize a complete simulation. The constitutive blocks ofthe digital-to-phase deviation converter are the D-STAR coder and the modulating-phase generator. The constitutive blocks of the phase deviation-to-digital converterare the bit decoder and the D-STAR decoder. We test our implementations �rst onsynthetic signals, then on real signals of high quality and lower quality. These testsshow our implementations are successfully working on synthetic signals and on sig-nals of reasonable quality. Our implementations are less-e�cient for signals of lowerquality. We are now ready to use the acquired knowledge to build our CubeSat com-munication system. The ground-based ULg D-STAR repeater/gateway (ON0ULG)is the �rst of its type in Benelux. The OUFTI-1 CubeSat will be the �rst-everD-STAR based satellite. All the objectives of the thesis have been accomplished.

Keywords: [CubeSat, D-STAR, GMSK, ham-radio, LEODIUM, OUFTI-1]

Contents

1 Introduction 1

2 Context and motivation 2

2.1 Initial motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Reasons for using amateur-radio telecommunications . . . . 22.3 Reasons for using D-STAR . . . . . . . . . . . . . . . . . . . . . . . 22.4 Communications systems used by amateur satellites and

CubeSats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.5 Reasons for using D-STAR . . . . . . . . . . . . . . . . . . . . . . . 42.6 Fail-safe strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.7 VEGA Maiden Flight . . . . . . . . . . . . . . . . . . . . . . . . . . 62.8 Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Overview of D-STAR telecommunication sys-tem 8

3.1 Key features of D-STAR (except for connectivity) . . . . . . 83.2 D-STAR connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Status of worldwide D-STAR network . . . . . . . . . . . . . . . 103.4 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5.1 User equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5.2 Repeater equipment . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.6 Ways to establish a communication . . . . . . . . . . . . . . . . . 14

4 Using D-STAR aboard a satellite: a new con-cept 16

4.1 Description of concept . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.1 Direct communication . . . . . . . . . . . . . . . . . . . . . . . . 164.1.2 Indirect communication through a local repeater . . . . . . . . 174.1.3 CubeSat command and control . . . . . . . . . . . . . . . . . . . 184.1.4 Equipment required . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Modes of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Comparison with other CubeSats' telecommunication sys-

tems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Unraveling the intricacies of the D-STAR com-munications system 22

5.1 Initial knowledge available . . . . . . . . . . . . . . . . . . . . . . . 225.2 Our current understanding of D-STAR . . . . . . . . . . . . . . 225.3 Description of the transmit (Tx) chain . . . . . . . . . . . . . . 23

5.4 Description of the receive (Rx) chain . . . . . . . . . . . . . . . . 245.5 Pairing of blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.6 Grouping of blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.7 How did we arrive at the proposed transmit and receive

chains? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.7.1 Phase 1: Probing in the IC-E2820 . . . . . . . . . . . . . . . . . 255.7.2 Phase 2: Testing the packet-data output . . . . . . . . . . . . . 255.7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 Detailed analysis of D-STAR communication sys-tem as found in ICOM IC-E2820 27

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2 AMBE voice coder and decoder . . . . . . . . . . . . . . . . . . . 276.3 D-STAR coder and decoder . . . . . . . . . . . . . . . . . . . . . . 27

6.3.1 Structure of a D-STAR frame . . . . . . . . . . . . . . . . . . . . 286.3.2 D-STAR coder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.3.3 D-STAR decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.4 Modulating-phase generator and bit decoder . . . . . . . . . . 306.5 Radio-Frequency angular modulator and demodulator . . . . 306.6 Digital-to-∆ω and ∆ω-to-digital converters . . . . . . . . . . . 326.7 GMSK modulator and demodulator . . . . . . . . . . . . . . . . 346.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 High-level view of our CubeSat D-STAR com-munication system 35

8 Software implementation of ∆ω/D and D/∆ωconverters 37

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.2 Detailed description of ∆ω/D software implementation (Rx

chain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.2.1 Bit decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.2.2 D-STAR decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8.3 Detailed description of D/∆ω software implementation (Txchain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.3.1 D-STAR coder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.3.2 Modulating-phase generator . . . . . . . . . . . . . . . . . . . . . 43

9 Experimental work with D-STAR signals 45

9.1 Acquisition of real signals from ICOM IC-E2820 . . . . . . . . 459.1.1 First method for extracting ∆ωR(t) from IC-E2820 . . . . . . . 459.1.2 Second method for extracting ∆ωR(t) from IC-E2820 . . . . . 46

9.2 Generation of synthetic signals . . . . . . . . . . . . . . . . . . . . 489.3 Examples of decoding of synthetic signals . . . . . . . . . . . . 509.4 Moving on towards bigger challenges . . . . . . . . . . . . . . . . 529.5 Decoding tools by others . . . . . . . . . . . . . . . . . . . . . . . . 53

9.5.1 Tool 1: C program from Satoshi Yasuda [68] . . . . . . . . . . . 539.5.2 Tool 2: D-STAR.exe from Jakub Hruska [75] . . . . . . . . . . 549.5.3 Tool 3: DV Dongle [36] . . . . . . . . . . . . . . . . . . . . . . . 56

9.6 Examples of decoding of real signals . . . . . . . . . . . . . . . . . . . . . 579.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579.6.2 Envelope detected and zero-level detected . . . . . . . . . . . . 599.6.3 Synchronization patterns . . . . . . . . . . . . . . . . . . . . . . 609.6.4 Radio header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629.6.5 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9.7 Reconstruction of frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.8 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

10 Installation and con�guration of ULg's D-STARrepeater 67

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6710.2 First installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6710.3 Second installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6810.4 Installation of gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7110.5 Final installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

11Miscellaneous activities, publications, and pre-sentations 75

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7511.2 Local and international presentations . . . . . . . . . . . . . . . 7511.3 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7511.4 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

11.4.1 Ham-radio license . . . . . . . . . . . . . . . . . . . . . . . . . . . 7511.4.2 CubeSat community . . . . . . . . . . . . . . . . . . . . . . . . . 76

11.5 Press . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7611.5.1 Newspapers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7611.5.2 TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7611.5.3 Magazines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7611.5.4 Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

12Conclusions 77

13Acknowledgments 78

A GMSK modulation 79

A.1 RF angular modulator and RF angular demodulator [57] . . 79A.1.1 FM modulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.1.2 PM modulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81A.1.3 Quadrature modulator . . . . . . . . . . . . . . . . . . . . . . . . 82A.1.4 From PM to FM and vice-versa . . . . . . . . . . . . . . . . . . 82A.1.5 Demodulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

A.2 Modulating-phase generator and bit decoder . . . . . . . . . . 83A.2.1 Modulating-phase generator . . . . . . . . . . . . . . . . . . . . . 83A.2.2 Bit decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

B AMBE voice coding and decoding 88

C D-STAR protocol 89

C.1 Technical Requirements for the Wireless System . . . . . . . . 89C.1.1 Voice Communication . . . . . . . . . . . . . . . . . . . . . . . . 89C.1.2 Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . 90C.1.3 Backbone communication . . . . . . . . . . . . . . . . . . . . . . 90

C.2 System Interconnection Requirements . . . . . . . . . . . . . . 91C.2.1 Wireless Communication Packet . . . . . . . . . . . . . . . . . . 91C.2.2 Communication protocol . . . . . . . . . . . . . . . . . . . . . . 95

C.3 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.3.1 Scrambler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.3.2 Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

C.3.3 Interleave process . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.4 Lexicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

D Schematics of ICOM IC-E2820 100

E Link budget 102

1 Introduction

OUFTI-1 will be the �rst nanosatellite from the University of Liège (ULg), and also the�rst nanosatellite made in Belgium. OUFTI-1 takes place within the framework of along-term program called Leodium (Liège in Latin), the goal of which is to develop aseries of student satellites for scienti�c experiments. The key objective of this project isto provide hands-on satellite experience to students.

The future OUFTI �eet will be controlled via the latest digital ham-radio commu-nication technology, the D-STAR protocol. Putting D-STAR aboard a satellite requiresa complete understanding of the D-STAR technology. We use a two-pronged, fail-safestrategy. On the one hand, we install a D-STAR ground-based repeater connected toa gateway computer allowing access to the Internet, thereby providing worldwide ra-dio/Internet connectivity. On the other hand, we are developing a satellite system basedon acquired experience. We present the complete unraveling of the mystery of D-STARusing a combination of documents, theoretical consideration about GMSK, and practicalmeasurements on our equipment.

The present thesis describes in extrema details of the transmit and receive chains ofa generic D-STAR transceiver. Our view of the transmit chain consists, besides voicecoder and radio-frequency angular modulation, of a digital-to-phase deviation converterfor which we realize a complete simulation. Similarly, our view of the receive chainconsists, besides voice decoder and radio-frequency angular demodulation, of a phasedeviation-to-digital converter for which we realize a complete simulation. The consti-tutive blocks of the digital-to-phase deviation converter are the D-STAR coder and themodulating-phase generator. The constitutive blocks of the phase deviation-to-digitalconverter are the bit decoder and the D-STAR decoder. We test our implementations�rst on synthetic signals, then on real signals of high quality and lower quality.

The ground-based ULg D-STAR repeater/gateway (ON0ULG) is the �rst of its typein Benelux. The OUFTI-1 CubeSat will be the �rst-ever D-STAR based satellite.

Chapter 2 describes the context and motivations of the project. Chapter 3 providesan overview of the D-STAR telecommunication system. Chapter 4 describes the use ofthe D-STAR telecommunication system aboard a satellite. Chapter 5 presents our viewto deal with the intricacies of the D-STAR communication system. Chapter 6 detailsthe D-STAR telecommunication system as found in a ham-radio equipment. Chapter7 presents the telecommunication system of our future CubeSat. Chapter 8 describesthe software implementations we have realized. Chapter 9 describes the experimentalwork we have realized with D-STAR signals. Chapter 10 describes the successive stepsin the installation of the ULg D-STAR repeater. Chapter 11 lists the various activities,presentations, and publications we have realized through this thesis.

1

2 Context and motivation

2.1 Initial motivation

Since about 2003, there has been a desire to develop an educational satellite at theUniversity of Liège (ULg), with ultimate goal of carrying out innovative scienti�c ex-periments in space. This initiative is often referred to as the Leodium project, whereLeodium is the Latin name of Liège. The University is in fact already involved in studentsatellite projects. In the last few years, indeed, the University has been participating inthe European Student Earth Orbiter (ESEO) and the European Student Moon Orbiter(ESMO) projects, which were initiated by the Student Space Exploration and TechnologyInitiative (SSETI) association. For ESEO, the ULg students work on the deployment ofthe solar panels, while for ESMO they are developing a narrow angle camera.

On the 18th of September 2007, the breakthrough idea was formulated (1) of buildinga series of educational nanosatellites, referred to below as CubeSats1, for carrying outspace experiments, and (2) of using the latest in digital amateur-radio communications,namely the D-STAR system, to communicate with the CubeSat. In case of success, our�rst D-STAR-based CubeSat, called OUFTI-1, would become the world's �rst satellitefeaturing D-STAR, as well as the �rst satellite entirely built in Belgium. An overview ofthe D-STAR telecommunications system is provided in Chapter 3.

We emphasize that this is, before all, an educational project for students and bystudents. It is also an interdisciplinary project: it involves, among others, electricalengineers, mechanical engineers, computer scientists and engineers, and physicists. It isalso a great opportunity for cooperation between the University, the technical schools ofLiège, and the local industry.

2.2 Reasons for using amateur-radio telecommunications

The main reasons for using the amateur-radio, or �ham-radio�, communication bandsare as follows. While the radio spectrum is a limited resource, numerous ham bandsare freely and quickly accessible to duly licensed users. We will also be able to getsupport from ham-radio operators [49, 14] worldwide and from the emerging GlobalEducational Network for Satellite Operations (GENSO)2 organization, to help keep trackof the CubeSat, both initially and throughout its lifetime. In exchange, during thetime our CubeSat is not used for scienti�c experiments, we plan to make its D-STARtelecommunication system available to the ham-radio community.

2.3 Reasons for using D-STAR

In Section 2.2, we provided the reasons for using the ham-radio bands for communicat-ing between the ground and our CubeSat. Here, we provide the reasons for using theD-STAR ham-radio technology. Details about the D-STAR protocol are given in Chap-ter 3.

1A nanosatellite is a satellite with a mass of 1 to 10 kg. A picosatellite is a satellite with a massbetween 0.1 and 1 kg. A CubeSat is a picosatellite whose shape is standardized.

2GENSO is a worldwide network of ground stations used to track educational satellites. More infor-mation can be found on [72].

2

The latest in digital amateur-radio technology is the D-STAR system, which wasinitially developed by the Japanese Amateur-Radio League (JARL), and was then �rstcommercialized by the Japanese company ICOM. Other companies are beginning to pro-vide D-STAR capable equipment. D-STAR is spreading at an increasing speed throughthe ham-radio community worldwide, especially in the US and now in Europe. So far, thetechnology has only been used on the ground. Therefore, it is tempting to see whether itcan also be used as the primary means of communication with a satellite. Our �rst orderof business with our �rst CubeSat OUFTI-1 is to verify that we can communicate with,and through, our CubeSat using D-STAR (in order to let more people access to D-STARtechnology thanks to the more extended coverage zone provided by our CubeSat).

Note that we did not start the project by asking what the best technology was tocommunicate with an educational satellite. Instead, we picked the emerging and promiz-ing D-STAR technology for which a lot of hams are already equipped, and took as achallenge, �rst, to investigate whether D-STAR can be used in a satellite system, and,then, to con�rm this with a proof of concept.

As we shall discuss later in more detail, D-STAR uses GMSK modulation. Thereare in fact four a priori arguments that indicate that GMSK might in fact be a reason-able choice for our application. The main advantage of GMSK relative to many othermodulations is to reduce the bandwidth needed. However, the spectral jamming of hambands is not as strong an issue for space as it is already for terrestrial systems, while itis crucial for ground applications. This limited bandwidth problem in space applicationsis traditionally solved by a use towards higher frequencies, such as in satellite televisionworking at more than 12 GHz. Furthermore, GMSK is what is implemented in the ICOMequipment for the terrestrial D-STAR for cost reasons (e.g. GMSK chip available at lowcost. Therefore, it is interesting to use techniques all users are equipped with, so thatham-radio operators can participate in our experiment. Moreover, nobody would investa large amount of money in a narrowspread technology to hear a CubeSat that couldpossibly last only a few days in case of technical problem.

In addition, D-STAR coverage throughout the world is increasing, with a combinationof user transceivers, repeaters, and Internet gateways. This connectivity should proveuseful in getting help from the ham-radio community to aid track our CubeSat, especiallyin case of di�culties.

We insist on the fact we are not trying to construct a full-�edged satellite-basedtelecommunication system with 24 hours-7 days access. The goal of the project is toprovide hands-on experience to students in designing, constructing, and operating Cube-Sats and in carrying out space experiments. Therefore, not picking the absolute besttechnology is not an issue here.

Another advantage of using D-STAR is that it is an open protocol, thereby allowingsigni�cant �exibility in experimentation. By using D-STAR and, thus, the ham-radiobands, we (almost) avoid getting bogged down into proprietary protocols and equipment(except for the proprietary voice coder described in Appendix B). In fact, the proprietaryvoice coder could however be replaced by a di�erent system if necessary. However, ourCubeSat does not need to code or decode the voice stream and, so, we won't need accessto the proprietary aspects of the voice (de)coder to build our CubeSat.

3

In case of success, D-STAR could be adopted by other CubeSat teams, and becomea CubeSat standard. Let us emphasize that our plan to use D-STAR has spread througha major part of the world's CubeSat and ham-radio communities. For example, ourplan was defended at ESA in January 2008 [17] in front of an international audience,mostly European; it was presented at the CubeSat Developer's Workshop (San LuisObispo, CA, USA) [20]; and it was also mentioned on the American Amateur RadioRelay League (ARRL) website [64].

2.4 Communications systems used by amateur satellites andCubeSats

Table 1 gives a list of some of the amateur-radio satellites, together with the main char-acteristics of their telecommunication system. Table 2 does the same for many of theCubeSats built or planned.

Based on Tables 1 and 2, it is clear that most of the amateur satellite featuring digitaltelecommunications are using the AX.25 protocol.

Satellite name Band (in MHz) Modulation In orbit

Analog Digital

AMSAT-1 145/435 FM AX.25 Yes

A0-10 145/435 SSB - Yes

OSCAR-ECHO 145/435 FM/BLU PSK/AX.25/APRS Yes

Table 1: Main characteristics of the telecommunication systems used by amateur satel-lites.

CubeSat name Amateur Bands (in MHz) Modulation In orbit

Analog Digital

AAU-CubeSat 435 - AX.25 Yes

Delphi-C3 145/435 - AX.25 Yes

OUFTI-1 145/435 - D-STAR No

Table 2: Main characteristics of the telecommunication systems used by CubeSats.

2.5 Reasons for using D-STAR

It should be pointed out that AX.25 is strictly limited to the (asynchronous) transmissionof digital data. Contrary to D-STAR, AX.25 does not provide the capability of trans-mitting voice data. Although one could of course easily digitize the voice signal and useAX.25 to transmit the voice data, AX.25 cannot guarantee that the packets will arrivein a timely order and that the receiver will be able to produce an intelligible acousticvoice signal. Therefore, D-STAR has this incredible advantage, of not only being able totransmit digital voice data (in a synchronous way), but of simultaneously allowing thetransfer of digital voice and digital data (in DV mode).

As already indicated above, D-STAR equipment is relatively a�ordable and is �ndingan increasingly large pool of ham operators with its increasing network of repeaters. In

4

other words, ham operators can participate in the OUFTI project without investing inone-of-a-kind expensive equipment.

We can add the following comments. Even though we are not interested in AX.25,since we want to be able to exchange both digital voice and digital data, it should bepointed out that AX.25 implies often QPSK modulation. In QPSK, bits are encoded inpairs and the constellation of points in the complex (I,Q) space are equispaced in angleand at the same radial distance. However, QPSK is not a standard amateur-radio mod-ulation, so that few operators would �nancially and technically be able to participatein our project if we used QPSK. We should also point out that QPSK is a particularcase of the more general M-ary type modulation. The reason QPSK is generally fa-vored is that all points in the (I,Q)-plane constellation are at the same radial distance,which simpli�es the design of the receiver. (This is not true of many M-ary modulations.)

It also appears that many professional (civilian or military) satellites use QPSK orsome M-ary modulation. As pointed out above, the equipment required would no longerbe standard ham-radio equipment. The equipment would probably be much more ex-pensive to build, and it would be di�cult to build a community of users.

Recall that D-STAR ICOM equipment uses (0.5-)GMSK. So, what do we lose byusing GMSK rather than the more standard QPSK and M-ary modulations? It seemsthat the main disadvantage will be that we will require a higher signal-to-noise ratio,or more speci�cally a higher Eb/N0, to achieve the same bit error rate (BER). This isprobably something we can live with in an experimental educational satellite. With somesophisticated digital signal processing on the ground, we may even be able to compensatefor this by adding some �processing gain� [33].

As far as the Doppler e�ect is concerned, we do not see a priori any disadvantage ofGMSK over QPSK or M-ary.

GMSK has a signi�cant advantage in the ground operation, where most ham-radiooperators will in fact use their equipment. Conventional FM equipment (and repeaters)require about 12.5 KHz of bandwidth, as compared to only 6.25 KHz for the GMSK usedby D-STAR. In other words, the use of D-STAR allows one to put more repeaters (andusers) in the ham-radio band reserved for (FM) repeaters.

The reduction in bandwidth comes at the expense of intersymbol interference (ISI).This is why GMSK requires a higher Eb/N0 to achieve the same BER.

The bandwidth reduction allowed by GMSK (and thus D-STAR) is not of primaryimportance for space application, unless the number of ham-radio satellites in orbit (andusing GMSK) becomes signi�cant.

In conclusion, the three massive arguments in favor of D-STAR (which is based onGMSK) are that (1) D-STAR allows, not only the transmission of digital voice, but thesimultaneous transmission of digital voice and digital data, (2) ham-radio operators cana�ord buying D-STAR equipment and are able to use it on the ground (independentlyof any satellite), and (3) D-STAR is bandwidth-e�cient thanks to its use of GMSK.D-STAR seems, in our case, the ideal way to go.

5

2.6 Fail-safe strategy

To minimize risks, we have adopted a fail-safe, two-pronged strategy.

We started by installing a two-band (70 cm and 2 m) repeater system at the ULg,with connection to the Internet via a gateway computer. This system and its installationare described in Chapters 3 and 10, respectively.

On the one hand, this system will ultimately be required to interconnect our CubeSatto the worldwide D-STAR network. On the other hand, it allows us to get some practicalhands-on experience with all the intricacies of the D-STAR protocol and equipment. Asinitially envisioned, and as con�rmed by the work and results described in the presentthesis, this preliminary experience will prove invaluable in designing and constructingour CubeSat system.

Furthermore, the ULg D-STAR system will play a key role (1) in developing a localcommunity of D-STAR users, some of which will probably become future users of ourCubeSat, and (2) in inspiring young people to start engineering studies.

2.7 VEGA Maiden Flight

VEGA is the latest of the European launchers. It is in the �nal stages of developmentand construction. Although ESA announces it should be ready by the end of 2008, itseems more reasonable to imagine that it will be ready by mid 2009 at the earliest.

The VEGA launchers will take o� from the Centre Spatial Guyanais in Kourou,French Guyana. The VEGA launcher is designed to launch small to middle satellites ofa total mass of 600 to 2500 kg. Its lift-o� (excluding payload) mass is about 136 tonsand its length is about 30 m. For comparison, Ariane has a lift-o� mass of 750 tons anda length of 50 m. The primary payload on VEGA's maiden (i.e. �rst) �ight is LARES,an Italian satellite that will perform scienti�c experiments on the consequences of thegeneral relativity.

On its maiden �ight, VEGA will take o� not only with its main payload LARES, butwith a secondary payload consisting of six educational CubeSats. The six correspondingspots aboard VEGA's maiden �ight will be awarded as a result of a competition that washeld in the early part of 2008. About 30 teams throughout Europe were running [12].At the end of January, each team made a presentation [17] at ESA's European SpaceTEchnical Center (ESTEC) in Noordwijk, The Netherlands, in front of an internationalaudience and a jury of experts. Finally, each team wrote a report in mid April [19].The jury has made its recommendation but, as of this writing in late May 2008, we arestill waiting for ESA to announce the selected teams. In any case, our project is movingforward. Let us mention that Professor Robert Twiggs, from Stanford University, CA,USA, the father of the concept of educational satellites, was present at ESTEC duringthe whole 3-day conference and listened to our presentation.

Needless to say that our participation in this ESA competition has signi�cantly in-creased the motivation for this project. Our participation in the competition also mo-tivated us to complete a preliminary installation of our D-STAR repeater prior to theESTEC meeting.

6

2.8 Team

Succeeding in such a large educational project requires a strong interdisciplinary team.During the present academic year, two students worked on the project for their Master'sthesis: Stefania Galli on the mission design, and myself on the D-STAR telecommunica-tions system. Other students joined the team in the course of the academic year, �rstPhilippe Ledent, and then François Mahy. Many of the students who will work on theproject for their Master's theses next year have already been identi�ed; there are about11 to 15 students, some from the local technical schools.

The management team consists of Professors Gaëtan Kerschen (A&M Dept.), PierreRochus (CSL and A&M Dept.), and Jacques Verly (EEI Dept.), as well as Luc Halbachfrom Spacebel in the Liège Science Park.

7

3 Overview of D-STAR telecommunication system

In this chapter, we present an overview of the D-STAR telecommunication system. Weemphasize what is directly relevant to our project. Details are given in later sections aswe go further into the analysis of the D-STAR system. A complete description of theprotocol, the exact knowledge of which is required for our work, is provided in AppendixC [65].

3.1 Key features of D-STAR (except for connectivity)

D-STAR stands for Digital Smart Technologies for Amateur-Radio. It is a digitaltelecommunication system developed by the Japanese Amateur-Radio League (JARL)in 2003. It allows for the simultaneous transmission of voice and data. Voice is coded bythe Advanced Multi-Band Excitation (AMBE) technique [11], which is described in moredetail in Appendix B. With the exception of the AMBE technology, which is proprietaryof Digital Voice Systems, Inc., Westford, MA, USA, the D-STAR standard is mostly open(although the documentation is often incomplete).

D-STAR o�ers two modes of communication, �digital data� and �digital voice�, morecommonly referred to as DD mode and DV mode, respectively. The DD mode transmitsand receives data only, at a rate of 128 Kbps, while the DV mode transmits voice anddata, at a rate of 4.8 Kbps. In DV, the 4800 bauds3 are distributed as follows: 1200bauds are dedicated to data, and 3600 bauds to voice. The 3600 voice bauds are dividedinto 2400 for the voice signal and 1200 for the forward error-correcting code (FEC). Wefocus here on the DV mode because it is the only mode currently used in Europe (eventhough it seems that the DD mode will soon be available in Europe). The DV mode canoperate in the 144 MHz (VHF), 440 MHz (UHF), and 1.2 GHz (L-band) bands, whilethe DD mode requires the 1.2 GHz (L) band. The DV mode, which is of interest to us,provides a limited bandwidth of about 6 kHz.

D-STAR uses Gaussian minimum shift keying (GMSK), with a bandwidth-durationproduct of 0.5, denoted by 0.5-GMSK (Appendix A). The other modulation techniquessuggested in the protocol are quadrature phase shift keying (QPSK) and 4-phase shiftkeying (4-PSK). Since the ICOM equipment uses 0.5-GMSK, we exclusively consider thistype of modulation.

Any digital data can be sent via D-STAR. One example is GPS data. Such GPSdata can be transmitted if the D-STAR transceiver is equipped with a GPS receiver,itself connected to an appropriate antenna. Another example is data from any computerapplication, such as the DSTARLET messaging application [51].

3.2 D-STAR connectivity

There are several possibilities for establishing a communication between two users.

The simplest one is a direct communication from one user to the other (Fig. 1). Ofcourse, the two users must be close enough to establish the link . Users can operate froma �xed ham-radio station, from a �mobile� station (typically in a car), or even from a

3A baud is a unit of measure of the data rate in symbols being transmitted per second. In the presentcontext, bauds and bit/s are synonymous.

8

�portable� station (typically carried by a walking operator).

Figure 1: Direct communication.

Users can communicate over longer distances, and/or overcome obstacles, by using arepeater (Fig. 2). Of course, they must both be within radio coverage of the repeater.

To increase coverage, repeaters can also be linked together to constitute a so-called�D-STAR zone�. This is typically done by microwave links (in the 2.3 GHz ham band orabove).

Figure 2: Local communication through a repeater.

Finally, a repeater can be connected to other repeaters (and thus other zones whenapplicable) anywhere in the world by a gateway computer connected to the Internet.This o�ers worldwide connectivity (Fig. 3).

9

Figure 3: Worldwide communication through a gateway.

Although we showed three di�erent con�gurations (Figs. 1, 2, and 3), it is useful toconsider that there are really only two di�erent scenarios

� Direct communication

� Indirect communication through a local repeater

In the second case, user A in Figs. 2 and 3 is �local� and connects to the repeater byradio, while user B is �distant� and communicates with the repeater either by radio orover the Internet. This concise view is shown in Fig. 4, which can be viewed being anaggregate of Figs. 2 and 3.

Figure 4: Indirect communications through a local repeater.

The worldwide D-STAR connectivity via Internet is managed at the moment by asingle trust server located in the USA. A more complex distributed management will benecessary in the near future. When a user presses on the microphone button to start acommunication, even with a local user, the trust server becomes immediately aware ofthis action and instantly posts the corresponding report of activity on publicly-accessibleweb sites ([69] and [74]). This feature can be disabled if desired.

3.3 Status of worldwide D-STAR network

D-STAR is a relatively recent addition to the techniques of the amateur-radio community.The D-STAR network is rapidly growing. The network is particularly well-developed inthe USA where there are about 100 repeaters as shown in Fig. 5. Because ham-radio

10

operators plays a major role in emergencies, it is not surprising to see a concentration ofrepeaters in the South-East of the USA, where Katrina hit not so long ago4.

Figure 5: US D-STAR repeaters (Source: ICOM America [73]).

Figure 6 shows the network of the D-STAR repeaters in Europe. Compared to the USnetwork, the European network is still quite modest. However, it is expanding quickly.The most recent repeaters are: 1st two in Portugal (January 2008), 1st in France (Febru-ary 2008), and 1st three in Switzerland (March 2008).

On Fig. 6, one can see our own repeater, with callsign ON0ULG: it became opera-tional in January 2008 and was connected to the worldwide D-STAR network in March2008. It is the �rst D-STAR repeater in Belgium and the �rst Internet-

connected D-STAR repeater in Benelux.

4We would like to point out that our repeater remained operational throughout the �ooding thattook place on 29 May 2008 in the Liege area, even though electrical, telephone, and GSM services wereoften unavailable throughout much of the day. This demonstrates the potential of our D-STAR repeaterin case of emergency.

11

Figure 6: European D-STAR repeaters (Source: [74]).

The reader may �nd it interesting to take a look at the website www.j�ndu.net thatgives near real-time information about the activity on the di�erent D-STAR repeatersin the world. On this site, the reader can get all the parameters of all the operationalrepeaters and the callsigns of all active users on each repeater. The website www.d-starusers.org gives the callsigns of all active users in the world. If you see a ham-radiooperator active, say in New York City, you can set up your transceiver to use the D-STARroaming functionality and to communicate with him, e.g. from your car, �rst throughthe ULg repeater, then through the Internet, and �nally through the destination repeaterin New York City.

3.4 GPS

The D-STAR transceivers manufactured by ICOM can optionally be equipped with GPSreceivers. In one sense, GPS data is just a particular form of data. However, thetransceiver of user A can display the GPS coordinates of a user B that A is in con-tact with, provided B is equipped with a GPS module and transmits GPS data. If A isalso equipped with a GPS module, A can also display, both numerically and graphically,its position relative to user B. For example, A can immediately visualize that the userhe is in communication with is, say, at a distance of 19 km or at a distance of 1000 km.GPS is particularly helpful in case of emergency, since one can transmit one's own GPSdata, as soon as one presses the microphone button.

3.5 Equipment

We describe the typical D-STAR equipment, both for users and for repeaters.

12

3.5.1 User equipment

The current workhorse of user equipment is the IC-E28205 [26, 27] (Fig. 7 (a)). It canoptionally be equipped with a GPS module and its corresponding antenna (Fig. 7 (c)).It can operate on two bands of frequencies, 144 MHz and 435 MHz. It even features apair of receivers, meant to be connected to two separate antennas, to provide diversityreception. The 2820 can be used either at a �xed location or as a mobile station. Inany case, it requires a separate power supply. The 2820 has three radio-frequency (RF)power levels; 5 W, 15 W, and 50 W.

The IC-E92D (Fig. 7 (b)) is a portable version, like a walkie-talkie. It can also beequipped with a GPS module (in the optional remote microphone).

Figure 7: Typical D-STAR user's equipment: (a) IC-E2820, (b) IC-E92D, (c) GPS mod-ule and antenna (Source: ICOM [73]).

3.5.2 Repeater equipment

A complete repeater equipment is composed of a controller and three digital repeaters,with one or two transceiver modules for each band of frequency (144 MHz, 435 MHz,and 1.2 GHz)6. Most repeaters, whether D-STAR or more conventional, can listen onone band and retransmit on another. When two di�erent frequencies are used, one talksabout cross-band operation. To perform cross-band operation, the users' transceiversmust also be able to transmit on one band and receive on the other. Figure 8 shows afully-equipped repeater with the various modules, and, on top, cavities that allow therepeater to work in full-duplex mode. Antennas are connected to the cavities which arethemselves connected to the repeaters. The repeater has two RF power levels, 5 W and25 W. Details are given in Chapter 10. A repeater does not need to be connected to

5IC is used as a pre�x in most ICOM ham-radio models.6One module for each of 144 MHz and 435 MHz, and two modules for 1.2 GHz.

13

the Internet. A gateway computer connected to the repeater and appropriate softwareis required for connection to the Internet.

Figure 8: Typical D-STAR repeater. From top to bottom, an IC-2820, two IC-92A, thecontroller, the VHF transceiver, the UHF transceiver, and the two L-band transceivers(Source: ICOM Australia).

3.6 Ways to establish a communication

We now describe how one user goes about establishing a communication with a seconduser [50].

Users are characterized by identities called �callsigns�. The same is true for repeaters.There are typically a source user, a destination user, a source repeater, and a destinationrepeater. In the D-STAR jargon, the callsign of the source user (typically ourselves) iscalled the �MY� callsign and that of the destination user the �UR� (Your) callsign. Stillin the D-STAR jargon, the source repeater is called �RPT1�, and the destination repeater�RPT2�.

Assuming I operate my equipment, I am the �MY� user (the �MY� callsign has twoparts, but this is a detail at this point). The �rst step is to enter, i.e. to program, one'sown, i.e. �MY�, callsign in the transceiver. For the �UR� callsign, there are two mainpossibilities. If we want to communicate with a speci�c user, we enter his/her callsign.If we want to call anyone on a given repeater (speci�ed later), we enter �CQCQCQ�7.To program the repeaters �RPT1� and �RPT2�, we proceed as follows. Since a typicalD-STAR repeater can operate on several bands, we must specify both the (general) re-peater callsign (e.g. ON0ULG) and the frequency. The frequency band is speci�ed byadding a space followed by a letter (the port) after the repeater callsign, typically A for1.2 GHz, B for 435 MHz, and C for 145 MHz. If we want to leave a repeater via theInternet, rather than via radio, we use the letter G (for gateway). (Note that the bandletter is always in the 8th position, even if the repeater general callsign is less than 6

7CQ is a traditional ham-radio acronym. It stands for �seek you�.

14

letters long.)

If we just want to use the local repeater, we have three choices. We can �enter� therepeater on one frequency band, and �exit� either on the same frequency or on anotherfrequency. If we just want to use port B, we enter �RPT1� = �ON0ULG B� and weleave �RPT2� blank. If we want to enter on frequency B and exit on port C (cross-bandoperation), we enter �RPT1� = �ON0ULG B� and �RPT2� = �ON0ULG C�. We can alsouse the G port (the gateway) for roaming within the local repeater's zone.

If we want to access a remote repeater via the Internet, we proceed as follows. Weset �RPT1� as in the previous case (local communications). We set �RPT2� = �ON0ULGG� to tell the system we want to go on the Internet. The �UR� callsign must be set asfollows: �/� , followed by the callsign of the destination repeater, followed by a blank andthe letter of the frequency band we want to exit on. The �/� indicates we want to reachanyone operating through this repeater. For example, if I want to contact anyone on theB port (435 MHz) of the Geneva repeater (with callsign �HB9AR�), the �UR� callsign isset to �/HB9AR B�. It is equivalent to doing a �CQCQCQ� from this remote repeateron band B only. Note that it is not possible to do a �CQCQCQ� on all the repeaters ofthe D-STAR network: indeed, it does not make much sense to ask �Is there anybody outthere on any D-STAR repeater in the world?�. If we want to contact a particular personon a remote repeater, we must set �RPT1� as in a local communication, say �ON0ULGC�, and �RPT2� to �ON0ULG G� to specify we want to communicate via the Internet.The �UR� callsign is now the callsign of the person we want to reach.

15

4 Using D-STAR aboard a satellite: a new concept

The reasons for using D-STAR aboard our CubeSat have already been discussed. Inthis chapter, we focus on what is needed to add a satellite to the worldwide D-STARham-radio communications system. (A link budget is provided in Appendix E.)

4.1 Description of concept

Figures 1, 2, and 3 of Chapter 3 show the three basic, standard D-STAR con�gurations(by order of increasing complexity). As indicated in Chapter 3, it is useful to considerthat there are only two basic scenarios (Figs. 1 and 4):

� Direct communication,

� Indirect communication through a local repeater.

In the second scenario, the link between the local repeater and a �distant� user B is, eitherby radio over the local VHF radio module, or over the UHF radio module (we ignore the1.2 GHz frequency band since our current equipment does not cover this band), or byInternet via the local gateway computer.

Below, we describe how our D-STAR CubeSat can be integrated to work with eachof these two scenarios.

4.1.1 Direct communication

Figure 9 is Fig. 1 with our CubeSat added. As in most satellite telecommunication sys-tems, the transmissions to and from the satellite are on two di�erent frequencies. In ourcase, we use 145 MHz for the uplink and 435 MHz for the downlink8. We therefore don'tneed cavities in our CubeSat, which is quite fortunate because of the size and weight.

Users A and B must be within the footprint of the CubeSat to be able to commu-nicate via the CubeSat. But, otherwise, A and B can be anywhere in the world, i.e. inEurope, in the USA, etc.

The CubeSat will use a speci�c uplink frequency and a speci�c downlink frequencythat will be known, of course, from particular users, principally the ham-radio commu-nity. To go through the CubeSat, A and B just need to dial the proper frequencies:they transmit on the Rx frequency of the CubeSat (around 145 MHz), receive on the Txfrequency of the CubeSat (around 435 MHz), and adjust for Doppler shift on both theTx and Rx frequencies..

The CubeSat continuously listens on the uplink frequency, and simply retransmitsunchanged any upcoming signal, on the downlink frequency. Of course, it is importantthat the CubeSat Tx and Rx frequencies be di�erent from those of any D-STAR repeater,

8The �rst reason for using 145 MHz, rather than 435 MHz, for the uplink is to avoid interference fromground-based radars working around 435 MHz. On downlink, we don't have to worry about �jamming�these radars, given that the transmit power of our CubeSat is extremely small. The second reason isthat, because we have no transmit harmonic as would be the case with downlink on 145 MHz, since thethird harmonic of 145 MHz is 435 MHz, it is easier to deal with the third harmonic on the ground thanin the CubeSat.

16

otherwise the signal of interest would go through multiple paths. Such a situation couldin fact happen in a distant country not aware of the speci�cs of our CubeSat.

The situation is evidently completely symmetrical. The description of what happensfrom A to B is also valid in the reverse direction.

Figure 9: Direct communications via the CubeSat. The two users must be in the CubeSatfootprint.

4.1.2 Indirect communication through a local repeater

Figure 10 is Fig. 4 with the CubeSat added. If user A is in the footprint (or zone) ofthe local repeater, he could, of course, contact B directly via the repeater. Once again,it does not matter whether B is within the footprint of the local repeater or reachablethrough the gateway and the Internet.

What is important in the present scenario is that both A and the CubeSat groundstation be in the footprint of the satellite. The ground station is characterized (1) bymovable antennas that can accurately point to the satellite as it crosses the sky duringany particular pass, and (2) by a dedicated 435 MHz receiver and a dedicated 145 MHztransmitter. Note that the radio link connecting the satellite and the ground stationis not a dedicated link on a distinct set of uplink and downlink frequencies. These fre-quencies are the regular frequencies of the CubeSat, which users know about. As weshall explain later, the fact that there is only one set of uplink and downlink frequenciesis not a problem. It is even an advantage for the whole system because the CubeSatmust transmit what he receives all the time, so users know when they can get onto thefrequency, without disturbing on-going communications.

A key feature of our system is that the ground station is connected to a standardrepeater (Fig. 10). Ideally, both should be close to each other, perhaps in the same rackor in nearby racks. The signal coming down from the satellite can thus be routed toeither one of the VHF, UHF, or gateway modules, and vice-versa. Note that the UHFand VHF modules of the ground station must be distinct from those of the repeater.

17

It is useful to examine what can happen if B is also in the CubeSat's footprint. Thereare essentially two possibilities of interest: (1) B's transceiver is tuned to the CubeSat fre-quencies, or (2) it is tuned to the repeater frequencies. In the �rst case, we are back to thedirect-communication-via-the-CubeSat situation. In the second case, B is not listeningto the direct transmission from the satellite. How does A reach B? A will have speci�edin the set up of his transceiver that the source repeater, i.e. �RPT1�, should be the localrepeater connected to the ground station. Note that, just as in standard D-STAR, A doesnot know where B is located. All that matters is that B be active and connected to a D-STAR repeater anywhere in the world. The routing from �RPT1� to B will be automatic.

Although the situation is not symmetrical, contrary to the �rst case, B can of courserespond to A via the opposite path.

Figure 10: Indirect communications via the CubeSat, its corresponding ground stationand through a local repeater. User A must be in the CubeSat footprint. User B caneither be in the local repeater footprint, or linked to the Internet via another repeater.

4.1.3 CubeSat command and control

Above, we have focused on communications between two ham-radio operators. However,it is clear that the exact same communication channel will be used for the CubeSat own-ers/operators to interact with it, i.e. to send commands to it and to receive telemetryfrom it. (We use telemetry in a wide sense, including data from space experiments.)

Therefore, a strategy will need to be developed to distinguish between the owner/operatorof the CubeSat and members of the ham-radio community using the CubeSat. This isnot further discussed here, but remains an important issue to be addressed by otherstudents in subsequent years.

18

4.1.4 Equipment required

As in any satellite system, we distinguish between the ground segment and the spacesegment.

Ground segment: It is clear from the previous discussion that the key elements ofthe ground station are

� the tracking antennas,

� the dedicated VHF and UHF modules [37], and

� the connection to the local D-STAR repeater.

The focus of this thesis being the space segment9, these three elements are not furtherdiscussed in the sequel. They will be taken up by other students in subsequent years.

Space segment: A CubeSat consists of several subsystems. Here, we focus on thetelecommunications aspects of the CubeSat. Some information about the other subsys-tems can be found in [16, 54, 62].

A high-level, conceptual view of the on-board D-STAR telecommunications systemis shown in Fig. 11. A brief description follows. The �Receiver� box can be conceptuallyviewed as taking the RF signal in, and unpacking from it two separate digital streams:the digital voice and the digital data. The digital voice (and FEC) remains unchangedin the CubeSat, and is retransmitted unchanged back to Earth.

When the operator takes control of the CubeSat (which implies that the ham-radiooperators are, in principle, silent), the �Processor� box extracts, after correct operatoridenti�cation, commands from the data stream and insert telemetry in it. Otherwise,the �Processor� box doesn't change the data stream. The �Transmitter� box essentiallydoes the reverse of the �Receiver� box. It can conceptually be viewed as packing theunchanged digital voice (and FEC) and the (new) digital data onto the outgoing RFsignal. Voice and FEC remain unchanged since we make the assumption that FEC isstrong enough for both uplink and downlink communications. From now on, the digitalvoice and FEC will often be referred to as (digital) voice signals.

Even though highly conceptual, Fig. 11 will prove to be important throughout thisthesis. In the end, we will have explained our detailed view of how the three black boxesshould operate and, in particular, the �Receiver� box and the �Transmitter� box.

9Our work on the general ground-based ULg D-STAR repeater is described in Chapter 10.

19

Figure 11: Telecommunication system for the space segment (CubeSat).

4.2 Modes of operation

The CubeSat can be used in two di�erent modes. The �rst mode is the user-to-usermode. It is described in the previous section. The second mode is the command-and-control mode used to control the CubeSat and to send telemetry down to understandthe state it is in. Telemetry may includes various currents, voltages, and temperatures.We may also want to turn the CubeSat on or o� depending on whether the availableelectric power is high (typically when the CubeSat is in the sun) or low (typically whenthe CubeSat is in darkness).

To use the command-and-control mode, we will have to de�ne a new structure for theD-STAR data. This will be done in subsequent years, based on the detailed understand-ing of the D-STAR protocol acquired through the present thesis. Currently, we imaginede�ning, instead of data and voice blocks (described in Section 6.3.1), new blocks, suchas one for the command, one for the value, and one to designate the exact location inthe CubeSat the value relates to. An example would be �read voltage solar panel two�.When a scienti�c experiment will be aboard, it is common practice to tell the ham-radiooperators that we need the CubeSat, so they will kindly refrain from using it as a com-munication means. A common convention in the ham world is to perform experimentson Wednesdays.

Moreover, we will have to set up an identi�cation procedure that ensures we are theonly ones able to control the CubeSat. Note that any ham-radio amateur will be able todecode the telemetry. However, they may not know the details of the information sentdown to Earth.

When the CubeSat will be in the ULg ground station's footprint, we will be able tocommunicate with it in the command-and-control mode, and thus to get the telemetry.When this is not the case, some D-STAR-equipped ham operator will be able to listen

20

to the D-STAR telemetry sent by the CubeSat, and any ham operator will be able tolisten to the telegraphy beacon, and send the telemetry over to us (this is a main reasonfor having such a beacon). If a signi�cant portion of the CubeSat fails (especially theD-STAR telecommunication system), we hope that the reliable telegraphy beacon willstill be operational, in which case any ham-radio operator anywhere in the world will beable to listen to the beacon telemetry, and send it over to us.

4.3 Comparison with other CubeSats' telecommunication sys-tems

As far as the telecommunication system is concerned, the main similarities between ourCubeSat and those of other student groups, mainly in Europe and in the USA, are that(1) all these CubeSats use the radio-amateur bands (for the reasons stated in Chapter2), (2) they have a means of command-and-control and of telemetry, and (3) they oftenhave a CW beacon as a backup communication mode.

We mainly di�er from all other groups in (1) that we will use the D-STAR telecommu-nication system, while others generally use the more conventional AX.25 communicationsystem, and (2) that our main payload is in fact this innovative, experimental telecom-munication means. The other CubeSats focus instead on scienti�c experiments, whichwe will do on later CubeSats.

We use GMSK modulation, as explained in Chapter 2. GMSK is also used in othersatellites such as Cute 1.7 and CanX-2. Other modulations are also used, such as MSKor AFSK. Our CubeSat will transmit signals at a data rate of 4800 bauds, as do otherCubeSats. Other CubeSats also transmit signals both at a higher data rate, e.g. 9600bauds, and at a lower data rate, e.g. 1200 bauds.

Table summarizes the situation.

OUFTI-1 CubeSat Other CubeSats

Frequency bands UHF, VHF UHF, VHF, S-band

Data rate 4800 bauds 1200, 2400, 4800, 9600

Modulation GMSK MSK, GMSK, AFSK

Protocol D-STAR AX.25

Table 3: Comparison OUFTI-1 vs. other CubeSats (Source: [9]).

21

5 Unraveling the intricacies of the D-STAR com-munications system

D-STAR aboard a CubeSat is a totally new concept. We have discussed in previouschapters how we plan to �integrate� our CubeSat within the conventional ground-basedD-STAR system. It is clear from Fig. 11 that we will need to master the details ofthe D-STAR receive and transmit chains. The present chapter presents our current un-derstanding of the principles of these chains. It also explains how we arrived at thisunderstanding. Unraveling the intricacies of the D-STAR turned out to be quite a chal-lenge.

5.1 Initial knowledge available

When we started, all we had at our disposal was essentially the information of AppendixC and the related documents. In particular, we knew that the modulation was 0.5-GMSK and that the DV-mode data rate on 70 cm and 2 m was 4800 bauds. However, wehad no idea how this baseband information was brought to the carrier frequency, eitherin the IC-E2820 or in the repeater radio-frequency (RF) modules. In this regard, thevarious references consulted were not helpful, in part because there are several ways toproduce a GMSK signal at the carrier frequency, e.g. by frequency modulation, by phasemodulation, or by quadrature modulation. We had no idea which one was used in ourequipments. We even wondered at some point whether a symbol consisted in more thana single bit and to what extent we were in QPSK rather than in GMSK. These initialuncertainties led us to go back to a thorough examination of the theoretical principles ofthe GMSK modulation and its practical implementations. Having cleared up all initialuncertainties, we wrote, in Appendix A, a personal account of GMSK modulation thatis as direct, concise, and pertinent (to our application) as possible.

5.2 Our current understanding of D-STAR

Figure 12 represents our current understanding and view of the D-STAR transmit (Tx)and receive (Rx) chains of the ICOM D-STAR equipment, at least for the IC-E2820.Indeed, we haven't had a chance to check whether Fig. 12 also applies to the repeaterequipment. The Tx and Rx chains are described later.

22

Figure 12: (a) Transmit chain, and (b) receive chain of the IC-E2820.

We emphasize that it took considerable time and e�orts to arrive at the block dia-gram of Fig. 12. There were in fact uncertainties in some of the aspects of Fig. 12 untilearly May 2008. Indeed, it is only when our decoding software, described in Chapter 6,started to produce the correct bits of known synchronization patterns, i.e. the 64 syn-chronization bits and the 15 frame10 synchronization bits, that we began to have strongcon�dence in the validity of the block diagram of Fig. 12. Our work would have beengreatly simpli�ed if someone had provided us with the view of Fig. 12 early on!

Our journey for arriving at the �gure is described in Section 5.7. In brief, we exam-ined various references on GMSK, the schematics of the IC-E2820 (which were not soeasy to obtain), live signals on circuit pins of our IC-E2820, eye diagrams, and spectralanalysis plots. In addition, we bene�ted from the long, hands-on experience of localham-radio operators with various types of radio equipment and modulations.

We also worked hard to make Fig. 12 as modular and concise as possible, so we couldeasily and fully exploit it in our work, including, of course, the design of our CubeSat'sD-STAR communications system. Figure 12 is one of the most important one in thisdocument, and it will often be referred to.

5.3 Description of the transmit (Tx) chain

The transmit (Tx) chain is shown in Fig. 12 (a). The inputs are the analog voice signalvT (t) and the digital bit sequence data, which we denote via the binary discrete-timesequence dT [n] 11 (Notation according to [42, 43, 58, 59, 60]). The subscript T stands

10The term �frame� is commonly used in various digital communication protocols. More formally, aframe is an arti�cial intelligence data structure used to divide knowledge into substructures by repre-senting stereotyped situations.

11Signals indexed by t are continuous-time (CT), and signals indexed by n are discrete-time (DT), orbit sequences.

23

for �transmit (Tx)�.

The signal vT (t) is coded via an AMBE voice coder, resulting in the binary sequencevT [n] . The AMBE voice coder is described in Appendix B.

The voice and data sequences vT [n] and dT [n] enter the D-STAR coder which pro-duces, in a complicated way described in Chapter 6, a single sequence of bits bT [n]. Thissequence is then transformed into an analog �pulsation deviation� ∆ωT (t). Note thatthe CT signal ∆ωT (t) can theoretically take values anywhere in (-∞, +∞)12. Instead of�pulsation�, we may often say �frequency�. We should however not lose track of the factpulsations and frequencies di�er by a factor of 2π.

Finally, ∆ωT (t) is used to drive an RF angular modulator, which produces the RFsignal sT (t) which is then sent to a power ampli�er and to the Tx antenna. At the presenttime, we are virtually sure that the IC-E2820 implements the RF angular modulator viaan FM modulation, rather than via a PM modulation or a quadrature modulation.

5.4 Description of the receive (Rx) chain

The receive (Rx) chain is shown in Fig. 12 (b). The input is the RF signal coming fromthe Rx antenna. We denote it by sR(t). The subscript R stands for �receive (Rx)�. Inan ideal world, sR(t) would be an untruncated time-delayed version of sT (t). The signalsR(t) passes through an RF angular demodulator, producing the (received) �pulsationdeviation� signal ∆ωR(t). This signal is then transformed into the binary sequencebR[n] by the bit decoder. The D-STAR decoder converts bR[n] into the two binarysequences vR[n] and dR[n], corresponding to the (received) digital voice and digital data,respectively. The digital signal vR[n] is decoded via an AMBE voice decoder, resultingin the CT signal vR(t). The outputs of the Rx chain are the continuous-time voice vR(t)and the digital data dR[n].

5.5 Pairing of blocks

On Fig. 12, we can, not surprisingly, notice that some blocks go in pairs. Conceptually,the input signal of one is the output signal of the other and vice-versa. These are

� the AMBE voice coder and the AMBE voice decoder,

� the D-STAR coder and the D-STAR decoder,

� the modulating-phase generator and the bit decoder, and

� the RF angular modulator and the RF angular demodulator.

Note that, on the third line, the names of the paired blocks are quite di�erent.

12The minimum and maximum values taken by ∆ωT (t) are in fact controlled by the parameters of themodulation, in particular the duration T of each �bit pulse�, and its bandwidth B. Note that the rangeof values of ∆ωT (t) should not be confused with that of an unwrapped phase, which is not of primaryinterest here. See Appendix A for details on the form of ∆ωT (t).

24

5.6 Grouping of blocks

The dotted lines in Fig. 12 suggest useful ways of regrouping some fundamental (�atomic�)blocks. In each of parts (a) and (b) of the �gure, one grouping puts the emphasis on theGMSK operation, while the second puts the emphasis on the transition between digitalsignals and the �frequency deviation�, ∆ωT (t) or ∆ωR(t). We will see later that it seemsa particularly good idea to emphasize, and bring to the fore, the frequency deviations,which turns out to play a critical role in our work. We will indeed see later that wecan, in fact, extract ∆ωR(t) from our IC-E2820. (A goal of subsequent theses will be togenerate ∆ωT (t).)

5.7 How did we arrive at the proposed transmit and receivechains?

This section can be skipped without any loss of continuity by the readers only interestedin the main technical aspects and experimental results.

5.7.1 Phase 1: Probing in the IC-E2820

Based on the ICOM schematics of the IC-E2820 (See Appendix D), the D-STAR proto-col found on the American Radio Relay League (ARRL) website [64], and the referencesabout GMSK we have found, we decided to open our IC-2820 transceiver and to extractthree key signals from the GPS module using circuit probes. The �rst signal we tookwas the signal RX SIGNAL IN entering the CMX589A high-speed GSMK modem chip.We initially thought this signal would be sT (t). The second signal we took was theRX DATA signal leaving the CMX589A chip. We initially thought this signal would bebR[n]. The third signal we took was the RX CLK signal. The plot of the RX CLK signalcon�rmed the data rate was 4800 bauds.The eye diagram of RX DATA we made showedus a perfect eye-�gure, periodic of period 1/4800s. We could then conclude RX DATAcorresponded to bR[n].

Since we will ultimately need to produce a GMSK modulation signal aboard theCubeSat, we decided to display RX SIGNAL IN, after an acquisition phase, on Matlab.We observed the data rate was not the 4800 bauds we expected. Moreover, the shapeof the signal was not the one we expected either. RX SIGNAL IN looked more like aGaussian signal, which made us think it was ∆ωR(t). Note that the derivative of ∆ωR(t)would also have had a similar form. We knew already what shape to expect for ∆ωR(t)since we were at that point able to simulate such signals (in Matlab). The fact that RXSIGNAL IN is ∆ωR(t) is our working hypothesis that we �rst have to validate.

5.7.2 Phase 2: Testing the packet-data output

To validate our working hypothesis, we had to acquire the signal more precisely thanjust with probes. Having further examined the ICOM schematics of our IC-E2820, wedecided to focus on the data packet output signal, which was the same signal as the onewe were taking with the probes, except there is an ampli�cation stage between the two.We therefore used a self-made cable connecting the data packet output of our IC-E2820to the soundcard of a computer through its line input. During the signal acquisition onMatlab, the IC-2820 must be set to FM mode and transmit data packets at 9600 bauds(because the other option is 1200 bauds for AFSK, and we want 4800 bauds). After

25

having determined that, totally counter-intuitively, the highest amplitude was the noiseand the lowest one the D-STAR signal (since the signal has a higher level when only noiseis present because we are in FM mode), we could conclude the data packet output signalwas ∆ωR(t), since the data packet output signal had Gaussian-like shape, and a periodbetween zero-crossings of 1/4800s. Therefore, we could validate our working hypothesis.

5.7.3 Conclusion

Since we are now sure the signal coming out of the data packet output is ∆ωR(t), we canimplement the bit decoder and the D-STAR decoder to get the digital voice and datasignals, vR[n] and dR[n], respectively. Similarly, we can also implement the D-STARcoder and the modulating-phase generator to generate ∆ωT from vT [n] and dT [n]. Thisis explained in Chapter 6.

26

6 Detailed analysis of D-STAR communication sys-tem as found in ICOM IC-E2820

6.1 Introduction

In Chapter 5, we brie�y described the path we followed to understand how to produce theD-STAR frames from the analog voice and digital data signals. In the present Chapter,we describe the role of each block of Fig. 12.

The block diagrams of Fig. 12 represent our current understanding of the D-STARcommunication system of the IC-E2820. Having a detailed knowledge of the operationof each atomic block is crucial for our later work, not only in the present thesis, butalso for all the subsequent work on our CubeSat. Some of the blocks shown will indeedbe implemented, either in hardware or in software, certainly on the CubeSat, and alsoprobably in the ground station. In relation to the software implementations, we discusslater, in Chapter 8, the code implemented to create synthetic D-STAR signals, i.e. theD-STAR coder and the modulating-phase generator, and (2) the code implemented todecode both synthetic signals and real signals (the real ones being extracted from theIC-E2820), i.e. the bit decoder and D-STAR decoder.

As pointed out in Chapter 5, each atomic block in the Tx chain of Fig. 12 (a) can bepaired with an atomic block in the Rx chain of Fig. 12(b). These are the AMBE voicecoder and decoder, the D-STAR coder and decoder, the modulating-phase generatorand the bit decoder, and the RF angular modulator and demodulator. Moreover, thecompound blocks can also be paired, i.e. the digital-to-∆ω converter with the ∆ω-to-digital converter, and the GMSK modulator with the GMSK demodulator. Below, wedescribe each of these pairs in detail.

6.2 AMBE voice coder and decoder

The coder transforms the analog vT (t) signal into a digital sequence vT [n], while the de-coder performs the reverse operation, from vR[n] to vR(t). Even if the D-STAR protocolis open, the AMBE algorithm is proprietary and its inner details are not known. Theonly way to perform AMBE coding and decoding appears to be the use of the AMBEchips. In other words, we cannot currently hope to deal with the coding and decoding viasoftware. Therefore, a detailed knowledge of the AMBE inner workings is not crucial toour project. For this reason, and for completeness, a description of the AMBE vocoderis relegated to Appendix B.

6.3 D-STAR coder and decoder

The D-STAR coder transforms the pair (vT [n], dT [n]) into the sequence of bits bT [n].The decoder performs the reverse operation, from bR[n] to (vR[n], dR[n]). To describehow bT [n] is produced and decoded, we �rst need to describe the structure of a D-STARframe. The D-STAR protocol is described in detail in Appendix C. The software imple-mentation is discussed in Chapter 8.

27

6.3.1 Structure of a D-STAR frame

To understand the operations performed by the D-STAR coder and by the D-STARdecoder, it is useful to describe the D-STAR frame (in the DV mode). A complete de-scription of the D-STAR protocol is provided in Appendix C. A frame is a sequenceof bits that starts when a user presses the microphone button, and that lasts until theuser releases the microphone button. A D-STAR frame (Fig. 13) is composed of initialsynchronization patterns, a radio header, and data. This is di�erent from Fig. 13 in thesense we do not consider the synchronization patterns as part of the radio header. Thiswill simplify our notations.

The synchronization patterns are the 64-bit bit synchronization pattern and the 15-bitframe synchronization pattern whose 15 bits are the sequences:

111011001010000.

The 64 bits of the bit synchronization pattern are obtained by concatenating 32 copiesof the basic sequence 10.

The radio header (without the synchronization patterns, as explained above) is 328-bit long. First, there are three �ags, each one being 1 byte long. Flag 1 gives informationabout the communication, while �ags 2 and 3 are left for further development of the pro-tocol. There are then 5 callsign blocks, each one being 8 bytes long, except for the lastone, which is 4 bytes long. The successive blocks are the destination repeater callsign,the source repeater callsign, the companion callsign, the source user callsign 1, and thesource user callsign 2. The radio header ends with the 2-byte P_FCS block. P_FCS isthe CRC-CCITT checksum of the radio header.

Data is composed of successive voice and data blocks, starting with a voice block. Avoice blocks is 72 bits long (and not 72 bytes as written in the o�cial description of theprotocol), while a data block is 24 bit long (and not 24 bytes as written in the o�cialdescription of the protocol). There are three types of data blocks: the user's data block,the synchronization data block, and the end-of-frame data block. The synchronizationdata block and the end-of-frame data block have speci�c patterns. The end-of-frameblock is 48 bits long. Every 21st data block is a data synchronization block, starting withthe �rst data block.

Figure 13: Structure of a D-STAR frame (Source: [65]).

6.3.2 D-STAR coder

The D-STAR coder can be viewed as consisting of three groups of operations. The �rstgroup of operations is performed on the synchronization patterns. The second group of

28

operations is performed on the radio header, and the third group of operations is per-formed on the data, which includes the digital data dT [n] and voice data vT [n].

We �rst construct the synchronization patterns as they are de�ned in Section 6.3.1.

To construct the radio header, the di�erent callsigns are �rst appended together withthe P_FCS block. The result is passed through a convolutional encoder to form the660 bits that are subsequently (1) interleaved to minimize the impact of the error rate(e.g. burst interferences...), and (2) scrambled [5, 4, 30] to randomize the sequence (e.g.to help later demodulating by clock recovery). The bit synchronization pattern and theframe synchronization pattern are inserted in front of the radio header to build a D-STARframe, which is also the bT [n] digital sequence.

To construct the data, the data sequence dT [n] is �rst scrambled to introduce somerandomization on the sequence. Then, the result is divided into 24-bit long blocks. Thedata is then built by appending one data block with one voice block and so on. Datasynchronization blocks are inserted every 21st data block, starting with the �rst datablock. A speci�c end-of-frame block is also added at the end of the frame.

We �nally append the synchronization patterns, the radio header, and the data to-gether to build a D-STAR frame.

6.3.3 D-STAR decoder

The D-STAR decoder can be viewed as consisting of three groups of operations. The�rst group of operations is performed on the synchronization patterns. The second groupof operations is performed on the radio header, and the third group of operations is per-formed on the data, which includes the digital data dT [n] and voice data vT [n].

Decoding a D-STAR frame means �rst �nding the synchronization patterns that areat the beginning of the frame, prior to the data header and the data. Once we havelocated the synchronization patterns (which consists of 64 + 15 = 79 bits), we know thatthe next 660 bits belong to the data header. Since the data is of variable length, wemust keep looking for the end-of-frame pattern (which consists of 16 copies of the basicsequence 10, followed by a 15-bit sequence 000100110101111, and ended by a 0) as wego through the data. As we do this, we must also look for the data synchronization pat-terns (which consist of 5 copies of the sequence 10, followed by 2 copies of the sequence1101000) at the beginning of the data, and then every 21st data block.

To decode the radio header, we �rst descramble the 660-bit sequence, and then dein-terleave the result. Finally, a convolution decoder is applied to get the three �ags, thereal callsigns, and the P_FCS block.

To decode the data, we �rst isolate the voice blocks and the data blocks. The con-catenation of the voice blocks forms the voice sequence vR[n]. To get the data sequencedT [n], we append together the data blocks that are neither data synchronization blocks,nor the end-of-frame block. We then descramble the data blocks to form dT [n].

29

6.4 Modulating-phase generator and bit decoder

The modulating-phase generator transforms the bit sequence bT [n] into a CT signal∆ωT (t) . The bit decoder performs the reverse operation, from ∆ωR(t) to bR[n]. Thesuccinct description to follow relies heavily on Appendix A, which gives our personalview of the essentials of the GMSK modulation for our project.

The modulating-phase generator consists of the two processing steps shown in Fig.14: (1) the digital-to-NRZ converter13 converts the discrete-time signal bT [n] into theequivalent continuous-time signal NRZT (t) that is equal to 1 during the duration of a1-bit or to -1 during the duration of a 0-bit; (2) the Gaussian low-pass �lter produces asits output a smooth version ∆ωT (t) of its input NRZT (t). Note that, in practice, wedon't implement the modulation as the succession of these two steps, but we rather doit in a single step by directly superposing individual Gaussian-convolved pulses.

Figure 14: Modulating-phase generator.

The input of the bit decoder is ∆ωR(t). The output is the sequence bR[n]. Insimpli�ed terms, the bit decoder operates as follows. At each new sample, we estimatethe (reference) zero-level of ∆ωR(t), and we determine which of three states we are in:(1) we are just after a zero-crossing of ∆ωR(t), (2) we are at, or at the closest to, thetime predicted for decoding a bit, or (3) we are in neither of the two previous states.The bit decoder can thus be viewed as a three-state state machine. The implementationof the bit decoder is described in Chapter 8.

6.5 Radio-Frequency angular modulator and demodulator

The RF angular modulator converts the baseband ∆ωT (t) signal into the RF signalsT (t). The RF angular demodulator converts the RF signal sR(t) into the basebandsignal ∆ωR(t). In ideal conditions, ∆ωR(t) should be identical to ∆ωT (t). The angularmodulation (from baseband to RF) can be implemented in several ways, i.e. by FM, PM,or quadrature modulation. It took quite a bit of detective work to �nally establish thatour IC-E2820 uses FM modulation. The frequency deviation signal ∆ωT (t) is used asthough it was an audio signal, and this audio-like signal is used to drive a conventionalFM modulator. ∆ωT (t) plays the role of the traditional �message m(t)� used in manytelecommunication textbooks.

An important parameter in FM modulation is the modulation index β de�ned as[55, 56]

13NRZ stands for non-return to zero.

30

β =∆ffm

, (1)

where ∆f and fm are de�ned as follows. First, ∆f is half the maximum value of | f − fc |,where f is any frequency component in the RF signal sT (t), and fc is the RF carrier fre-quency. In other words, ∆f is the maximum deviation in frequency, with respect tothe carrier, of the RF signal. Second, fm is the maximum (positive) frequency in themodulating (baseband) signal ∆ωT (t). Note that the designers and manufacturers havesome freedom in choosing the ratio of ∆f to fm, i.e. β. In the simplest implementationof FM, via a voltage-controlled oscillator (VCO), the value of β is controlled by the way∆ωT (t) is transformed into the voltage used as input to the VCO. It is customary to dis-tinguish between narrowband frequency modulation (NBFM), corresponding to β < 1,and wideband frequency modulation (WBFM), corresponding to β > 1. Note that themanufacturer decided what maximum half excursion ∆f he wants at RF, and drives itsVCO accordingly.Given the importance of β, we set out to determine what value of β was used in our

IC-E2820. In particular, we wanted to know whether the IC-E2820 operated in NBFMor in WBFM. Our initial guess was that it should be NBFM, so as to reduce the initialoccupied bandwidth in the bands reserved to ham-radio operators.

To obtain the value of fm, we took an arbitrary signal ∆ωR(t) collected from our IC-E2820, and of 4.54 sec in duration, and obtained an estimate of its power spectral density(PSD) by computing its periodogram. This periodogram is shown in Fig. 15. Since theunderlying signal is at 4800 bauds, i.e. 4.8 KHz, we expect fm to be at least 4.8 KHz,which is con�rmed by Fig. 15. The noise �oor appears to be located around -120 dB.In rough terms, that fm is between 5 and 10 KHz. Therefore, we say that fm w 7.5KHz.

Figure 15: Periodogram of a sample signal ∆ωR(t).

Although we could have tried to get the value of ∆f by using a spectrum analyzer(or network analyzer), we decided to use the value given in the D-STAR documentation,

31

i.e. the bandwidth B = 6.25 KHz. ∆f is therefore equal to 3.125 KHz.

The modulation index β of our IC-E2820 is thus

β =∆ffm

=3.1257.5

= 0.4167.

Note that if we took fm equal to 10 KHz, we could get β = 0.3125. One way or theother, this establishes that our IC-E2820 works in NBFM mode, as expected.Besides knowing that NBFM is advantageous from a band usage standpoint, one of the

advantages of knowing whether we are in NBFM or in WBFM mode is that this gives ussome indication regarding how one might think about the frequency content of the FM(RF) signal. For example, we know that, when β � 1, we can make approximation in thetheoretical calculation of the spectrum of an FM signal [57], at least for a cosine mod-ulation signal. One can in fact show that an NBFM signal with β � 1 has a spectrumsimilar to that of an AM signal, the di�erence residing in a sign di�erence on one sideof the carrier. However, we should be carefully in using this convenient approximationsince β = 0.4167 does not really satisfy β � 1.

We currently view the RF angular modulator and demodulator as black boxes. The�rst takes the baseband (�audio�) signal ∆ωT (t) and converts it to the RF signal sT (t),while the second takes the RF signal sR(t) and converts it to ∆ωR(t). Recall that ∆ωT (t)can be viewed as playing the role of the �message m(t)�. At the present time, it is likelywe will use ready-made commercial FM modulators and demodulators in the CubeSatand the ground station.

Once again, key moments in our investigation were the times (1) when we began tosuspect that a key stepping stone in the Tx chain was the signal ∆ωT (t) and that thissignal was used to drive a conventional FM modulator in the IC-E2820, and (2) when weactually located on one of the pins of a circuit in the IC-E2820 a signal that appeared tohave the required theoretical characteristics of a ∆ωR(t) signal.

6.6 Digital-to-∆ω and ∆ω-to-digital converters

As already indicated several times, the signals ∆ωT (t) and ∆ωR(t) constitute importantsignals in the Tx and Rx processing chains, respectively. These signals are in fact at theboundary between digital/baseband signals and radio frequency (RF) signals. Therefore,it makes sense to view the cascade of the D-STAR coder and the modulating-phase gen-erator as a single entity called here the digital-to-∆ω converter, or D/∆ω (converter) forshort. Similarly, it makes sense to consider the cascade of the bit decoder and the D-STAR decoder as a single entity called the ∆ω-to-digital converter, or ∆ω/D (converter)for short14.

We can thus redraw the Tx and Rx chains of Fig. 12 as shown in Fig. 16. The nicething about Fig. 16 is that, in the Tx chain, everything to the left of the D/∆ω converteroutput ∆ωT (t) is digital/baseband, while everything to its right is RF, and similarly forthe Rx chain. This �gure will prove extremely useful for the rest of our work.

14We chose D/∆ω and ∆ω/D by analogy with D/A and A/D.

32

Figure 16: (a) D/∆ω converter in the Tx chain. (b) ∆ω/D converter in the Rx chain.

Recall there is little we can do regarding the AMBE voice coder and decoder, exceptfor using one of the AMBE chips. Similarly, as we have just discussed, there is a priorino reason for trying to implement our own RF modulation and demodulation hardware.This clearly shows that most of our e�orts must be devoted to the D/∆ω and ∆ω/Dconverters, which are shown in isolation in Fig. 17, together with their atomic blocks.Don't forget that Fig. 14 gives the two subblocks of the modulating-phase generator.Much of the rest of this thesis is focused on the two blocks of Fig. 17.

Figure 17: (a) D/∆ω converter. (b) ∆ω/D converter.

33

6.7 GMSK modulator and demodulator

bT [n] in the Tx chain is an important signal because it corresponds to the D-STAR framedigital signal. Therefore, it makes sense to view the cascade of the two atomic blocks�modulating-phase generator� and �RF angular modulator� as a single entity called theGMSK modulator. Similarly, it makes sense to consider the cascade of the �RF angulardemodulator� and the �bit decoder� as a single entity called the GMSK demodulator.Note that the D/∆ω converter and the GSMK modulator overlap, and that the ∆ω/Dconverter and the GMSK demodulator similarly overlap. Using the D/∆ω as a pri-mary block has the advantage of bringing to the forefront the key signal ∆ωT (t) betweenthe D/∆ω converter and the RF angular modulator/demodulator, thereby, here again,showing a clear separation between digital/baseband signals and RF signals. This de-composition (i.e. using the D/∆ω grouping) also appears much more useful from animplementation standpoint. The same can be said about the Rx chain.

6.8 Conclusion

We have described in some detail the various atomic and compound blocks in the Txand Rx chains of Fig. 12. The atomic blocks are the D-STAR coder and the D-STARdecoder, the modulating-phase generator and the bit decoder, and the RF angular mod-ulator and the RF angular demodulator. The compound blocks are the digital-to-∆ωconverter and the ∆ω-to-digital converter, and the GMSK modulator and the GMSKdemodulator. We have shown the fundamental characteristics of the digital-to-∆ω con-verter and ∆ω-to-digital converter compound blocks, both for a conceptual/theoreticalstandpoint and from an implementation standpoint. We have also explained why we donot have to worry about the AMBE voice coder and decoder, as well as about the RFangular modulator and demodulator.

The software implementations of the D/∆ω and ∆ω/D converters are described inChapter 8. We will explain in the next Chapter why and how these two blocks are usefulfor our D-STAR CubeSat's communication system.

34

7 High-level view of our CubeSat D-STAR commu-nication system

Before going further, we show how the conceptual block diagrams of Fig. 11 describingour CubeSat's D-STAR telecommunication system can be �eshed out in terms of theatomic and compound blocks identi�ed in Chapter 6. The result is shown in Fig. 18.

Since we simply want to pass unchanged the digital voice vR[n], there is no need fordecoding the voice and then recoding it. In other words, there is a priori no need for anAMBE voice coder or an AMBE voice decoder aboard the CubeSat.

The digital data dR[n] will be changed since we want to extract commands and inserttelemetry, resulting in the dT [n] sequence. Of course, this will happen only if the D-STAR signal received by the CubeSat is a control signal sent by its operator, who willbe recognized so by the CubeSat thanks to an identi�cation procedure yet to be devised.For regular ham-radio communications, the data dR[n] won't be changed, and it willtherefore be equal to dT [n]. It is clear that data has to be extracted from the D-STARframes to determine whether the current input is a ham-radio communications signal ora command-and-control one.

Figure 18: CubeSat communications system.

The key D-STAR communication blocks aboard the CubeSat are

1. the RF angular demodulator and modulator,

2. the ∆ω/D and D/∆ω converters,

3. the D-STAR data processor.

We therefore have a clean distinction (both at the conceptual/theoretical level and atthe hardware level) between

35

1. radio frequency systems,

2. digital/baseband signal processing,

3. data processing.

As indicated earlier, we may be able to use o�-the-shelf commercial components for theRF angular modulator and demodulator. Therefore, the bulk of the work for developingour CubeSat D-STAR communication system lies in the design and implementation of

1. the ∆ω/D converter,

2. the D/∆ω converter,

3. the D-STAR data processor.

These elements are clearly not available o�-the-shelf. In the rest of this thesis, we focuson the key ∆ω/D and D/∆ω blocks. Work on the D-STAR data processor should beperformed by other students in upcoming years. Among other things, this processor willneed to deal with the nature of the commands and the telemetry, and the distinctionbetween ham-radio communications and command-and-control communications.

36

8 Software implementation of ∆ω/D and D/∆ω con-verters

8.1 Introduction

The ∆ω/D and D/∆ω converters play a key role, not only in the general D-STAR trans-mit and receive chains of Figs. 12 and 16, as found in the IC-E2820, but also in theenvisioned CubeSat system, as shown in Fig. 18. The two converters have been de-scribed in Chapters 6 and 7, respectively.

Historically, we started working on a simulation of the transmit and receive chainsbefore we had a precise understanding of the inner workings of these chains, and in par-ticular, before we knew that the GMSK signal was brought to RF via FM rather thanvia PM modulation or quadrature modulation, and before we knew the key role playedby ∆ωT (t).

As a matter of fact, we simulated a complete quadrature modulator and demodulator,including the demodulator low-pass digital �lters. When our understanding of the innerworkings of the IC-E2820 became clearer and was con�rmed by experiments describedin Chapter 9, we temporarily shelved the software implementation of the RF angularmodulator and demodulator, and refocused our e�orts on what is now clearly identi�edas being the ∆ω/D and D/∆ω converters.

Besides the key role played historically by our simulation work in unraveling theintricacies of the D-STAR communications system (see Chapter 5), the software imple-mentations of the ∆ω/D and D/∆ω converters are crucial for several reasons.

1. Whether we decide to implement the ∆ω/D converter and/or the D/∆ω converterin hardware or software, writing simulations for these two processing blocks forcesus to get an exact understanding of the inner workings of the D-STAR system, andto �nd values for the various parameters involved, such as the truncated length ofeach Gaussian pulse. This will prove invaluable when we set about to design theconverters either in hardware or in software.

2. A software implementation of the ∆ω/D converter can be tested immediately, sincewe are now able to extract the ∆ωT (t) signal from the IC-E2820 in operationalconditions, either directly from a transmitting D-STAR user or via a D-STARrepeater (and more speci�cally, via the new ULg D-STAR repeater described inChapter 10). Our understanding of the D-STAR system, as described in Figs. 12and 16, and our software implementation will prove correct if we can indeed decodereal signals, which, I am happy to report, we can do today.

3. A software implementation of the D/∆ω converter is also useful to develop the soft-ware implementation of the ∆ω/D converter since it allows us to generate syntheticsignals.

4. A software implementation of the whole transmit chain will prove useful to test theCubeSat D-STAR system because we won't have access to real D-STAR signalsfrom space, since such signals won't, we believe, be available until our own CubeSatis in orbit. The software implementation of the D/∆ω converter is thus a crucialpart of the implementation of the whole transmit chain.

37

5. More generally, we want to have, at all times, a complete simulation facility thatallows us to guide the development of various subsystems, and to test their limits invarious conditions. Anything that is done in the CubeSat, and, to some extent, inthe ground station, we want to be able to do by simulation. Our evolving simulationsoftware could lead someday to a full-blown operational simulator.

6. We plan to mix and match hardware implementations and software implementa-tions certainly in our breadboard, and perhaps in the CubeSat and the groundstation.

7. A software implementation of the ∆ω/D converter would give us the �exibilityto handle the unavoidable Doppler-shift, generated by the orbital motion of theCubeSat, directly via digital signal processing.

8. Our software implementation of the ∆ω/D and D/∆ω converters could somedayform the basis for an on-board software-de�ned radio (SDR).

In summary, developing increasingly sophisticated software implementations of the ∆ω/Dand D/∆ω converters, and later of the RF angular modulator and demodulator, arecrucial steps in the overall CubeSat development.

8.2 Detailed description of ∆ω/D software implementation(Rx chain)

The goal of the ∆ω/D converter is to produce, starting from the ∆ωT (t) signal, thedigital voice and data sequences, vR[n], and dR[n]. As shown in Fig. 17(b), this is donein two steps. First, the bit decoder converts the input ∆ωT (t) into the intermediateD-STAR sequence bR[n]. Second, the D-STAR decoder converts bR[n] into the pair ofdigital signals (vR[n], dR[n]).

8.2.1 Bit decoder

The bit decoder takes ∆ωR(t) as input, and produces the bit sequence bR[n] as output.To sample ∆ωR(t), we work at a sampling frequency of 44,1 KHz, which is the com-monly used sampling frequency for audio signals. Since the data rate is approximately4800 bauds, we have an average number of 9.1875 samples per bit. (We would havepreferred to work at 48 KHz to get 10 samples per bit, but our Matlab-based acquisitionsoftware did not allow us to go above 44,1 KHz.)

The signal processing is done sample by sample, and is causal. We built a four-statestate machine, the machine being in one of these four states. Each sample can be, or notbe, at the instant time to decode a bit, and be, or not be, at the instant time of a zero-crossing. Note there is no way it can be simultaneously at the time a zero-crossing justoccured and at the time of decoding a bit. The machine is therefore a three-state statemachine. Table 5 summarizes the possibilities. Although there are four possible states,it doesn't make sense to be at the same time at a decoding time and at a zero-crossingtime. This state is therefore not allowed.

38

Sample zero-crossing non zero-crossing

decoding time NO YES

non decoding time YES YES

Table 5: State machine of bit decoder.

To determine whether each sample corresponds to a 1 or to a 0, we �rst detect the(reference) zero level. We proceed with a window of adjustable length (on both sidesof the current sampling time), and constant all over the signal, to get the envelope of∆ωR(t). To do so, we put in a vector called topvalues all the samples whose values areabove an upper threshold, and in another vector, botvalues, all the values below a lowerthreshold. The thresholds are computed from the zero level amplitude computed at theprevious step (i.e. at the previous sample).

We can be in three di�erent cases. The �rst one (Fig. 19(a)) implies there are onlyvalues above the upper threshold in the current window, with possibly some outliers.The second case is the opposite, i.e. there are mainly negative values relative to thelower threshold (Fig. 19(b)). In the third case, there are both values above the upperlimit and values below the lower limit (Fig. 19(c)). To compute the envelope, we takethe median of the value in each vector, when not empty. If empty, we use the heightof the envelope computed at the previous step (i.e. at the previous sample) to get theminimum value in �rst case, and the maximum value in second case.

Figure 19: Envelope detection. There are three possible cases. (a) Most of the sampleshave values above the zero-level, and there might be some outliers. (b) Most of thesamples have values below the zero-level, and there might be some outliers. (c) Thereare several values above the zero-level, and several values below the zero-level, with somepossible outliers.

From the envelope, we can compute the zero level values by taking the average valuebetween the maximum and minimum of the envelope at every instant.

To increase robustness in the detection of the envelope of the signal, we could usethe RANdom SAmple Consensus (RANSAC) method [15]. This has not yet been im-plemented, but could be explored as a potential improvement, in particular for the casewhere ∆ωR(t) would ��uctuate up and down� over time.

39

We determine when we have a zero-crossing. If the previous sample's value is aboveits zero level and the current sample value is below its zero level, or vice-versa, we have azero-crossing. Note the zero levels for di�erent samples can be di�erent. This geometryproblem is depicted in Fig. 20.

Figure 20: Detecting a zero-crossing. A zero-crossing is the interpolated value at theintersection of the zero-level line and the sample values line.

We also want to know when we need to decode a bit, that is to say when it is time tolook at the current sample and to determine if a are currently �at� a 1-bit or �at� a 0-bit.We use the prediction of the next bit decode time, computed below, to know whether weneed to do this.

If we just had a zero-crossing between the current sample time and the previous sam-ple time, we estimate the current bit length. It can be either calculated on its own basedon the distance between the previous zero-crossings, or also averaged with the previouslength.

To decode a bit, if it is time to do so, we base ourselves on the relative value of the in-terpolated signal at the previously-determined bit-decode time. We determine the valueof the interpolated signal at the next bit-decode time. This is done either by a nearestneighbor method, or by a linear-interpolation method between the two samples aroundthe exact time instant at which we must decode a bit. Other methods, such as quadratureor cubic interpolation, could be implemented in the future, if necessary. We get the inter-polated value of the zero level in the same way. The binary value of the signal ∆ωR(t) atthe time instant we just calculated can then be computed by a comparison between theinterpolated signal value and the interpolated zero level. Note that the bit-value 0 or 1is randomly chosen in case the di�erence between the two interpolated values is too small.

We end up with the binary signal bR[n].

8.2.2 D-STAR decoder

From the just obtained binary signal bR[n], we want to detect the di�erent parts of aD-STAR frame. The D-STAR frame (for DV mode) is described in Section 6.3.1, andthe D-STAR protocol is provided in Appendix C. Figure 13 shows the constituents of aframe. What the algorithm does is taking the binary signal, and �ll in a vector for each

40

di�erent type of bits in the frame, after of course having detected the beginning of aframe. The di�erent types of bits are the bit synchronization pattern, the frame synchro-nization pattern, the radio header, the voice signal, the data bits, the synchronizationdata pattern, and the end-of-frame pattern.

First, we have to determine whether we are at the beginning of a frame. We comparethe pattern of the current bit and the 63 followers with the sequence of 64 bits we shouldhave. Since these are synchronization bits, the pattern might not be exactly equal to thesupposed one. This is why we have added a weighting test. The number of 1's in the oddbits, with the current bit being bit number 1, supposed to be 32, must be higher than aspeci�c value, say 25. We do the same with the even bits, supposed to be 32 0's. If thetests are positive, we check we have the 15-bit frame synchronization pattern just afterthe 64 synchronization bits. If so, we can tell we are at the beginning of a D-STAR frame.

We then store the next 660 bits, making up the radio header. To get the true radioheader of 328 bits as indicated in the protocol, we must successively descramble, dein-terleave, and deconvolve. The intermediate results after descrambling and after deinter-leaving are still 660 bit long. The �nal deconvolution results in a �nal 330-bit long result.To get the true 328-bit long radio header, we must �rst take out the last two, equal to 0and inserted at transmit time, and then reverse the order of each byte, since the protocoltells us the least signi�cant bit of each byte was inserted �rst. We then have the �nal328 bit sequence for the radio header.

The descrambling is described in the protocol. Figure 21 shows how it is performed.Each input bit is xor-ed with the input of the �rst register. The input of the �rst registerat the next time is the result of the xor operation between the fourth and the last bit inthe sequence of registers. The initial state of each register is 1. Note that only the codebit circulate through the registers. More speci�cally, the data does not go through theregisters, as is the case in other schemes.

Figure 21: Descrambling (Source: [65]).

The deinterleaving process is illustrated in Fig. 22. We must construct the deinter-leaving matrix row by row, and then read it column by column to get the deinterleavedsequence.

41

Figure 22: Deinterleaving (Source: [65]).

The deconvolution is performed as follows (Fig. 23). The output is half the lengthof the input. The deconvolution is performed through a Viterbi algorithm that decidesthe value of a bit according to the most likely sequence of hidden states of a trellis. Thetrellis is de�ned according to the protocol de�nition; it has a length of three becausethere are two registers and one input. It has a code generator of [111] for the odd out-put, and [101] for the even output, with a 1 meaning that the output of a register orthe current input bit participates in the xor operation to compute the odd or even output.

Figure 23: Deconvolution (Source: [65]).

We can now work on the data. We will work 96 bits by 96 bits, since a voice blockis 72-bits long, and a data-block 24-bits long. We have already stored the �rst voiceblock, the �rst part of vR[n]. Recall that no operation is performed on the voice signal.

42

For each set of 96 bits, we �rst perform a test to check whether the data block is theend-of-frame block. If so, we are at the end of the frame. If not, we test whether thedata block is a data synchronization block, present every 21st data block, starting withthe �rst one. If so, we store it and store the following voice block. If not, the 24 bitsare user's data dR[n] to be stored. Then, we store the voice block and go on with thenext 96 bits until we reach the end-of-frame block. vR[n] and dR[n] are now ready to beprocessed either by the D-STAR data processor aboard the CubeSat, or by the AMBEvoice decoder, if applicable.

8.3 Detailed description of D/∆ω software implementation(Tx chain)

The goal of the D/∆ω converter is to produce, starting from the digital voice and datasequences, vR[n] and dR[n], respectively, the ∆ωT (t) signal. As shown in Fig. 17(a),this is done in two steps. First, the D-STAR coder converts the pair of digital signals(vR[n], dR[n]) into bR[n]. Second, the modulating-phase generator converts the interme-diate D-STAR sequence bR[n] into the output ∆ωT (t).

8.3.1 D-STAR coder

The D-STAR coder constructs the digital frames bT [n] from the digital voice vT [n] anddata dT [n]. First, data has to be scrambled to introduce some randomization. Scram-bling is implemented in exactly the same way as descrambling is. Recall there is nooperation on the voice signal.

We �rst insert the 64 + 15 bit synchronization pattern into bT [n], and then the660-bits radio header, which is obtained from the 328 bits we had by adding two 0's tothe 328 bits, reversing the bytes in order to insert the MSB �rst into the convolutionalencoder, and performing the convolution encoding. The result is �rst interleaved andthen scrambled. The convolution is implemented using the trellis mechanism. The trellisis the same as for the deconvolution.

The interleaving is exactly the opposite of the deinterleaving as shown in Fig. 22.We insert the successive bits of the radio header column by column, and then read it lineby line.

The scrambling is exactly the same as for the descrambling (Fig. 21).After having scrambled, we can insert the radio header right after the 15 frame syn-

chronization bits.

Before getting the entire D-STAR frame, the data has to be built. We have �rstto calculate the right number of voice and user's data blocks we have in each frame.Starting from that, we insert a voice block, than a data block, and so on until we reachthe right number of voice blocks. Don't forget we have to put the data synchronizationblocks every 21st data block, beginning with the �rst. The data, and thus the frame, endwith the end-of-frame 48-bits pattern. We can now insert the data just after the radioheader.

8.3.2 Modulating-phase generator

We want to obtain ∆ωT (t) from the binary sequence bT [n] just computed by the D-STARcoder. ∆ωT (t) is in fact generated as a DT signal. We have �rst an initialization proce-

43

dure aimed at precomputing quantities we will need later. These are the center time ofeach bit pulse, and the times at which each pulse starts and stops. From these quantities,we determine the start and stop indexes of each pulse. This allows us to get the numberof samples per pulse.

Then, for each bit, we compute the time τ0 of the �rst sample of the pulse, withrespect to the center of the pulse (Fig. 24).

τ0 = nblTs − tb,

with nbl being the start index of current pulse, Ts the sampling period, and tb thecenter time of each bit pulse. We also compute the relative times τ i of all samples of thepulse,

τi = τ0 + iTs.

We can now compute the required values of the function cT,σ,l(t) (See Appendix Afor de�nition of this function). For each relative pulse sample time τ i, the pulse sampleequals cT,σ,l(τi), with

cT,σ,l(τi) = Q [(τi − T/2) /σ]−Q [(τi + T/2) /σ] ,

where Q(x) is the standard Q-function de�ned by

Q (x) =1√2π

ˆ ∞x

exp(−x2/2

)dx =

12erfc

(x√2

).

We then normalize all values of the pulse samples for each bit by dividing each ofthese values by their sum. Figure 24 show a truncated pulse, of length lT. We can �nallyadd the pulse samples cT,σ,l to the output signal ∆ωT (t). We then move on to the next bit.

Figure 24: Cartoon-like view of a pulse sample cT,σ,l of length lT and its samples.

44

9 Experimental work with D-STAR signals

In this Chapter, we discuss the various experiments we have performed both with realsignals and with synthetic signals. The �rst order of business is, of course, to havesignals. Section 9.1 deals with the acquisition of real signals, while Section 9.2 dealswith the generation of synthetic signals. Section 9.3 deals with the decoding of thesesynthetic signals, Section 9.4 presents decoding tools conceived by ham-radio operators,and Section 9.5 deals with the decoding of real signals.

9.1 Acquisition of real signals from ICOM IC-E2820

Initially, we wondered how we would get our hands on real �D-STAR signals�. Eventhe term �D-STAR signal� was quite nebulous in our minds. Recall that, initially, (1)we did not have the nice, modular view provided by Fig. 12, (2) we did not have theslightest idea of what signal to look for, and (3) we certainly did not know that the signal∆ωR(t) played such a major role in the Rx chain. In any case, it was quite clear that wewould need to open up our IC-E2820 (something which we had already done to insertthe optional GPS module UT-123 (Fig. 25).) and poke around with oscilloscope probes.Somehow, we managed to get a full set of schematics of the IC-E2820, which is certainlynot readily available. With the help of the schematics, we identi�ed a number of circuitpoints (including chip pins) that might be interesting to probe, in particular, around theCMX589A high-speed GMSK modem [7, 6, 40] present on the UT-123 GPS module wehad installed. We probed around and looked at various signals. This experimental work,and the decoding work described in Section 6.4, led to the conclusion that ∆ωT (t) was akey signal produced in the IC-E2820. Of course, today, we know how to extract it fromthe IC-E2820. There are in fact two ways of doing so.

Figure 25: UT-123 GPS module in the IC-E2820.

9.1.1 First method for extracting ∆ωR(t) from IC-E2820

The most direct way to acquire ∆ωR(t) from the IC-E2820 is to place a �rst probe on thepin �RX SIGNAL IN� of the CMX589A high-speed GMSK modem chip (the datasheet

45

of which is given in Appendix D) and a second probe on a ground point. The pins are soclose to each other that a magni�er glass is required, as well as a steady hand to avoidshort-circuiting pins. While we initially managed to get real ∆ωR(t) signals in this way,it became quite clear that this was not the way to go for the long term. We then decidedto solder a wire on the appropriate pin and to bring it out of the case of the IC-E2820.However, as we were getting ready to do this, we found an alternate way of getting accessto the same signal in a much more convenient way, which is described below.

Before going further, let us indicate that, in both acquisition methods, the CT (i.e.analog) signal is digitized, at 44100 Hz, via a computer sound card operating under Mat-lab control. The signal ∆ωR(t) is thus available in the form of a DT sequence ∆ωR[n] inthe acquisition computer, and thus in Matlab.

9.1.2 Second method for extracting ∆ωR(t) from IC-E2820

We realized that the desired signal ∆ωR(t) could also be obtained from the IC-E2820directly from the packet-data connector available behind the face-plate of the IC-E2820.We thus built the appropriate cable, with a PS/2 connector at one end, and a 3.5 mmjack at the other end (with the PS/2 plugging into packet-data connector, and the jackplugging into the computer line input).

As we were about to acquire our signals, we had some vague hints that we might haveto set up the IC-E2820 in a di�erent con�guration than the one we usually used for D-STAR communications. Anyway, we used this standard con�guration to record our �rstsignal via the packet-data connector, and the result looked �ne at �rst sight. Rememberthat we still had no idea we were looking at what turned out to be ∆ωR(t)! However,the shape appeared to be all right. But, the timing appeared to be wrong. It took usa while to realize that what we thought was signal (when the transmitter microphonebutton is pressed) was actually noise (when the same button is released). Our mistakewas to assume that the recorded waveform has a higher amplitude in the presence ofsignal, when the opposite was in fact true!

Our analysis and experimentation con�rmed that, indeed, we should set the IC-E2820in standard FM mode, as opposed to the D-STAR DV mode, and that we should setthe packet data rate to 9600 bauds. The available packet data rates are 1200 and 9600bauds, but the 1200 bauds data rate is too low to properly sample our 4800 bauds sig-nals. It should be noted that when we set the IC-E2820 in FM mode, rather than in DVmode, we can no longer monitor the transmission while we record. As an aside, when wedirectly probed the circuit pin and used DV mode, we also could not continue monitoringthe transmission, as though we were overloading the circuit being probed.

Figures 26 and 27 show signals acquired via the packet-data connector, and digitizedvia a sound card under Matlab. The signal of Fig. 26 was acquired on 9 May 2008, froma transmitting IC-92D located about 5 m from the receiving IC-E2820, while the signal ofFig. 27 was acquired on 22 May 2008 from a transmission going through the ON0ULG D-STAR repeater located about 1 km away from the receiving IC-E2820. The transmittingham-radio operator was the same person as the receiving ham-radio operator. The goalof this communication is to check whether a ham-radio operator can enter a repeater. Ifso, the repeater will transmit a signal to the operator. When the microphone button is

46

pressed at the transmitter, a D-STAR signal is received. This D-STAR signal's amplitudeis lower than the amplitude of the noise present when there is no signal being transmitted.

Figure 26: D-STAR signal in direct communication. The receive signal has a loweramplitude when a transmitted D-STAR signal is being received. When no D-STARsignal is being received, the signal has a higher amplitude, corresponding to noise.

Figure 27: D-STAR signal in an indirect communication via a local repeater. The receivesignal has a lower amplitude when a transmitted D-STAR signal is being received. Whenno D-STAR signal is being received, the signal has a higher amplitude, corresponding tonoise.

47

9.2 Generation of synthetic signals

We must begin by deciding what is assumed known to create the desired signal ∆ωT (t),or its digital equivalent ∆ωT [n]. One possibility is to start with the analog voice vT (t)and the digital data dT [n]. As pointed out earlier, we do not have enough informationto perform the AMBE coding ourselves in software. Therefore, we cannot get vT [n]. Inother words, we cannot get the pair (vT [n], dT [n]) which is required as the input of theD-STAR coder (Fig. 12) It is therefore reasonable to start with some bit sequence bT [n].We will thus focus on the synthetic generation of ∆ωT (t) (or ∆ωT [n]) from bT [n]. Inother words, the synthetic data generator described here is nothing but the modulating-phase generator of Fig. 14. As far as testing this converter is concerned, the bit sequencebT [n] is not required to be a valid D-STAR sequence. In other words, we do not haveto worry about the structure of the D-STAR frame, and thus of its radio header and data.

While a frame has hundreds of bits, we can limit ourselves, for testing purposes, toshort bit sequences. As a �rst illustrative example, we consider the short sequence

bT [n] = 1101110001001010. (2)

Our software implementation of the modulating-phase generator is described in Sec-tion 8.3.2, and little else has to be added. We simply need to specify the followingparameters

1. BT product: Bn = 0.5 (for D-STAR),

2. Truncated pulse length in units of T: l = 3,

3. Data rate 1/T = 4800 bauds, hence T = 2.0833 e− 4 s.

Since we generate ∆ωT (t) in DT form, i.e. as ∆ωT [n], we need to specify the samplingfrequency (not to be confused with the data rate). Here, we choose the same value asthe maximum value allowed by our version of Matlab, i.e. 44100 Hz, which is also thesampling frequency used to discretize real audio signals (Section 9.1).

The DT signals ∆ωT [n] produced by our software implementation of the modulating-phase generator for the bit sequence bT [n] in Eq. 2 and the above parameters is shownin Fig. 28. The waveform of Fig. 28 has (reassuringly) the characteristic form of∆ωT (t) signals in (0.5-)GMSK.. Among ourselves, we casually refer to this waveform asthe �camel-humps waveform�. We all instantly know what this refers to, namely some∆ωT (t) signal.

Through our software implementation, we can easily vary all parameters. For exam-ple, we can easily generate ∆ωT (t) of a GSM signal, for which Bn = 0.3. Furthermore,we have various ways of adding jitter to the position of each pulse (and thus of eachhump).

Several interesting observations can be made about the waveform of Fig. 28. Forexample, note that, for isolated 1's and 0's, the signal does not have the time to reachits value of +1 or -1, respectively.

48

Figure 28: Synthetic ∆ωT [n] signal for bT [n] in Eq. 2.

As a second illustrative example, we consider the longer sequence

bT [n] = 01010011010000110010110111101110101100100101000111, (3)

Figure 29: Synthetic ∆ωT [n] signal for bT [n] in Eq. 3.

which has been generated randomly by Matlab. The corresponding ∆ωT [n] is shown inFig. 29.The reasons for being able to generate synthetic signals were given earlier. At this

stage, one of the major advantages of the ability to generate synthetic (GMSK) signals∆ωT (t) (or more precisely ∆ωT [n]) is to familiarize ourselves with the various possibleshapes of such signals. Having a feel for these camel-hump signals is helpful for recog-nizing them in real signals in the presence of noise and other artifacts. Of course, later,

49

synthetic signals will also be useful for testing our Rx chain, at least a portion of it atthis point.

9.3 Examples of decoding of synthetic signals

The modulating-phase generator generates ∆ωT (t) from bT [n]. The inverse operation isproduced by the bit decoder, which generates bT [n] from ∆ωR(t).

Below, we thus applied the bit decoder to the signals ∆ωR(t) (or more precisely∆ωR[n]) shown in Figs. 28 and 29. The resulting bR[n]'s are shown in Figs. 30 and31, respectively. We see that the original sequences bT [n] shown in Eqs. 2 and 3 arerecovered exactly.

Figure 30: Result of decoding synthetic signal ∆ωR[n] of Fig. 28. Result is identical tosignal in Eq. 2.

50

Figure 31: Result of decoding synthetic signal ∆ωR[n] of Fig. 29. Result is identical tosignal in Eq. 3.

Figures 32 and 33 show intermediate signals that are used by the bit-decoder algo-rithm, namely the estimated upper and lower envelopes of ∆ωR(t) (in green and red), aswell as the (reference) zero-level (in yellow). Even though the envelopes and the refer-ence are shown as signals, only the current and past values are used at each sample. Theimportant curve is the zero-level, which is used to �nd the zero-crossings of the inputsignal ∆ωR(t). The zero-crossings are the intersection of the blue and yellow curves, in-terpolated between their samples. In a nutshell, the tracking of the zero-crossings allowsus to determine the time at which the �center� of each next bit is supposed to be located,and thus the time at which ∆ωR(t) must be decoded to produce a 1 or a 0.

51

Figure 32: Signal ∆ωR(t) corresponding to sequence of Eq. 2, together with its upperenvelope (in green), lower envelope (in red), and zero-level (in yellow). The zero-crossingsare at the intersection of the blue and yellow lines.

Figure 33: Signal ∆ωR(t) corresponding to sequence of Eq. 3, together with its upperenvelope (in green), lower envelope (in red), and zero-level (in yellow). The zero-crossingsare at the intersection of the blue and yellow lines.

9.4 Moving on towards bigger challenges

So far, we have focused on acquiring real signals ∆ωR(t) and on generating syntheticsignals ∆ωT (t). Recall that, in practice, these CT signals are actually in their sampledversion ∆ωR[n] and ∆ωT [n]. So far, we have also tested our bit decoder that allows usto go from ∆ωR(t) to bR[n] (assuming ∆ωR(t) = ∆ωT (t) in the case of synthetic signals).

52

We now want to go further. We want to fully decode legitimate ∆ωR(t) signals cor-responding to meaningful digital voice sequences vR[n] and digital data dR[n]. Since wedo not have a complete simulation ready for generating such signals ∆ωT (t) ≡ ∆ωR(t),or more precisely ∆ωT [n] ≡ ∆ωR[n], we have no choice, but to work on real signals∆ωR(t). While being able to fully decode real signals ∆ωR(t) is our ultimate goal, weshould not lose track of the fact that we would someday like to have a full simulationfacility allowing us to generate realistic, legitimate ∆ωR(t) signals.

Because of the initial uncertainties in the de�nition of the D-STAR protocol and thenature of the signals we were dealing with, writing from scratch the software requiredto decode a real signal ∆ωR(t) into meaningful elements, such as callsigns, without anyhints along the way appeared to be an almost insurmountable obstacle, at least in ashort amount of time. Fortunately, as we began to work on this challenging task, webecame aware of the existence of decoding tools that greatly facilitated our task. Theseare described next.

9.5 Decoding tools by others

Recall that the bit decoder converts ∆ωR(t) (or more generally ∆ωR[n]) into a sequenceof bits bR[n]. Doing this correctly on a real noisy signal is already a challenge. However,we are then confronted with identifying synchronization bits, decoding the header andthe voice data and the non-voice data, all this in spite of convolution, interleaving, andscrambling. Needless to say that we must get all this decoding correct before we canstart regrouping bits into bytes and �nally into meaningful ASCII text, where we wouldthen start to recognize key words such as callsigns or �CQCQCQ�. At �rst, this lookedlike a formidable, almost-impossible task, in part because of all the uncertainties andincomplete information concerning the D-STAR protocol.

Fortunately, we found some tools that allowed us to take a real signal ∆ωR(t) andprint down the ASCII text corresponding to all non-voice data. (Recall that to this date,no one outside Digital Voice Systems, Inc., appears to be able to perform the AMBEdecoding without using one of the AMBE chips.)

9.5.1 Tool 1: C program from Satoshi Yasuda [68]

This C program is capable of encoding the �ags, callsigns, and the P_FCS into a 660-bitradio header. For each D-STAR frame, (i.e. the time between pressing and releasing themicrophone button), it successively produces, as intermediate steps, the convolved radioheader, then the interleaved sequence, and �nally the scrambled sequence. The sameprogram also decodes a 660-bit radio header into a 328-bit radio header; It produces thesame intermediate steps as above, but in the reverse order.

Therefore, for decoding, it takes the 660-bit sequence of a D-STAR frame correspond-ing to the radio header and produces the descrambled sequence, then the deinterleavingsequence, and �nally the deconvolved 328-bit radio header.

We show below an example of the printouts produced by the program. We see theinitial callsigns we have speci�ed, then the 328-bit radio header (�testdata with CRC2bytes�), that is then convolved, interleaved, and scrambled to make the 660-bit radioheader. The �nal output sequence is the result of the decoding.

53

Initial test data :

=> RPT2 = "DIRECT "

=> RPT1 = "DIRECT "

=> YOUR = "ON0ULG I"

=> MY = "ON6JY "

testdata :

00 00 00 44 49 52 45 43 54 20 20 44 49 52 45 43 54 20 20 4f 4e 30 55 4c 47 20 49 4f 4e36 4a 59 20 20 20 20 20 20 20 00 00 00testdata with CRC 2 bytes :

00 00 00 44 49 52 45 43 54 20 20 44 49 52 45 43 54 20 20 4f 4e 30 55 4c 47 20 49 4f 4e36 4a 59 20 20 20 20 20 20 20 7d f7 00Interleave output :

12 42 00 20 24 61 42 19 d5 59 61 12 4f d5 35 84 f9 53 4a 41 00 3d f5 75 50 1a 0c 16 3c97 dc 23 c1 7f 41 12 cc 7a b1 28 e3 a9 3f a9 ea a5 b4 � 00 � bb aa 09 05 a9 51 1e ae 0023 df 40 0d 25 db 50 44 eb ab 21 fd 4d 65 2c af 00 f7 fd f5 14 48 0e b0 28Scrambling output :

1c b0 c9 22 02 4f f4 15 01 be d5 38 b5 84 8d 7a e4 b6 d8 45 4c 60 99 6c f9 d5 64 43 c834 ad df fa b4 65 1a 54 c0 69 1b b0 37 ef 02 03 e3 57 07 77 69 f3 bb 38 70 19 37 b9 93a1 74 0d cd ca d5 34 7c d4 c9 c9 ca 9d 80 2b 57 ed af 52 e6 7a f5 96 57 90 28Final output after header composition & decomposition :

00 00 00 44 49 52 45 43 54 20 20 44 49 52 45 43 54 20 20 4f 4e 30 55 4c 47 20 49 4f 4e36 4a 59 20 20 20 20 20 20 20 7d f7 00

9.5.2 Tool 2: D-STAR.exe from Jakub Hruska [75]

The set up is the following. We bring the ∆ωR(t) signal from the packet-data con-nector of the IC-E2820 into a computer via a sound card, and we simultaneously runD-STAR.exe. The program then prints out on the screen the full non-voice data, includ-ing �ags, callsigns, and user's data in an intelligible way. A typical dump is shown below.It corresponds to the following real-life experiment we have conducted on 2 May 2008.

The ham-radio operator ON4YY has set up his IC-E2820 to enter the ULg D-STARrepeater via port C and to leave the repeater via port G, i.e via the gateway. ON4YYsends a message �73 de Jean ON4KJR� to everyone in the Liège D-STAR zone, CQCQCQ,and transmits his GPS coordinates.

54

==== r00t's D-Star decoder - v0.2a ================================(use /? or -h for commandline help, for more info see readme.txt)

Server: bind() failed with error 10048Using card #-1- Soundcard initialized OK - sample rate 48000...Press ENTER to quit...[TRANSMISSION HEADER]Flags : 01 = VOICE DIRECT NORMAL opt=[Relay unavailable] , 00 00Destination : ON0ULG CDeparture : ON0ULG GCompanion : ON4YYStn.Callsign: ON0ULG G /ISYNCh-[END OF TRANSMISSION][TRANSMISSION HEADER]Flags : 00 = VOICE DIRECT NORMAL opt=[None] , 00 00Destination : ON0ULG CtrueDeparture : ON0ULG CCompanion : CQCQCQStn.Callsign: ON4YY /ISYNC - User message: 73 de Jean ON4KJR Data: $$CRC2AEC,ON0KJR>API28²,DSTAR*ISYNC - Data: :!5037.84N/00551.41E>040/027/.ISYNC -MISSD -ISYNC - Data: $$CRC83B4,ON4KJR>API282,DSTAR*:!5037.85N/00551.42EISYNC - Data: >039/026/.ISYNC -ISYNC - Header data: @ ON0ULG BON0ULG CCYCQCQ ON4KJR [BAD CRC]ISYNCh-ISYNCh- Data: $$CRC4107,ON4KJR>API2.2,STAR*:!5037.87N/00551.44EISYNCh- Data: >038/0¶6/.ISYNCh-ISYNCh-ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ½ON4KJR [BAD CRC]ISYNCh- Data: $äCRCE04F,ON4KJR>API282,DSTAR*:!5037.88N/00551.45EISYNCh- Data: >038/026/.ISYNCh- Header data: @ OL0ULG BON0ULG CCQCQCQ ON4KJR [BAD CRC]ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]ISYNCh- Data: $$CRCE04F,ON4KJR>AÐI2(.<äSPAR*:!5037.88N/00551.45EISYNCh- Data: >038/026/.ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]ISYNCh- Data: $$CRCE04F,ON4KJR>API282,DSTAR*:!5037.88N/00551.45EISYNCh- Data: >038/026/.ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]MISSD -ISYNCh- Data: $$CRCE04F,ON4KJR>API282,DSTAR*:!5037.88N/00551.45E

55

ISYNCh- Data: >038/026/.ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [BAD CRC]ISYNCh- Header data: @ ON0ULG CON0ULG CCQCQCQ ON4KJR [BAD CRC]ISYNCh-ISYNCh- Data: $$CRCE04F,ON4KJR>API282,DSTAR*:!5037.88N/00551.45EISYNCh- Data: >038/026/.ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]ISYNCh-ISYNCh- Header data: @00M^0ULG BON0ULG CCQCQCQ ON4KJR [BAD CRC]ISYNCh- Data: $$CRCE04F,ON4KJR>APISTAR*:!5037.88N/00551.45EISYNCh- Data: >038/026/.ISYNCh- Header data: @ ON0ULG BON0ULG CCQCQCQ ON4KJR [CRC OK]ISYNCh-[END OF TRANSMISSION]- Soundcard closed

Carefully note that DSTAR.exe is a �black box�. It decodes ∆ωR(t) into meaningfulpieces of text, but it does not tell us how it does it. (Furthermore, just like us, this toolis incapable to deal with the voice data.)

However, the output of DSTAR.exe is invaluable information. First, if DSTAR.execan do it, we cannot say that the task is impossible! Second, we know that we are work-ing on the correct signal. However, interestingly, this still does not tell us that this signalis ∆ωR(t), and that the D-STAR GMSK is relying on an FM modulator. It is by puttingvarious pieces of the puzzle together that we arrived at the conclusion that the signal wewere working on ought to be a frequency (or pulsation) deviation. As far as we know, weare probably the only ones to have so explicitly stated that this key signal, on the RXSIGNAL IN pin of the CMX589A chip, or at the output of the packet-data connector, isa pulsation deviation ∆ωR(t) (and not its integral, or its derivative, or something totallydi�erent). Third, we know what we have to �nd in the quite opaque bit stream bR[n].Knowing what we had to �nd, and that it could be done, were signi�cant motivations.

The combination of the C program above and of DSTAR.exe allowed us to proceedstep-by-step, being reassured that we would reach our goal sooner or later. Note that, inthe process, we reverse-engineered step-by-step some of the details of the protocol thatwere unclear or missing.

9.5.3 Tool 3: DV Dongle [36]

We could also have used a DV dongle, Fig. 34, developed by MoeTronix. This is anelectronic gadget connecting to the computer via a USB port, and that is capable ofdecoding the D-STAR frames, showing the callsigns, and playing the voice being trans-mitted. (Not surprisingly, DV Dongle is using an AMBE voice decoder.) However, asthe DSTAR.exe is enough and since playing the voice doesn't bring us more information,we have decided not to acquire one, at least at the time of this writing.

56

Figure 34: DV Dongle (Source: [36]).

9.6 Examples of decoding of real signals

9.6.1 Introduction

We �rst present two example signals. The �rst (Fig. 35) corresponds to a direct com-munication signal between an IC-92D and an IC-E2820 both located in room R138. Thesecond (Fig. 36) corresponds to an indirect communication signal between the local ULgrepeater at the PCC and a user in room R138 at the Monte�ore Institute. Notice that the�rst signal is nicer than the second (and closer to the theoretical camel-hump form). Thereason for the di�erence is that the distance between the two transceivers is smaller forthe direct communication signal than for the indirect communication signal. However,note that this could be exactly the opposite.

Figure 35: Sample of ∆ωR[n] of a direct communication signal between an IC-92D andan IC-E2820.

57

Figure 36: Sample of ∆ωR[n] of an indirect communication signal between the repeaterand an IC-E2820.

We then present two example signals that are longer than those of Figs. 35 and 36,and that we will process through our algorithms. The �rst, which we will call signal A,(Fig. 37) corresponds to ∆ωR(t) of the direct communication signal. The second, whichwe will call signal B, (Fig. 38)corresponds to ∆ωR(t) of the indirect communicationsignal. as in the previous case, notice that signal A is nicer than signal B (and closer tothe theoretical camel-hump form), for the same reason as above.

Figure 37: Signal A, which is corresponds to ∆ωR(t) of a direct communication signal.

58

Figure 38: Signal B, which is corresponds to ∆ωR(t) of an indirect communication signal.

The reason why we consider the two cases of Figs. 37 and 38 is that 37 correspondsto a clean, near-ideal ∆ωR(t) signal, while 38 corresponds to a noisier, less ideal ∆ωR(t).(The reason is not that one corresponds to a direct communication signal and the otherto an indirect communication signal.)

We now describe the operation of the bit decoder and of the D-STAR decoder oneach of the ∆ωR(t) of Figs. 37 and 38.

9.6.2 Envelope detected and zero-level detected

We �rst need to check out that the envelopes the bit decoder correctly tracks what weperceive as the top and bottom envelopes of the signal, thus allowing to determine the(reference) zero-level. Figures 39 and 40 show the envelopes of signals A and B, respec-tively. We can see the envelope detection routine works perfectly in both cases. Thisallows us to determine the (reference) zero-level, which is the signal we need to detect bits.

59

Figure 39: Estimated upper (green) and lower (red) envelopes, and resulting referencezero-level (in yellow, roughly midway between the envelopes) for signal A.

Figure 40: Estimated upper (green) and lower (red) envelopes, and resulting referencezero-level (in yellow, roughly midway between the envelopes) for signal B.

9.6.3 Synchronization patterns

The �rst thing to do after having determined the zero-level is to recover the synchro-nization patterns of the signals we have analyzed. Figure 41 show the synchronizationpattern in the ∆ωR(t) signal, and Fig. 42 show the corresponding detected bits for signalA. We get the same graphs for signal B. We can immediately see in Fig. 42 the 64-bitsequence of alternating 1's and 0's, i.e.

1010101010101010101010101010101010101010101010101010101010101010,

60

as well as the 15-bit sequence that is equal to

111011001010000.

It appears that an upward-pointing hump in the ∆ωR(t) signal actually correspondsto a 0-bit and that a downward-pointing bump in ∆ωR(t) corresponds to a 1-bit. Thatis something that is apparently not covered in the protocol. Even though we were readyfor this inversion of polarity, this uncertainty made our task more di�cult, especially inthe beginning when there were so many uncertainties.

Figure 41: Synchronization patterns in ∆ωR(t) signal for signal A. The upward-pointinghumps correspond to a 0-bit, and the downward-pointing humps correspond to a 1-bit.We can easily recognize the synchronizations patterns.

Figure 42: Detected synchronization patterns for signal A. We recognize the 64-bit syn-chronization pattern, and the 15-bit frame synchronization pattern.

Once we have those synchronization bits, we can isolate the �radio header� and the�data�. We will work on each one separately. On the one side, after having identi�ed the

61

synchronization blocks and the end-of-frame block, we only have to apply descramblingto the data blocks while the voice blocks remain unchanged. On the other side, wemust apply the descrambling, deinterleaving, and deconvolution operations to the �radioheader�.

9.6.4 Radio header

Assuming the operational conditions are reasonable, the sequence bR[n] contains one ormore frames, and thus the same number of radio headers of 660 bits. The successiveoperations we perform on the 660-bit radio header to recover the 328 bits de�ned inthe protocol are descrambling, deinterleaving, and deconvolving. These operations aredescribed in Chapter 8. Thanks to the three successive outputs printed out by the Cprogram of Satoshi Yasuda (Section 9.4), we were able to check our results after each ofthese operations.

Descrambling the 660 bits gives us another sequence of 660 bits. Deinterleaving thissequence gives us another sequence of 660 bits. Deconvolving this sequence gives us a330 bit-long sequence. In this sequence, we have to delete the last two bits that shouldnormally be equal to �0� as stated by the protocol (they are in fact equal to 0). In theremaining 328-bit sequence, we invert each byte because in the generation of the radioheader at transmission, the LSB was inserted �rst in the convolutional encoder. We endup with the true 328-bit radio header for the frame of interest.

When analyzing signal A, each sequence at each step was identical to the sequencesobtained by the C routine when the callsigns inserted in the C routine and the call-signs in the IC-92D are the same. The resulting radio header is shown in Fig. 43. Thedi�erent bytes can be converted into ASCII code. This gives us the callsigns statedin Table 6. The �MY� callsign is �ON6JY�, the �UR� callsign is� ON0ULG I�, and the�RPT1� and �RPT2� callsigns are set up to �DIRECT� since it is a direct communication.

Figure 43: 328-bit radio header for a signal A.

We proceed exactly the same way for signal B. The 328-bit radio header is shown

62

in Fig. 44. We get the following callsigns. �MY� has been set to ON0ULG since thesignal has been sent by the ULg repeater (the signal sent to the repeater was askingthe repeater to send us a signal. This is usually done by a ham-radio operator to checkhe can �enter� a repeater), �UR� to CQCQCQ, �RPT1� to ON0ULG C, and �RPT2� toON0ULG G. The decoding of the radio header for signal A and signal B is summarizedin Table 6.

Figure 44: 328-bit radio header for signal B.

Signal A Signal B

�MY� ON6JY ON0ULG

�UR� ON0ULG I CQCQCQ

�RPT1� DIRECT ON0ULG C

�RPT2� DIRECT ON0ULG G

Table 6: Radio header analysis.

We have detected and decoded the radio header. We can now analyze the data.

9.6.5 Data

We must now analyze the data to go from bR[n] to the digital and voice signals, dR[n]and vR[n], respectively. Voice and data blocks are inserted one after the other, startingwith a voice block (Fig. 13). We make the distinction, as usual, between signal A andsignal B. We do so because signal A is close to synthetic signals, while there is more noisein signal B (see Section 9.6).

Recall there is no operation performed on the voice block. We form vR[n] directly byappending the voice blocks together.

To get dR[n], we must �rst detect the data synchronization blocks inserted every 21st

data block, starting with the �rst data block, and the end-of-frame block. We show these

63

two particular blocks in Figs. 45 and 46 respectively. The data synchronization block is24-bit long. It consists of the following sequence

1010101010︸ ︷︷ ︸ 1101000︸ ︷︷ ︸ 1101000︸ ︷︷ ︸ . (4)

The �rst part is a 10-bit sequence consisting of alternating 1's and 0's. The secondand third part each consists of the same 7-bit sequence.

The end-of-frame block is 48-bit long. It consists of the following pattern: a 32-bitsequence alternating 1's and 0's, then a 15-bit sequence that is exactly the complementof the frame synchronization sequence, and a �0�.

10101010101010101010101010101010︸ ︷︷ ︸ 00010011010111︸ ︷︷ ︸ 0︸︷︷︸ . (5)

We decode and detect the data synchronization blocks and the end-of-frame blockboth for signal A and signal B.

Figure 45: Data synchronization blocks for signal A and signal B. We easily recognizethe pattern described by Eq. 4.

64

Figure 46: End-of-frame block for signal A and signal B. We easily recognize the patterndescribed by Eq. 5.

We have decoded the user's data blocks. Before getting dR[n], we need to perform adescrambling operation on the user's data blocks.

9.7 Reconstruction of frames

In the D-STAR coder, we want to reconstruct the D-STAR frames from the voice anddata signals, vT [n] and dT [n], respectively, that we have decoded in the previous section.To reconstruct a D-STAR frame, we reconstruct the radio header and the data as ex-plained in Chapter 8. In our simulation, we start from the decoded blocks of the previousSection, i.e. from the synchronization patterns, the 328-bit radio header, the digital voicevR[n], and the digital data dR[n]. The graphs are the same as in the previous section,but in the reverse order.

9.8 Performance

An important issue when working in digital telecommunication is the bit error rate (BER)achieved. As shown on the previous �gures of sections 9.3 and 9.6, we don't get any er-ror on the synchronization pattern, neither on the 64 synchronization bits nor on the 15frame synchronization, of the signals we have analyzed. All the synchronization data arealso correct, and so is the end-of-frame data.

However, there are two di�erences between the signals ∆ωR(t) we have analyzed, onecoming from a direct communication, signal A, and the other coming from an indirectcommunication, signal B. The di�erences are that (1) the distance is smaller for the directcommunication than for the indirect communication, and (2) the repeater has a power of25 W, while the user can have up to 50 W. Indeed, we don't have any error, neither on thesynchronization patterns, nor on the radio header, nor on the data synchronization blocksfor signal A. Furthermore, we detect the right number of bits in the data blocks and in

65

the voice blocks. For signal B, we do not detect the expected number of bits neither forthe voice blocks, nor for the data blocks, despite the fact all the synchronization databits are correct. We detect from 1 to 10 more bits than expected. We should detect,between two data synchronization blocks, 20 voice plus data blocks, plus a voice block.That makes

20 ∗ (72 + 24) + 72 = 1992 bits.

We instead detect from 1982 to 1996 bits. This gives us a bit-error rate (BER) of

BER =1992− 1982

1992= 0.005

at least. Indeed, there may be other bits that are incorrect in the voice and data blocks.

This observation must lead us to make the bit decoder more robust to degradationin signal quality, since signals coming from the repeater and signals coming in directcommunication present di�erent shapes, as shown on Figs. 35 and 36. Indeed, the shapeof ∆ωR(t) for signal A looks more to the theoretical signal than for signal B, thus leadingto a lower BER. On the one hand, the shape of signal A is quite close to the syntheticsignal, since the distance between the two transceivers is relatively small. On the otherhand, the distance between the repeater and a user's transceiver is bigger, thereforeintroducing more noise.

9.9 Conclusion

We have described the experiments performed on di�erent signals to check out the valid-ity of our implementations of the ∆ω/D and D/∆ω converters. We have bene�ted fromsoftwares developed by other ham-radio operators to help us along the way, by allowingus to check the accuracy of intermediate results. We can say our implementations workperfectly on synthetic signals and on real signals of reasonable quality. We have observedsome errors in the bit decoder when the signal comes from a repeater because the shape ofthe real ∆ωR(t) signal di�ers signi�cantly from the shape of the theoretical camel-humpsignal. However, we still can get most of the information from those signals.

We are only at the beginning of our attempts at decoding signals. Our algorithmwill progressively be more robust to noise and other artefact's. For example, we havesuggested the use of RANSAC to better track the envelope of �uctuating signals. Theseimprovements will be considered in subsequent theses by other students.

66

10 Installation and con�guration of ULg's D-STARrepeater

10.1 Introduction

To understand the D-STAR telecommunication system, we have installed our own re-peater system at the ULg, with callsign ON0ULG, on two frequency bands. These arethe 435 MHz band (on the B port), and the 145 MHz band (on the C port). We alsohave installed a gateway through a computer on G. We present in this chapter a historyof our installation and con�guration of the G port of the ULg's D-STAR repeater.

10.2 First installation

We have installed the �rst set-up of the repeater and the IC-E2820 user's equipmentin room R138 of the Monte�ore Institute on January 3, 2008. Figure 47 shows on theleft side of the desk the three gray boxes, which are the controller on top, with the twotransceivers (one for UHF and one for VHF) just below. The con�guration was madethanks to the user manuals of the controller and the transceivers. For the �rst tests, onlythe 70 cm frequency band on the B port was installed.

We also see a power supply (on the right side of the desk in Fig. 47) that suppliesthe controller and the user's equipment (Fig. 48) we have installed the same day, also inroom R138. We have put an antenna on metal plane used as a master plan (Fig. 49).

Figure 47: First installation of the repeater in room R138 in January 2008. On the left,the controller on top of the UHF and VHF transceivers. On the right, the power supplyconnected to the controller and to the IC-E2820. A computer was used to con�gure therepeater.

67

Figure 48: User's equipment IC-E2820 in room R138 in January 2008. The IC-E2820 iscomposed of a microphone, a screen, and a processing unit.

Figure 49: Antenna on a metal ground plane in room R138 in January 2008.

After having con�gured our IC-E2820 [26, 27], we realized our �rst D-STAR commu-nication via a repeater in the Benelux, thanks to two local ham-radio operators that hadjust equipped themselves with D-STAR equipment, after some phone calls to verify thatthe two ham operators were entering the same callsigns in the IC-2820's.

10.3 Second installation

After having done the �rst tests and having defended our project at ESTEC, we wentfurther in the installation of the repeater. We installed two antennas, one for the UHFband, and one for the VHF band, on top of a tower in the center courtyard of the Mon-te�ore Institute, as shown in Figs. 50 and 51. This was done with the precious help oflocal ham-radio operators. Since we had two antennas, we have installed the 70 cm and

68

the 2 m frequency bands on ports B and C, respectively.

The repeater was then moved to the basement of Monte�ore, in room S131. To beable for the repeater to work in full-duplex, we installed temporary cavities on the 435MHz band as shown in Fig. 52.

Since the antennas were higher than in the �rst installation, and since antennas onthe tower were outside the building and no more in a room, we could get better signalsfrom and to the repeater than before. Users from further away could therefore enter therepeater, which they couldn't with the �rst installation. We have been able to establishcommunications with di�erent users, from Ans to Cheratte (on the next day, since allD-STAR equipped ham-radio operators were at the Monte�ore Institute on this day).Figure 53 shows the repeater, and Fig. 54 shows our IC-E2820 and the power supply.

Figure 50: Antennas on tower in the middle of the courtyard of the Monte�ore Institute.One antenna is for the 435 MHz band, the other antenna is for the 145 MHz band.

69

Figure 51: Antennas on the ground. We check the tightness of the connections beforeraising the tower.

Figure 52: Temporary cavities installed on the 70 cm frequency band to allow full-duplexoperation of the repeater.

70

Figure 53: Second installation in room S131. In the back, the controller on top of theUHF and VHF transceivers. In the middle, the temporary cavities. On the lower right,the power supply.

Figure 54: On the left, the power supply shows voltage (13.8 V) and current (0.07 A),in the receive mode. On the right, the IC-E2820.

10.4 Installation of gateway

Up to this point, we had only con�gured the ports B and C, for the UHF and VHF fre-quency bands, respectively. We could therefore only communicate with local ham-radiooperators. To communicate with worldwide users, we had to install a gateway, on the Gport, i.e. a computer and the appropriate software.

Under the advice of Prof. Boigelot of the Monte�ore Institute, we �rst used a CV763Amothercard (Fig. 55) to install the gateway software. Although it was a good idea sincethe card is small and can thus be inserted in a rack together with the repeater, there

71

were some problems. After quite a bit of investigation, we noticed that the mothercardhad been delivered without the required electric fans or passive coolers over critical chips.The temperature of the CPU was therefore too high (about 85°C), leading to frequentcrashes of the card. After having installed the missing fan and coolers, we con�guredLinux Fedora Core 8, �rst on an external router, and then on a virtual router. The map-ping of the Ethernet links were di�erent, and thus, had to be recon�gured. We then hadreception problem at 100 MBps. We have therefore tried another router. However, thislast router didn't support the 255.0.0.0 mask, which was required by the D-STAR con-troller since the controller runs a 10.X.X.X subnetwork. All these problems were solvedusing a virtual router that provides the transition from an IP address 139.165.16.X tothe 10.X.X.X address.

Figure 55: CV763A motherboard used as a gateway.

Since then, we have temporarily gone back to a standard computer under FedoraCore 8, and we have recon�gured the router card in Cent0S 5.0, as asked by ICOM. Theversion 2.0 of the gateway software was also successfully installed. Currently, we arewaiting to transfer the computer con�guration to the router CV763A mothercard. Thiswill be done when we will move our equipment into a 19� rack.

With the above-described installation, we ready to be connected to a test serverlocated in Germany. This was the �rst step before being connected to the trust serverK5TIT located in the USA. The second step was to have one of the members of theteam passing a D-STAR certi�cation organized by ICOM via an American quali�cationorganism to certify we know how to operate our repeater. Then, since the use of therepeater was satisfactory, our repeater's gateway was �nally hosted on the trust server.

10.5 Final installation

Although the repeater's installation of Section 10.3 was working correctly with the gate-way installed, we wanted to increase the coverage zone of the repeater. In order to doso, we moved the repeater to the Poste Central de Commande (PCC) of the ULg. Thecoverage map (Fig. 56) was computed for the 435 MHz band, for antennas such as theones stated in the ON0ULG license application form, and is based on digital cartography,with a resolution of 300 m. The software we used is RadioMobile [45].

72

Figure 56: Coverage zone of repeater ON0ULG B. The center is on the PCC, with Northpointing up (Source: [66]).

We show the current installation and the current antennas in Figs. 57 and 58, re-spectively.

Figure 57: Current installation of ON0ULG repeater. On the left �gure, we see the VHFcavities on the back left, the power supply in the front left, the UHF cavities in thecenter, and the controller on top of the UHF and VHF transceivers on the right. On theright �gure, we see the controller on top of the UHF and VHF transceivers on the left,and the gateway computer on the right.

73

Figure 58: Current antennas. The antenna on top of the tower is used for the 435 MHzband, and the antenna on the left of the �gure is used for the 145 MHz band.

74

11 Miscellaneous activities, publications, and pre-sentations

11.1 Introduction

In addition to the technical work described in this thesis, we engaged in related severalactivities, we made four presentations, and wrote two papers and reports. Our projectwas also the object of several reports in the press and on websites. Since many of our pre-sentations were at the international level, most of our presentations and papers/reportswere written in English.

11.2 Local and international presentations

� GALLI Stefania, PISANE Jonathan, D-STAR based student CubeSat of Universityof Liege (Leodium), 24 January 2008, ESTEC, Noordwijk, The Netherlands [17].(Presentation in front of international audience to defend the Leodium project toget a spot on the VEGA maiden �ight.)

� GALLI Stefania, LEDENT Philippe, PISANE Jonathan, OUFTI-1: New Studentnano-Satellite at ULg, 22 February 2008, Monte�ore Institute (R3) [18].

� GALLI Stefania, LEDENT Philippe, PISANE Jonathan, DENIS Amandine, VAN-DENRIJT Jean-François, KERSCHEN Gaëtan, ROCHUS Pierre, VERLY Jacques,HALBACH Luc, OUFTI-1: Le CubeSat en développement à l'Université de Liège,9 April 2008 & 26 April 2008, Monte�ore Institute [21] . (Two presentations of theproject to future students at the astronauts day and at the future students' day.)

� GALLI Stefania, LEDENT Philippe, PISANE Jonathan, DENIS Amandine, VAN-DENRIJT Jean-François, KERSCHEN Gaëtan, ROCHUS Pierre, VERLY Jacques,HALBACH Luc, OUFTI-1: The CubeSat developed at the University of Liège, Bel-gium, 5th Annual CubeSat Developer's Workshop, San Luis Obispo, CA, USA 9-11April 2008 [20].

11.3 Publications

� GALLI Stefania, LEDENT Philippe, PISANE Jonathan, The D-STAR based stu-dent CubeSat of the University of Liege (Leodium project), 16 March 2008, 16pages [19]. (Report of the project to ESTEC to defend the Leodium project to get aspot of the VEGA maiden �ight.)

� GALLI Stefania, LEDENT Philippe, PISANE Jonathan, DENIS Amandine, VAN-DENRIJT Jean-François, KERSCHEN Gaëtan, ROCHUS Pierre, VERLY Jacques,HALBACH Luc, OUFTI-1: The CubeSat developed at the University of Liège, Bel-gium, 9 April 2008, San Luis Obispo, CA, USA. (Abstract of the presentation ofthe project at the CubeSat Developer's Workshop.)

11.4 Activities

11.4.1 Ham-radio license

A ham-radio license is required to operate ham-radio equipment. In Belgium, there aretwo types of licenses:

75

� ON3 license

� HAREC license

Altough many candidate ham-radio operators �rst obtain an ON3 license, I decided todirectly go for the more complete HAREC license [10]. I got my HAREC license inDecember 2007, with callsign ON7JPD. Philippe Ledent, who will work on the projectnext year, also got his license, with callsign ON4MDR.

11.4.2 CubeSat community

ULg became a member of the CubeSat community in May 2008 [67].

11.5 Press

11.5.1 Newspapers

� Bientôt un satellite �OUFTI� dans l'espace?, Wauters Laurence, La Meuse, 23February 2008 [61] .

� Etudiants en orbite, l'ambition d'un satellite liégeois, Théo Pirard, Le 15me Jour,February 2008 [47].

� OUFTI-1, le Spoutnik des jeunes liégeois, Pascale Serret, Le jour Huy-Waremme,22 February 2008 [52].

� OUFTI, nanosatellite à la liégeoise, Théo Pirard, Athena 240, April 2004 [48].

11.5.2 TV

There was an interview [76] from the Liège local television network (RTC) made on 22February 2008.

11.5.3 Magazines

� UFRC

� QST, magazine of the ARRL.

11.5.4 Websites

� www.amsat.org [63]

� www.arrl.org [64]

� www.esa.int [70]

� http://f1shs.free.fr/blog/ [71]

76

12 Conclusions

OUFTI-1 will be the �rst nanosatellite from the University of Liège (ULg), and alsothe �rst nanosatellite made in Belgium. The future OUFTI �eet will be controlled viathe recently-developed amateur-radio digital-communication D-STAR protocol. We thuspropose to place in orbit the �rst-ever D-STAR based satellite.

The goal of the present thesis was to get a complete understanding of the D-STARtelecommunication system, which is of primary importance to build our CubeSat D-STARtelecommunication system. Starting from the D-STAR protocol and the schematics ofthe ham-radio equipment, we have developed our personal understanding of the D-STARtransmit and receive communication chains. This was made possible both by experimen-tation and by analysis at the theoretical levels (in particular, by investigating the variousviews in which GMSK can be implemented). A key step in our work was to come upwith the working hypothesis that the phase deviation ∆ωR(t) ought to be a key signalin the equipment we were confronted with. This hypothesis was then con�rmed.

We implemented the D/∆ω converter that consists in the cascade of the D-STARcoder that converts the digital voice and digital data signals into a binary sequence, andthe modulating-phase generator that converts the binary sequence into a phase deviation.We also implemented the ∆ω/D converter that consists in the cascade of the bit decoderthat converts the phase deviation into a binary sequence, and the D-STAR decoder toget the digital voice and digital data signals from the bit sequence obtained by the bitdecoder.

We tested our implementations �rst on synthetic signals, then on real signals, bothnear-ideal. These tests showed our implementations were successfully working on syn-thetic signals and on the direct communication signal. However, we didn't get the rightnumber of bits decoded by the bit decoder for the indirect communication signals, eventhough we were able to identify the radio header and the di�erent synchronization pat-terns. In the future, more robust implementations of our transmit and receive commu-nication chains should be considered.

A ground-based D-STAR repeater connected to a gateway computer was installed,allowing access to the Internet, thereby providing worldwide radio/Internet connec-tivity. The construction of our repeater/gateway system was successfully completed,and contacts with foreign/overseas operators were established. The ULg D-STAR re-peater/gateway (ON0ULG) is the �rst of its type in Benelux. Motivated by this successwe are now ready to move ahead to design and build our D-STAR based CubeSat, basedupon the D/∆ω converter and the ∆ω/D converter. Our CubeSat can be viewed as abare-bone D-STAR repeater in space.

In conclusion, this thesis has allowed me to completely understand the D-STARprotocol. This understanding will be used in subsequent years by other students to buildthe CubeSat communication system.

77

13 Acknowledgments

Throughout the project, we bene�ted from the support of various people, in di�erentdomains. We want to thank them for their support.

These are the radio-amateurs Serge Paeme, ON8PS, and Michel Bovy, ON4YY, whohelped us in several occasions such as mounting the pole for the antennas, and testing ourrepeater. Other ham operators also helped us for the diverse demonstrations of D-STARcommunications during our presentations.

We also want to thank Professor Boigelot, EEI, and Marc Frédéric, EEI, for the in-stallation of the gateway and the idea of using the same processing card as on the robotdeveloped at EEI.

We �nally want to thank Pascal Harmeling for his technical advice for our practicalwork, such as probing and making eye diagrams, and Thierry Legros for loaning usvarious tools.

78

Appendices

A GMSK modulation

We describe our particular view of GMSK modulation and GMSK demodulation we havedeveloped, based upon [1, 3, 8, 13, 28, 29, 32, 46]. Figure 59 show the block diagramsof GMSK modulation and GMSK demodulation. Our development relies heavily on this�gure.

Figure 59: (a) GMSK modulation, and (b) GMSK demodulation.

A.1 RF angular modulator and RF angular demodulator [57]

GMSK is an angular modulation. An angular modulation can be implemented in threepossible ways: by a frequency modulator (FM) (Fig. 60), by a phase modulator (PM)(Fig. 61), or by a quadrature modulator (I,Q) (Fig. 62).

A.1.1 FM modulator

In frequency modulation, the message m(t) modi�es the instantaneous pulsation (andthus frequency) linearly:

ωi(t) = ωc + kωm(t),

where kωm(t) is the instantaneous pulsation deviation ∆ωi(t). The instantaneous phaseis

φi(t) =ˆ t

−∞ωi(τ)dτ = ωct+ kω

ˆ t

−∞m(τ)dτ

79

The signal s(t) is therefore

s(t) = Ac exp(j

[ωct+ kω

ˆ t

−∞m(τ)dτ

])The modulated signal sT (t) is the real part of s(t)

sT (t) = Ac cos(ωct+ kω

ˆ t

−∞m(τ)dτ

)

Figure 60: Frequency modulator.

In our IC-E2820, the RF angular modulator implemented is an FM modulator. Wethus go further with the evaluation of sT (t) for a signal m(t) of the form

m(t) = Am cos (ωmt) .

We know from above the instantaneous pulsation deviation ∆ωi(t) is

∆ωi(t) = m(t) = kωAm cos (ωmt) ,

with kωAm the frequency deviation ∆f .The integral in the modulator is

ˆ t

−∞m(τ)dτ =

ˆ t

−∞Am cos (ωmτ) dτ =

Amωm

sin (ωmt)

The signal s(t) is therefore

s(t) = Ac exp(j

[ωct+ kω

Amωm

sin (ωmt)])

.

We have

∆ω =Amωm

.

We thus haves(t) = Ac exp (j [ωct+ β sin (ωmt)]) ,

where β is the modulation index

β =∆ωωm

Of course, we havesT (t) = Ac cos (ωct+ β sin (ωmt)) .

By using the Jacobi-Anger expansion [22]

exp (jz sin(ψ)) =∞∑

k=−∞Jk(z) exp (jψk) ,

80

we can rewrite s(t) as

s(t) = Ac exp (jωct)∞∑

k=−∞Jk(β) exp (jkωmt) = Ac

∞∑k=−∞

Jk(β) exp (j (ωc + kωm) t) .

Taking the real part of it, we get

sT (t) = Ac

∞∑k=−∞

Jk(β) cos ((ωc + kωm) t) .

We have showed in Section 6.5 we were in the case of narrowband FM (NBFM). Recallthis means β < 1. In case of NBFM with β � 1 (which is not exactly the case for ourIC-E2820 since its β = 0.3125), we can only keep the terms corresponding to k = −1, 0, 1,and use

J0(β) w 1

J1(β) w12β −→ J−1(β) w −1

2β

As a result, we get

s(t) = Ac exp (jωct) +12βAc exp (j (ωc + ωm) t)− 1

2βAc exp (j (ωc − ωm) t) ,

and

sT (t) = Ac cos (jωct) +12βAc cos ((ωc + ωm) t)− 1

2βAc cos ((ωc − ωm) t) .

A.1.2 PM modulator

In phase modulation, the message m(t) modi�es the instantaneous phase linearly,

φi(t) = ωct+ kpm(t)

The signal s(t) is therefore

s(t) = Ac exp (j [ωct+ kpm(t)])

The modulated signal sT (t) is the real part of s(t):

sT (t) = Ac cos (ωct+ kpm(t))

Figure 61: Phase modulator. Subscript �Tx� corresponds to subscript �T� in our equa-tions.

81

The instantaneous pulsation ωi(t) is

ωi(t) =dφi(t)dt

= ωc + kpdm(t)dt

A.1.3 Quadrature modulator

The quadrature modulator performs the following operations. We start with the instan-taneous phase

φi(t) = ωct+ kpm(t)

This phase is passed through a cosine on the upper branch, and through a sine on thelower branch. The results are called the in-phase component iTx(t) and the in-quadraturecomponent qT (t), respectively.

iT (t) = cos (φi(t))

qT (t) = sin (φi(t))

The modulated signal sT (t) is thus

sT (t) = AciT (t) cos (ωct)−AcqT (t) sin (ωct) = Ac cos (φi(t)) cos (ωct)−Ac sin (φi(t)) sin (ωct)

sT (t) = <{Ac exp (j [ωct+ φi(t)])}

Figure 62: Quadrature modulator. Subscript �Tx� corresponds to subscript �T� in ourequations.

A.1.4 From PM to FM and vice-versa

Note FM can be implemented via PM and vice-versa. Figs. 64 and 63 show the situation.

82

Figure 63: FM implemented in PM.

We transform an FM modulator into a PM modulator by adding an integrator stage.Indeed,

sFM (t) = exp(j

[ωct+ kω

ˆ t

−∞m(τ)dτ

]),

while

sPM (t) = Ac exp(j

[ωct+ kp

ˆ t

−∞m(τ)dτ

]).

The modulated signals sFM (t) and sPM (t)are thus equal if Ac = 1, and if kp = kω.

Similarly, we transform a PM modulator into an FM modulator. The equations arethe same, and so are the conditions of equivalence.

Figure 64: PM implemented in FM.

A.1.5 Demodulators

The demodulation can be implemented, here again, by the same three ways as the modu-lation; by an FM demodulator, by a PM demodulator, or by a quadrature demodulator.The operations are the same, but in the reverse order.

A.2 Modulating-phase generator and bit decoder

We know how to go from ∆ωT (t) to sT (t), and from sR(t) to ∆ωR(t) (Section A.1). Wenow discuss how we go from bT [n] to ∆ωT (t) in the modulating-phase generator, andfrom ∆ωR(t) to bR[n] in the bit decoder. Our implementations are described in Chapter8.

A.2.1 Modulating-phase generator

The modulating-phase generator converts the binary input bT [n] into a continuous-timesignal ∆ωT (t). bT [n] is a sequence of bits.

83

NRZ signal

We �rst convert bT [n] into a NRZ sequence iin(t). Then, we pass iin(t) through a bit-to-impulse converter, in which NRZin(t) is the convolution of iin(t) with the rectangularpulse of unit amplitude and duration T, denoted by pT (t) and de�ned as

pT (t) = uT2

(t) = u(t

T).

We introduce a new signal ωr,in(t), since we want to convert NRZin(t) into a phasesignal.

ωr,in(t) = αNRZin(t) (6)

The role of α is speci�ed later. ωr,in(t) is a �raw� pulsation.

Gaussian �lter

To avoid sharp transitions at bit boundaries, we smooth the raw pulsation by �lteringωr,in(t) with a Gaussian �lter with impulse response

gσ(t) =1√2πσ

exp(− t2

2σ2

),

where the parameter σ, which is the standard deviation of the Gaussian �lter, must beproperly selected. The output of the Gaussian �lter is denoted by ωs,in(t). We have

ωs,in(t) = αNRZin(t) ∗ g(t) = αiin(t) ∗ [pT (t) ∗ g(t)] = iin(t) ∗ hT,σ(t),

(where * stands for the convolution product), and where hT,σ(t) is de�ned as

hT,σ(t) , αpT (t) ∗ gσ(t) = αcT,σ(t),

where cT,σ(t) is de�ned as

cT,σ(t) = pT (t) ∗ gσ(t).

Analytical form of cT,σ(t)

We want to know the analytical form of cT,σ(t) in order to have a formula for hT,σ(t).cT,σ(t) is de�ned by pT (t) and by gσ(t). pT (t) is the rectangular square function of lengthT. We can decompose pT (t) into the subtraction of two step functions, one starting at−T/2, and the other starting at T/2. The subtraction of the convolution of each of thetwo step functions with gσ(t) gives cT,σ(t):

cT,σ(t) =ˆ t+T/2

−∞gσ(τ)dτ −

ˆ t−T/2

−∞gσ(τ)dτ.

cT,σ(t) can also be written as

cT,σ(t) =ˆ t+T/2

σ

−∞g1(τ)dτ −

ˆ t−T/2σ

−∞g1(τ)dτ, (7)

84

here g1(t) is de�ned as

g1(t) =1√2π

exp(−1

2t2).

We can express each one of the two integrals in terms of Q-functions. We use the Q-function de�nition of the Communication Blockset of Matlab, since these functions aredi�erently de�ned by di�erent authors.

Q(t) =ˆ ∞t

1√2π

exp(−1

2x2

)dx

We can therefore rewrite Eq. 7 as[1−Q

(t+ T/2

σ

)]−[1−Q

(t− T/2

σ

)]= Q

(t− T/2

σ

)−Q

(t+ T/2

σ

).

Spectrum of Gaussian gσ(t)

We want the continuous-time Fourier transform Gσ(jω) of gσ(t). Since Gσ(jω) is thefrequency response of the Gaussian �lter, we will be able to determine the 3 dB cuto�pulsation ω3dB of the frequency response. It will help us select appropriate values for σ.

Gσ(jω) =ˆ ∞−∞

gσ(t) exp (−jω) dt = exp(−ω

2σ2

2

). (8)

We also have ω3dB de�ned by

Gσ(jω3dB) =1√2. (9)

When equaling Eqs. 8 and 9, we �nd

ω3dB =

√ln 2σ

.

The corresponding cuto� frequency is given by

f3dB =

√ln 2

2πσ.

We will use the following formula in our next development

σ =

√ln 2

2πB, (10)

where B = f3dB is the bandwidth, expressed in Hz.

Choice of parameter σ

The pulse pT (t) is characterized by its duration T, i.e. the bit duration. The Gaussian�lter is characterized by its standard deviation σ, or by its 3 dB cuto� frequency B.The bit length is �xed by the data rate (1/T). The only parameter is thus B, i.e. σ. Itis quite intuitive that the �width� σ of the smoothing Gaussian gσ(t) should be chosenproportional to T,

σ = βT.

85

Note β must not be confused with the modulation index. From Eq. 10, we can write

√ln 2

2πB= βT.

This is equivalent to

β =

√ln 2

2πBT=

√ln 2

2πBn,

where Bn= BT. This shows the key role of the BT product. We can now rewrite everyquantity in term of Bn. This is done in [57].

Truncation of cT,σ(t)

Since the Gaussian gσ(t) takes non-zero values from −∞ to∞, the convolution cT,σ(t) =pT (t) ∗ gσ(t) has in�nite extent. In practice, cT,σ(t) must be truncated. The truncationcan be mathematically represented by a multiplication by a window function of totalwidth W.

cT,σ,W (t) = cT,σ(t) u(t

W

)The length of the window is generally chosen to be some multiple of T, say W = lT,

where the value of l generally depends on σ. Typical values for l are 2 and 3. We thusneed to replace in the previous formulas cT,σ(t) and hT,σ(t) by cT,σ,W (t) and hT,σ,W (t),respectively.

Determination of scaling factor α

We �nally need to determine the scaling factor α introduced in Eq. 6. The requirementin GMSK is that the integration of ωs,in(t) from −W/2to W/2 produces exactly a phaseshift of π/2. This means that

ˆ W/2

−W/2hT,σ,W (t)dt =

π

2,

or, sincehT,σ,W (t) = αcT,σ,W (t),

that

α

ˆ W/2

−W/2cT,σ,W (t)dt =

π

2.

Therefore, the value of the scaling parameter α is given by

α =π

2Ac,W,

where

Ac,W =ˆ W/2

−W/2cT,σ,W (t)dt.

86

If there was no truncation, i.e. if W was equal to ∞, Ac,W would be given by the areaunder cT,σ(t), which is equal to T.In a simulation of the GMSK signal, cT,σ,W (t) will be represented by a �nite-length

vector. The values of Ac,W then becomes the sum of the values of this vector, multipliedby the sampling interval used, i.e. T/M, where M is the number of samples taken in eachinterval T.

A.2.2 Bit decoder

The bit decoder transforms the received signal ∆ωR(t) into a binary sequence bR[n]. Theoperations performed by the bit decoder have been fully described in Section 8.2.1. Thereis no need to re-state them here.

87

B AMBE voice coding and decoding

We present the basic operations performed by the proprietary AMBE voice coder andAMBE voice decoder chip. The basic operation performed by the coder is to convert an8 KHz sampled speech stream to compressed speech data at the desired rate (Fig. 65).The decoder converts the compressed speech data to an 8 KHz speech data. The AMBEvoice coder and the AMBE voice decoder can operate at data rate of 2000 bauds to 9600bauds. The AMBE technology is an improvement of the Improved Multi-Band Excita-tion (IMBE) technology, itself being an improvement of the MBE technology, developedat the MIT in 1980, under the direction of Prof. Jae Lim.

Figure 65: Basic operations (Source: Digital Voice Systems, INC.).

The AMBE technology is a proprietary technology for which the licensing terms arevery restrictive. Digital Voice Systems, INC. does not disclose software licensing terms.This is the reason why we cannot provide full information about the AMBE voice coderand AMBE voice decoder. We refer the interested reader to [2, 23, 31, 11]. Furthermore,this policy is controversial since in the ham-radio community, the technology is free ofaccess.

88

C D-STAR protocol

The D-STAR protocol has been found in [65, 64]. We state the protocol, but the unclearelements we have made clearer through this thesis are written in italics. Recall we areinterested in the DV mode only.

C.1 Technical Requirements for the Wireless System

C.1.1 Voice Communication

1.1.1 General Terms

(1) Communication Method

Half-duplex, digitized voice transmissions.

(2) Communication Contents

Digitized voice/audio signals and short data messages are supported. Voice and audiostreams are transmitted synchronously to support communications quality reproduction.Data and voice/audio transmissions are interleaved.

1.1.2 Transmitting Equipment

(1) Modulation methods

� GMSK

� QPSK

� 4FSK

(2) Data rateMaximum of 4.8 Kbps

(3) Voice encoding method

� AMBE (2020) converting at 2.4 Kbps

� FEC at 3.6 Kbps

(4) Occupied bandwidthMaximum of 6 KHz

1.1.3 Tx / Rx Switching time

Less than 100ms.

89

C.1.2 Data Communication

1.2.1 General Terms

(1) Communication Method

Simplex

(2) Communication ContentsDigital data stream is supported.

1.2.2 Transmitting Equipment

(1) Modulation method

� GMSK

� QPSK

� 4FSK

(2) Data rate

Maximum of 128 Kbps

(3) Occupied bandwidth

Maximum of 150 KHz

1.2.3 Switching time (Tx-Rx)

Less than 50ms.

C.1.3 Backbone communication

1.3.1 General Terms

(1) Transmission Method

Full duplex.

(2) Transmission Contents

Backbone communication between repeaters containing multiplexed digitized voice/audio,user data, and link control data signals.

1.3.2 Transmitting Setup

90

(1) Output power

Complies with FCC regulations.

(2) Modulation method

GMSK

(3) Data rate

Maximum of 10Mbps

(4) Occupied bandwidth

Maximum of 10.5MHz

1.3.3 Multiplexing Method

Figure 66: Multiplexing (Source: [65]).

The multiplexing method for backbone link is an ATM. The details of the speci�ca-tions comply with the ATM protocol. Digitized voice/audio signals should be given thehighest transmission priority. If more data is required, refer to ATM standards.

C.2 System Interconnection Requirements

C.2.1 Wireless Communication Packet

The frame structure of the wireless packet is below.

Figure 67: Frame structure of a data packet (Source: [65]).

2.1.1 Frame structure of a data packet

91

The explanation of the data frame structure the Radio Header follows.

(1) Bit Syn. (Bit synchronization): Repeated standard 64-bit synchronization pattern(for GMSK 1010, for QPSK 1001). Transmission direction is from left to right.

(2) Frame Syn. (Frame synchronization) : 15-bit pattern (111011001010000). Transmis-sion direction is from left to right.

Figure 68: Flag 1 (Source: [65]).

92

(3) Flag 1 (8 bits): Flag 1 uses upper 5 bits and lower 3 bits separately. A detailedexplanation follows.

Figure 69: Flag 2 (Source: [65]).

(4) Flag 2 (8 bits): Flag 2 is for future expandability and is de�ned below.of

a. ID �ag is used as an format descriptor. This is available not only for the increaseand decrease of a �gure of callsign but also for ID, which is not used as callsign ratherthan numeric.b. M �ag is used only a creator or a manufacturer of the equipment.

Figure 70: Flag 3 (Source: [65]).

(5) Flag 3 (8 bits): Flag 3 is used to match control functions to protocol versions, whichmay be upgraded in future software versions.

(6) �Destination repeater Callsign� can have a maximum of 8 ASCII letters and numbers.Blanks should be �lled with a space character. In the case of direct communication, itinserts �DIRECT� and �lls the blanks with a space character. The use of this �eld isdescribed in section 2.2.

(7) �Departure repeater Callsign� can have a maximum of 8 ASCII letters and numbers.Blanks should be �lled with a space character. In the case of direct communication, itinserts �DIRECT� and �lls the blanks with a space character. The use of this �eld isdescribed in section 2.2.

(8) �Companion Callsign� can have a maximum of 8 ASCII letters and numbers. Blanksshould be �lled with a space character. The use of this �eld is described in section 2.2.

(9)�Own Callsign 1� can have a maximum of 8 ASCII letters and numbers. Blanks shouldbe �lled with a space character. This �eld same as voice frames.

93

(10) �Own Callsign 2� is used when to add su�xes to a callsign or a additional destinationaddress information. �Own Callsign 2� can have a maximum of 4 ASCII letters andnumbers. Blanks should be �lled with a space character.

(11) P_FCS is the Radio Header CRC-CCITT checksum, computed by the followingexpression. G(x) = x16 + x12 + x5 + 1

(12) The data frame of the packet is constructed as an Ethernet packet.

(13) FCS is the checksum of the Ethernet data payload. It is a CRC-32 checksum asde�ned in ISO3309 and is computed by the following expression.

G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x+ 1

Figure 71: Frame structure of voice packet (DV mode) (Source: [65]).

2.1.1 Frame structure of voice packet

The explanation of the voice packet including the voice and data frames follows:

(1) The Radio Header has the same frame structure as for the data packet (DD mode).

(2) Data part includes 72-bit (and not 72-bytes) voice signal frames with a length of20 ms in order of their output from the CODEC according to the AMBE (w/FEC)speci�cation. Data frames contain 24-bits (and not 24-bytes) of data.

(3) The �rst data frame and then every 21st data frame in a repeating cycle, are usedonly for synchronizing data for each modulation type. Synchronization corrects for thelag between transmission and reception, including the transit time of communications.This synchronized signal contains a 10-bit synchronized signals and two 7-bit Maximal-length sequences �1101000� patterns. (24 bits total). Transmission direction is from leftto right.

(4) The data in a data frame is transmitted without modi�cation from the input data.If the data is required as error correction or synchronization, these frames are processedbefore processing the data input.

94

(5) If the data signal length is greater than the length of the voice communication thetransmitting switch is turned on until the completion of the data signal manually. Theprocessing can be allowed automatically.

(6) The last data frame, which requires a means of terminating the transmission, is aunique synchronizing signal (32 bit + 15bit �000100110101111� + �0�, making 48 bits)as de�ned by the modulation type. Transmission direction is from left to right.

C.2.2 Communication protocol

Note : In the following descriptions,_ (under-bar) indicates a space character, ASCII$20. If the callsign �eld has blanks between the callsign's last letter and last characterin the �eld, the blanks should be �lled with a space character.

2.2.1 Callsign

The Callsign �eld of the radio header of data and voice packets is used for packet routing.Except for the callsign in the �Own callsign� �elds, callsigns generally have less than 6letters (or 7 letters). The following paragraphs show how to interpret callsign �elds.

(1) �Destination repeater Callsign�

In zone communication, this �eld must be set to the callsign of the repeater utilized bythe companion station. If there are multiple repeaters in a repeater site, they are distin-guished by last character, of �A�, �B�, �C�, or �D�. (Ex. W$1AAA_A , W$1AAA_D,etc.) The default character is �A� (Explained callsign is not to exist as W$1AAA butonly for examples). When communicating outside the local zone, which is called zone tozone communication, this �eld must be set to the callsign of the zone repeater connectedto a gateway and last character set to �G� to indicate communications via the gateway.(Ex. W$1AAA_G)

(2) �Departure repeater Callsign�

� This �eld must be set to the repeater callsign of the originating station.

� If there are multiple repeaters in a repeater site, they are distinguished by lastcharacter of �A�, �B�, �C�, or �D�. (Ex. W$1AAA_A , W$1AAA_D etc.) Thedefault character is �A�.

(3) �Companion Callsign�

� The �eld must be set the callsign of the companion station with which communi-cation is desired. If the station has multiple radios� they are distinguished by lastcharacter of �A�, �B�, �C�, �D�, �E�, or �F�. (Ex. W$1AAA_A , W$1AAA_Fetc.).

� When originating a non-directed call� the �eld should contain �CQCQCQ�.

95

� When calling CQ to a non-local zone, which is called zone to zone communication,prepend �/� to the destination repeater callsign. If there are multiple repeaters ina repeater site, they are distinguished by last character of �A�, �B�, �C�, or �D�.(Ex. W$1AAA_A , W$1AAA_D etc.) The default character is �A�.

� To access a repeater with a local server, in �Companion Callsign�, the �eld shouldcontain the repeater callsign and set last character to �S�. (Ex. W$1BBB_S).

(4) �Own Callsign 1�

� The �Own Callsign� �eld contains the own station's callsign. If the station hasmultiple radios, they are distinguished by last character of �A�, �B�, �C�, �D�, �E�,or �F�. (Ex. W$1AAA_A , W$1AAA_F etc.)

(5) �Own Callsign 2�

This �eld contains information to display as in after a �/ (slash)�. (Ex. W$1AAA_F/ JD1 etc. Note: �/� is not displayed). The purpose of �Own Callsign 2� is to allow�Own Callsign 1� to contain as complete a callsign as possible. �Own Callsign 2� is notevaluated by the system's identi�cation functions.

C.3 Appendix

C.3.1 Scrambler

Scrambling is implemented as follows to eliminate errors when the same bit patterns arereceived continuously.

3.1.1 Scramble codes

Figure 72: Scrambling (Source: [65]).

S(x) = x7 + x4 + 1

Initialization of the shift registers is de�ned to be (1111111). Initialization begins thescrambling process.

3.1.2 Data packet scrambling

96

Figure 73: Data packet (DD mode) scrambling (Source: [65]).

The error correction range is from Flag 1 to P_FCS.

3.1.3 Voice packet scrambling

Figure 74: Voice packet (DV mode) scrambling (Source: [65]).

Voice packet scrambling includes the radio header and data frames except for synchro-nizing frames. Synchronized signals and the last frame are not scrambled.The error correction range is from Flag 1 to P_FCS.

C.3.2 Error Correction

Figure 75: Error correction (Source: [65]).

Error correction for data voice packets is performed as follows. The error correction rangeis from Flag 1 to P_FCS. The error correction signal is interleaved with the packet datawith a convolutional rate of 1/2, a constraint length of 3, and a depth of interleave of 24.

97

Composing process:

(1) X1, X2 registers must be set to zero before encoding.

(2) Feed radio header (not header data) into the encoder beginning with the LSB.

(3) Following the header data, including P_FCS, input two zero bits.

C.3.3 Interleave process

To reduce continuous burst errors during the radio header, the interleaving process spec-i�ed by the following interleave matrix is used. The interleave process operates indepen-dently of the error correction process.

� To interleave transmit error correction, input the packet data stream from left topto the bottom. Read the interleaved data stream from left top to right.

� To separate the error correction data and original data stream, input from thereceived data stream from the left top to right. Read the output data stream fromthe left top to the bottom.

Figure 76: Interleaving (Source: [65]).

C.4 Lexicon

Gate way (GW): Equipment to connect between a zone repeater and the Internet. Usuallyit is normal PC including D-STAR GW softwares.

Zone: A region of connected multi repeaters by backbone repeaters.

98

Zone repeater: Connected a repeater to the Internet in a zone.

Repeater area: A region of available to access a repeater to the terminals.

Figure 77: Figure of system constitution.

Repeater site: A place of setting some repeaters and/or backbone repeaters.

99

D Schematics of ICOM IC-E2820

We have used the schematics of the IC-E2820 to understand which signals we were dealingwith and where to �nd them. We �rst show the block diagram of the CMX589A GMSKmodem [7, 6]. ∆ωR(t) and bR[n] are the signals we are interested in, and correspond tothe RX SIGNAL IN and RX DATA signals, respectively, as shown in Figs. 78 and .

Figure 78: CMX589A high speed GMSK modem. ∆ωR(t) corresponds to the �RX SIG-NAL IN� pin, and bR[n] corresponds to the �RX DATA� pin. (Source: [6]).

100

Figure 79: IC-E2820's UT-123 schematics. In purple, the RX SIGNAL IN pin, corre-sponding to ∆ωR(t). In orange, the RX DATA and RX CLOCK pins, corresponding tobR[n]. In blue, the packet-data output (Source: [27]).

101

E Link budget

To be sure we will be able to communicate with our CubeSat, we must compute the linkbudget [53], both for the uplink and for the downlink. Parameters are given in Table 7,both for the uplink and downlink cases.

Uplink Downlink

Power Pground = 20W = 13.0103dB Psat = 0.5W = −3.0103dBFrequency F = 145.9MHz = 163.2811dB F = 435.5MHz = 172.7798dB

Ground Gain Gground = 13.4dB Gground = 17.5dBLosses Lground = −2dB Lsat = −1.1dB

Thermic noise Ts = 300 = 24.7712dB Ts = 500 = 27.4036dBBandwidth B = 6KHz = 37.7815dB B = 6KHz = 37.7815dBDistance S = 1200 ∗ 1000/cos(5) S = 1200 ∗ 1000/cos(5)

Atmospheric losses La = 0dB La = 0dBCubeSat Gain Gsat = 0dB Gsat = 0dB

Polarization Losses Lpol = −3dB Lpol = −3dB

Table 7: Link budget parameters.

We can now compute, for each case, the link budget, according to the followingformulas. We �rst compute the equivalent isotropic radiated power (EIRP).

EIRP = P + Lground +Gground

Then, we compute the losses.

Ls = 147.55− 20 ∗ log10(S)− f

We eventually compute the signal-to-noise ratio (SNR).

SNR = EIRP + Ls+ La+Gsat + 228.6− Ts−B

It gives us a SNR of 42.1989dB for the uplink, and a SNR of 19.0472dB for thedownlink. Of course, the SNR is lower for the downlink, since we have less power aboardthe CubeSat. We are now sure we will be able to send signals to the CubeSat. This isnot surprising, since already-in orbit CubeSats work with the same range of parameters,including the same power aboard.

Moreover, it gives us the same values as computed by the RadioMobile software de-veloped by Roger Coudé [66], which we show in Fig. 80.

102

Figure 80: Link Budget (source: [66]).

103

References

[1] ANDERSON John B., AULIN Tor, SUNDBERG Carl-Erik, Digital phase modula-tion, Plenum Press, 1986.

[2] BRANDSTEIN Michael Shapiro, A 1.5 Kps multi-band excitation speech coder,MIT, May 1990.

[3] CALDERA, Manora K., Combined coding and modulation in frequency-selectivemobile communications, 2000.

[4] CALDERA Manora K., CHUNG K. S., RAZAVI S.H., Trellis coded CPM usingcoherent detection, .

[5] CALDERA Manora K., CHUNG K. S., Trellis coded GMSK in frequency selectivefading, .

[6] CML MICROCIRCUITS, CMX589A GMSK modem, 2002.

[7] CML SEMICONDUCTOR PRODUCTS, FX589 GMSK Modem application notes,1997.

[8] COUTURIER G., Departement GEII - IUT Bordeaux I, Les modulations π/4-DQPSK, CPFSK, MSK et GMSK, 2000.

[9] DENIS Amandine, Nanosatellite Leodium : contexte, étude de faisabilité et per-spectives, 2007.

[10] DEVOLDERE John, STROBBE Rik, Manuel HAREC de l'UBA, UBA, 2006.

[11] Digital Voice Systems, INC., AMBE-2020 Vocoder Chip User's Manual, version 4.9,2008.

[12] ESA, Education o�ce directorate of legal a�airs and external relations, Vega pro-gramme o�ce directorate of launchers, Educational payload on the Vega maiden�ight call for CubeSat proposals, issue 1, 2008.

[13] FARAG Emad N., ELMASRY Mohamed I., Mixed Signal VLSI Wireless Design -Circuits and Systems, Chapter 4, Digital modulation schemes, Kluwer AcademicPublisher, 2000.

[14] FORD Steve, Amateur radio in space.

[15] FORSYTH David A., PONCE Jean, Computer vision, a modern approach, p. 346,Prentice Hall, 2003.

[16] GALLI Stefania, Mission design for the CubeSat OUFTI-1, 2008.

[17] GALLI Stefania, PISANE Jonathan, D-STAR based student CubeSat of Universityof Liege (Leodium), January 2008.

[18] GALLI Stefania , LEDENT Philippe, PISANE Jonathan, OUFTI-1: new studentnano-satellite at ULg, February 2008.

[19] GALLI Stefania , LEDENT Philippe, PISANE Jonathan, The D-STAR based stu-dent CubeSat of the University of Liege (Leodium project), March 2008.

104

[20] GALLI Stefania, LEDENT Philippe, PISANE Jonathan, DENIS Amandine, VAN-DENRIJT Jean-François, KERSCHEN Gaëtan, ROCHUS Pierre, VERLY Jacques,HALBACH Luc, OUFTI-1: The CubeSat developed at the University of Liège, Bel-gium, 5th Annual CubeSat Developer's Workshop, San Luis Obispo, CA, USA 9-11April 2008.

[21] GALLI Stefania , LEDENT Philippe, PISANE Jonathan, Denis Amandine, VAN-DENRIJT Jean-François, KERSCHEN Gaëtan, ROCHUS Pierre, VERLY Jacques,HALBACH Luc, OUFTI-1, le CubeSat en développement à l'Université de Liège,April 2008.

[22] GRAY, GOODMAN, , p139.

[23] GRIFFIN Daniel W., Multi-band excitation vocoder, MIT, 1987.

[24] HALBACH Luc, Spacecraft systems engineering, telecommunications, April 2008.

[25] ICOM, Cinq exemples d'utilisations avec D-STAR, 2007.

[26] ICOM Inc., Dual band FM transceiver IC-2820H, user manual, 2007.

[27] ICOM Inc., Dual band FM transceiver IC-E2820, service manual, April 2007.

[28] LANGTON Charan, All about modulation, part I, 2005.

[29] LANGTON Charan, All about modulation, part II, 2005.

[30] LANGTON Charan, Coding and decoding with convolutional codes, 1999.

[31] LIM Jae Soo, Enhancement and bandwidth compression of noisy speech by estima-tion of speech and its model parameters, MIT, 1978.

[32] LYONS Richard, Quadrature signals: complex but not complicated, November 2008.

[33] MANOLAKIS Dimitris G., INGLE Vinay K., KOGON Stephen M., Statistical andadaptive signal processing, Artech House, 2005.

[34] MATHAPO Kgabo Frans, A software-de�ned radio implementation of maritimeAIS, 2007.

[35] MINSKY Marvin, A framework for representing knowledge, 1974.

[36] MoeTronix, DV dongle technical reference, version 1.00, 2007.

[37] MoeTronix, DVX VHF digital voice transceiver, version 1.03, April 2007.

[38] MOTAGHI Hamed, Placement at University of Hertfordshire, Hat�eld, United King-dom, Summer 2005.

[39] MUROTA Kazuaki, HIRADE Kenkichi, GMSK Modulation for digital mobile radiotelephony, lEEE Transaction on telecommunications, vol com-29, No. 7, July 1981.

[40] MX-COM, Inc., CMX589A High-speed GSMK modem, 1998.

[41] MX-COM, Inc., Practical GMSK data transmission, 1998.

[42] OPPENHEIM Alan V., SCHAFER Ronald W., BUCK John R., Discrete-time signalprocessing, 2nd edition, Prentice Hall, 1999.

105

[43] OPPENHEIM Alan V., WILLSKY Alan S., HAMID NAWAB S., Signals & systems,2nd edition, Prentice Hall, 1997.

[44] PEARCE Gary, Operating D-STAR, QST, September 2007.

[45] PERROTT Michael, High speed communication circuits and systems, lecture 19,Basics of wireless communication, MIT, 2003.

[46] PERROTT Michael, High speed communication circuits and systems, lecture 21,MSK modulation and clock and data recovery circuits, MIT, 2003.

[47] PIRARD Théo, Etudiants en orbite, l'ambition d'un satellite liégeois, Théo Pirard,Le 15me Jour, February 2008

[48] PIRARD Théo, Oufti, nanosatellite �à la liégeoise�, Athena 240, April 2008.

[49] REF-UNION, Radioamateur. . . pourquoi pas ?,

[50] SARRATT Greg, D-STAR get-on-the-air radio con�guration, 2008.

[51] SCHAFFER Ron, Finesse Gateway & applications, D-STAR '07 Amateur DigitalMode for the 21stCentury, 2007.

[52] SERRET Pascale, OUFTI-1, Le Spoutnik des jeunes Liégeois, Le Jour Huy-Waremme, February 2008.

[53] SILVER J.P., Satellite communication tutorial, RF, RFIC, and microwave theory,design,

[54] SWARTWOUTA Michael, KITTS Christopher, TWIGGS Robert, KENNYThomas, RAY SMITH Billy, LU Rick, STATTENFIELD Kevin, PRANAJAYAFreddy, Mission results for Sapphire, a student-built satellite, Science Direct, 2008.

[55] VAN DROOGENBROECK Marc, Analyse et conception des systèmes de télécom-munications, version 3.69, June 2005.

[56] VAN DROOGENBROECK Marc, Principes des télécommunications analogiques etnumériques, version 5.18, June 2005.

[57] VERLY, Jacques G., Private communication, 2008.

[58] VERLY, Jacques G., Traitement du signal, ULg, 2005.

[59] VERLY Jacques G., Traitement numérique du signal, ULg, 2006.

[60] VERLY Jacques G., Traitement statistique du signal, ULG, 2007.

[61] WAUTERS Laurence, Bientôt un satellite �OUFTI� dans l'espace?, La Meuse,February 2008.

[62] WENSCHEL Lan, CubeSat design speci�cation, California Polytechnic State Uni-versity, 2006.

[63] www.amsat.org

[64] www.arrl.org

106

[65] http://www.arrl.org/FandES/�eld/regulations/techchar/D-STAR.pdf

[66] www.cplus.org/rmw/english1.html

[67] http://cubesat.atl.calpoly.edu/

[68] http://d-star.dyndns.org/node_adapter.html.en

[69] www.d-starusers.org

[70] www.esa.int

[71] http://f1shs.free.fr/blog/

[72] www.genso.org

[73] www.icom.org

[74] www.j�ndu.net

[75] http://www.passion-radio.org/blog/un-decodeur-d-star-avec-une-carte-son-et-un-dv-dongle/602

[76] http://www.rtc.be/content/view/4330/374/

107