Interaktiv 3D-visualisering av NASAs Deep Space Network...

Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings universitet

gnipökrroN 47 106 nedewS ,gnipökrroN 47 106-ES

LIU-ITN-TEK-A-19/005--SE

Interaktiv 3D-visualiseringav NASAs Deep Space Network

kommunikationLovisa Hassler

Agnes Heppich

2019-04-30

LIU-ITN-TEK-A-19/005--SE

Interaktiv 3D-visualiseringav NASAs Deep Space Network

kommunikationExamensarbete utfört i Medieteknik

vid Tekniska högskolan vidLinköpings universitet

Lovisa HasslerAgnes Heppich

Handledare Emil AxelssonExaminator Anders Ynnerman

Norrköping 2019-04-30

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Lovisa Hassler, Agnes Heppich

Linköpings universitet

SE–581 83 Linköping

+46 13 28 10 00 , www.liu.se

Linköping University | Department of Science and Technology

Master’s thesis, 30 ECTS | Medieteknik

202019 | LIU-ITN/LITH-EX-A--2019/001--SE

Interactive 3D Visualization of

the NASA Deep Space Network

activity– Visualizing communication across great distances

Interaktiv 3D visualisering av NASAs Deep Space Network kom-

munikation

Agnes Heppich, Lovisa Hassler

Supervisor : Emil Axelsson, Carter EmmartExaminer : Anders Ynnerman

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-

ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-

pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-

ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan

användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-

heten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som

god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet

ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-

nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida

http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a

period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-

load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial

research and educational purpose. Subsequent transfers of copyright cannot revoke this permission.

All other uses of the document are conditional upon the consent of the copyright owner. The publisher

has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to bementionedwhen his/her work

is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures

for publication and for assurance of document integrity, please refer to its www home page:

http://www.ep.liu.se/.

© Agnes Heppich, Lovisa Hassler

Abstract

This report describe the master thesis project developed by students from Linkoping

University. The project was executed at the American Museum of Natural History and is a

contribution to an open source software called OpenSpace. The report presents the design

and development of an interactive visualization of the NASA Deep Space Network (DSN).

Data from the Jet Propulsion Laboratory (JPL) was used to create a visualization de-

signed to enhance the public understanding of the network as well as highlighting the chal-

lenges of interplanetary communication. The research topics for this work has been how to

visualize communication while considering the temporal aspects in space communication

as well as showing all of the active components of the DSN in a comprehensible manner

for laypeople. The result was an interactive visualization showing all spacecrafts, commu-

nication complexes and radio wave communication that are part of the NASA Deep Space

Network between 2014 and 2019. User tests showed that the visualization was in general

satisfying the main goals of the project. Some future improvements have been identified

and described as well.

Acknowledgments

We would like to express our gratitude to everyone at Linköping University (LiU) and TheAmerican Museum of Natural History (AMNH) who made it possible for us to conduct thiswork. Thanks to our examiner Anders Ynnerman and Carter Emmart who arranged thiscollaboration. Thanks again to Carter for his enthusiastic ideas about visualization and hisgreat knowledge about space as well as his eagerness to share it.

Thanks to Emil Axelsson for being our educational supervisor and supporting us withvaluable guidance throughout our whole project. We are also appreciative of Alexander

Bock for providing fast feedback on Slack and even working after hours in other time zonesto help us out. Also great thanks to Micah Acinapura who introduced us to the project codeand for his great patience whenever we needed his help. Thanks again, to all of you formaking us feel welcome into the OpenSpace team.

We want to show our gratitude to Kevin Hussey at Jet Propulsion Laboratory who con-nected us to people with expertise about DSN. Special thanks to Shan Malhotra for hiswillingness to generate custom file formats with the necessary data for this project. Thiswork could not have been possible without your help. We also want to extend our appre-ciation to everybody at AMNH who made our stay an unforgettable experience. Thanks toVivian Trakinski and Ro Kinzler who showed interest in our work and invited us to afterwork events. Also thanks to Camera Walrond-Joshua, Barbara Green and Eric Hamilton atAMNH who helped us with administrative tasks.

Agnes Karlsson-Heppich and Lovisa Hassler, March 2019

iv

Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables ix

1 Introduction 1

1.1 The Deep Space Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 OpenSpace software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivation and Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 4

2.1 Three-dimensional analysis of deep space network antenna coverage . . . . . . 42.2 Deep Space Network Now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Theory 6

3.1 Technical details of the Deep Space Network and Communication . . . . . . . . 63.2 Precision issues while navigating in OpenSpace . . . . . . . . . . . . . . . . . . 93.3 Date reference frames and celestial coordinate systems . . . . . . . . . . . . . . 103.4 JPL data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5 DSN Now XML data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Visual representation 13

4.1 Spacecraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Ground stations and their coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Radio wave communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Implementation 17

5.1 Preprocessing of raw data and Data formats . . . . . . . . . . . . . . . . . . . . . 175.2 Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3 Spacecraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.4 Radio wave communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.5 Station field of view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Results 26

6.1 Visualization of the DSN stations . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 Visualization of the spacecraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.3 Visualization of the radio wave communication . . . . . . . . . . . . . . . . . . 28

v

6.4 Ground station field of view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 User test 31

7.1 Design and purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.2 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

8 Discussion and analysis 33

8.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.3 Future improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9 Conclusion 37

Bibliography 39

vi

List of Figures

2.1 Main page of DSN Now observed at 2019-02-20.The center and left shows thecommunication complex sites and their individual stations. Above each stationthere are names of spacecraft that are in current communication. Animated radiowaves indicate activity and goes in different directions. To the right more detailedinformation can be found about the spacecraft and the transmission. . . . . . . . . 5

3.1 Illustration of the coverage of the communication complexes.The dotted line rep-resents 30 000 kilometers from Earth. Outside of that radius the DSN stationscoverage overlap, and there are nearly no blind spots left. . . . . . . . . . . . . . . 7

3.2 Overview of the DSN spacecraft communication. The figure represents the flow ofthe data between the Flight Systems, the DSN and the Mission Operations Systems. 9

3.3 The celestial equator and the vernal equinox is used to express Right Ascensionand Declination. The gray circle represents Earth. Right Ascension and Declina-tion is represented by the colored fields marked in the picture. . . . . . . . . . . . . 10

4.1 Point to point communication visualization. P1 and P2 represent the dish locationand the spacecraft location. The line represents the transmission between the two. 15

4.2 Li’s represents lines where L1 is the first one occurring followed by new lines astime progress, from left to right. The black dots represent positions of two movingobjects (station and spacecraft) at the current time, while the grey represent themat previous and future points in time. . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3 Concept of the visualization of a signal travelling through space from a dish to-wards a spacecraft or from a spacecraft towards a dish. P1 and P2 represent thestart and end point of the transmission and the orange rectangles represent thesignal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Sample of the positioning data. From top to bottom the values represent times-tamp, right ascension measured in degrees, declination measured in degrees,range measured in kilometers and light travel time measured in seconds. . . . . . 18

5.2 Preprocessing work flow chart. The numbers represent different scripts used onthe different sets of data. The same sorting script, (1), was used to sort the rawCSV data both with hourly and minute precision. Script (2) combined the hourlyand minute position data which was used in OpenSpace. Script (3) converted theraw CSV schedule to suitable JSON format. Script (4) added the light travel timefrom the positioning data into the transmission data which was used to visualizethe signals in OpenSpace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.3 Sample of the processed signal data. From top to bottom the values represent endtime for the transmission, dish name, start time for the transmission, spacecraftname, direction of the transmission, and light travel time measured in seconds. . . 20

5.4 A label rendered with precision uncertainty. The crooked look of the text is due tothe precision uncertainty caused by the vast distance between the camera and thelabel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vii

5.5 A scene graph node position is projected onto a view frustum plane at a staticdistance from the camera to determine the label position. The label size is scaleddepending on the distance from the object. . . . . . . . . . . . . . . . . . . . . . . . 23

5.6 Signal line concept where a signal travels from position P1 to position P2 withvelocity Vt. The flow speed effect of the signal segments have velocity Vs. . . . . . 24

5.7 Station field of view is represented by the cone in this figure. The tip of the cone iswhere the station is located. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1 Four dishes from the Goldstone ground station. Two 34 meter dishes are transmit-ting signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2 Close up of the Voyager spacecraft showing the 3D model from NASA. The redline indicates current incoming or outgoing signal communication from Canberra. 27

6.3 Spacecraft labels near Earth that fade in and out upon navigating towards andaway from them. The dot in the lower left corner of each label indicates the space-craft position. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.4 The labels for the spacecraft near Mars merged into two clusters i.e. "InSight,MarCOA & MarCOB" and "MarsOdyssey, MRO ..." which reduces the clutteringon screen when many spacecraft are visible at the same time. . . . . . . . . . . . . 28

6.5 Signals going from and towards all three ground stations, colored according tolocation. The pale orange clustered labels helps the readability around Mars. Thegrey labels represent individual spacecraft. . . . . . . . . . . . . . . . . . . . . . . . 29

6.6 Station field of views colored according to ground station with Goldstone as blue,Madrid as green and Canberra as red. They illustrate the potential range of eachground station location on Earth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.7 Wire frame representation of the station field of views colored according to groundstation with Goldstone as blue, Madrid as green and Canberra as red. They illus-trate the potential range of each ground station location on Earth. . . . . . . . . . . 30

viii

List of Tables

3.1 Positioning data table. The first two rows indicate how often there are data sam-ples and for what spacecraft. The rows following are the parameters in every sam-ple. "Upleg" means from station to spacecraft and "downleg" is from spacecraft tostation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Transmission data table. The DSN Now XML data are snapshots that can be col-lected approximately every five seconds from DSN Now. Thus they do not havea set start and end time for the transmission by default, which the JPL scheduledata has. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ix

1 Introduction

This chapter describes some topics to give an initial understanding of the scope of this work.The OpenSpace software is the environment where the Deep Space Network visualizationhas been incorporated. An introduction is also given to what the Deep Space Network is. Anoverall motivation with the aim to educate has been the driving force for this project. Thechallenges as well as target groups for the visualization are described further in this chapter.Four different research questions was created to give structure in the pursuit of reaching thesegoals. This chapter also mentions some delimitations taken to narrow down the main focusof the work.

1.1 The Deep Space Network

Space missions have since their infancy been of great interest to the public, with the scien-tific successes made during The Space Race during the Cold War being a major contributor.Newly acquired knowledge about the universe and about new missions are written aboutfrequently but the general public is usually not familiar with the system that supports thesemissions and makes their data aggregation possible. Although the NASA Deep Space Net-work (DSN) has an essential role for all other space science, most people have never heardof it. The DSN is a US federally funded worldwide network of spacecraft communication.It is operated by Jet Propulsion Laboratory (JPL) and has been in use since 1958 [15]. Sincethen it has been extended, improved and updated as new technology has been developed.Today the network facilities are located near Goldstone (USA), Madrid (Spain) and Canberra(Australia). Each communication complex, also referred to as ground station, has a numberof parabolic dish antennas, also called stations, that together support communication withover 50 spacecraft missions today. Throughout this report the terms "dish" and "station" areused when referring to the individual communication points on Earth, while "ground sta-tion" refers to a communication complex that is either in Canberra, Goldstone or Madrid.The DSN is developed for transmissions with spacecraft far out in our solar system whichrequire extra specialized equipment and technology. Although there is more than one DeepSpace Network, such as the Chinese Deep Space Network and Indian Deep Space Network, itshould be noted that all mentions of Deep Space Network with the abbreviation DSN withinthis report refer to the NASA Deep Space Network.

1

1.2. OpenSpace software

1.2 OpenSpace software

OpenSpace is an open source space data visualization software. It is an interactive 3D rep-resentation of the known universe as well as a cooperative effort by Linköping University(LiU), American Museum of Natural History (AMNH), the Scientific Computing and Imag-ing Institute at the University of Utah, and New York University. With a foundation of datafrom NASA, the software uses advanced computer graphics to e.g render scientific represen-tations of celestial bodies in the solar system with high resolution image data sets, volumetricspace weather phenomena and space missions [6]. The software has the ability to run onmultiple types of platforms such as desktops, dome theatres and touch displays. The factthat it is free to use and develop as open source further makes it more accessible than othersimilar softwares that are commercial [7]. OpenSpace is used at The American Museum ofNatural history in New York that is the home of Hayden Planetarium, one of the world’s mostrenowned planetariums, which brings knowledge of space directly to an international audi-ence. OpenSpace aims to continue to visualize the ongoing efforts of exploring the universeand bring the visualizations to scientists and laymen alike.

1.3 Motivation and Aim

The overall motive for this project was to create a 3D visualization that displays the extensivework that DSN performs daily based on data from NASA. The challenge to create a repre-sentation of DSN that is intuitively understood in a 3D environment is something that hasnot previously been done. To show the complexity of the DSN in a comprehensible way for alayperson who may not have previous knowledge of the topic is also part of the motivation.This also fits into the greater goal of OpenSpace as a way of showing NASA’s work to thegeneral public.

The main target group for this project are educators such as teachers or museum staff whowants to educate an audience using the OpenSpace software. This means the visualizationshould be easy to navigate, understand and explore for a user who is familiar to OpenSpaceor similar software such as Uniview, but may not have much previous knowledge about theDSN. Also the visualization on its own should be intuitive enough to help an audience geta better understanding of communication in space and draw their own conclusions from thedata visualized.

1.4 Research questions

To satisfy the overall aim the following research questions were formed that each targetedsome especially challenging topics to consider within the scope of this project.

1. How do we show the extent of the network so that someone who is not familiar withthe system could understand it?

2. How do we visualize radio wave communication across widely varying distances whencelestial bodies and spacecraft are constantly changing positions in space?

3. How do we visualize the vast transmission coverage of the deep space network in away that shows the timing of the transmission schedule?

4. How do we visualize to a layperson how vast space is and how relatively slow inter-planetary communication is?

2

1.5. Delimitations

1.5 Delimitations

Since the research questions have been the main goal of the project, some other things havenot been a priority due to lack of time. The optimization and improvement of data han-dling have not been covered within the scope of this project. Some basic optimization such asbinary searches when reading from disk were implemented to make the application run at ac-ceptable speed, but no database or other service have been developed to drastically improvethe data pipeline.

3

2 Related Work

To visualize different phenomena in space is what OpenSpace has been developed for. Sinceit is a scaled down version of the universe it offers unique opportunities for 3D visualization.Though a lot of effort has been put into scientific visualizations to better understand space,the task of displaying the communication activity of the DSN in 3D has barely been explored.The article Three-dimensional analysis of deep space network antenna coverage by Kegege et al. waspresented in 2012. It focused on the so called coverage gap of the DSN which was visualizedin both 2D and 3D[11]. Another effort to portray the work that the DSN performs is DeepSpace Network Now (DSN Now) which focuses on live streaming data from the stations. Thisis presented as a 2D web page.

2.1 Three-dimensional analysis of deep space network antenna coverage

The work "Three-dimensional analysis of deep space network antenna coverage" was con-ducted by people at NASA Glenn Research Center and the Space Communications and Nav-igation (SCaN) team. It was made with the purpose of exploring the coverage gap and whatto consider regarding it for future missions. For more info about the DSN coverage, readsection 3.1.1.

This communication coverage gap was analyzed using NASA’s Integrated SCaN (SpaceCommunication and Navigation) Simulator. To develop the physical attributes and con-straints of the DSN architecture within the simulation the SCaN model library was used.Models of DSN antennas were included in the analysis as well as receiver models at variousdeep space altitudes. The simulations incorporated antenna parameters and uplink calcu-lations. Since the focus on their work was to explore the coverage gap they used the az-imuth/elevation terrain masks around the stations. This was important to get details aboutsignal obstruction from the surrounding area for each antenna which potentially constrainthe line of sight to spacecraft. Also, the SCaN model library and Satellite Tool Kit (STK) wereused to develop the simulations.

Since no current missions fall within the coverage gap most data was simulated and thecase of uplink communication, called forward link in the report, was studied. However,to give an accurate representation of the gap a lot of parameters for the stations such asfrequency bands, polarization and transmitting power were taken into consideration to givedetailed simulated data [11]. The results included multiple visual representations as well

4

2.2. Deep Space Network Now

as calculations and diagrams showing how the altitude from Earth affected the size of thecoverage gap.

2.2 Deep Space Network Now

DSN Now is a public outreach project that aims to give more information about what workthe DSN is currently performing. It is developed and maintained by people at Jet PropulsionLaboratory (JPL). DSN Now is a web page that presents live stream data every five secondsdirectly from DSN, which is described on the information on the website [13]. Some anima-tions have been added to indicate current transmission as can be seen at dish number 54 infigure 2.1. The right hand panel shows the currently chosen dish and its transmission. Itcontains detailed numerical information about the current signal such as data rate, frequencyand power, see section 3.1.3. Other numbers are also provided for the spacecraft such asrange and round trip light time as well as azimuth (more information in section 3.3.2 ). andelevation of the dish, see section 3.3.2 for more information. JPL has generated their own dataformat that this web site is using. This data is described further in section 3.5.

Figure 2.1: Main page of DSN Now observed at 2019-02-20.The center and left shows the com-munication complex sites and their individual stations. Above each station there are namesof spacecraft that are in current communication. Animated radio waves indicate activity andgoes in different directions. To the right more detailed information can be found about thespacecraft and the transmission.

5

3 Theory

The challenge of visualizing the DSN requires some understanding of the different compo-nents of the network. In this chapter the different types of stations and their capabilities aredescribed in greater detail. It also contains information about the spacecraft and the com-munication between them and the stations. To be able to follow the placement of these DSNcomponents into OpenSpace the theory of celestial coordinate systems as well as OpenSpacespecific precision issues have been included. Furthermore the types of data available arepresented.

3.1 Technical details of the Deep Space Network and Communication

The DSN is a meticulously engineered system that deals with transmission over long dis-tances in an environment where celestial bodies are always in motion. Apart from havingadvanced instruments, the stations also have to be strategically placed to have as wide cov-erage as possible to be able to communicate with spacecraft no matter where in space theyare located. Since there are limitations to how many spacecraft a station can communicatewith at a time, the communication requires carefully scheduled transmissions on Earth. Thespacecraft are used for various scientific missions. They receive instructions from the groundstations as well as sending back telemetry and scientific data. To be able to perform theseoperations they are equipped with radio wave transmitters and receivers [15]. The uniqueenvironment that communication in space encompasses adds extra difficulties that in turndemands certain instruments and technologies described in this chapter.

3.1.1 Stations

The DSN Network communication complexes are located approximately 120 degrees aparton Earth, see Figure 3.1. This is essential to be able to provide a nearly continuous line ofcommunication of a spacecraft no matter its position in space. As described by Kegege et al.there is a small coverage gap in the Southern hemisphere, however no current missions fallwithin this gap [11]. Since all planets are near the ecliptic plane which does not fall withinthe coverage gap this has not posed a communication problem for any current or plannedmissions so far. The communication complexes are each a cluster of stations. Observed from

6

3.1. Technical details of the Deep Space Network and Communication

space as Earth rotates, a currently visible cluster of stations will eventually fall out of viewaround the same time as the next becomes visible at the opposite side of Earth.

Figure 3.1: Illustration of the coverage of the communication complexes.The dotted line rep-resents 30 000 kilometers from Earth. Outside of that radius the DSN stations coverage over-lap, and there are nearly no blind spots left.

The DSN station antennas have different sizes and are designed to solve different prob-lems. There are 70 meter dish antennas and 34 meter dish antennas that are currently used.Smaller dishes at sizes 26 meters and 9 meters are used for Earth orbiting missions but theseare not included as part of the DSN. The height of each DSN station is that it is almost ashigh as its dish diameter [9]. The 34 meter dishes replaced the previous 26 meter antennasand the 70 meter in diameter dish replaced the earlier 60 meter dishes [14]. There are twodifferent types of 34 meter dish antennas and those are High Efficiency (HEF) and BeamWave Guide (BWG) antennas. Each communication complex has one 70 meter station andmultiple 34 meter stations [16]. The same station antennas are used for both uplink data com-mands (transmission from station to spacecraft) and receiving downlink data (transmissionfrom spacecraft to station). More about this can be read in section 3.1.3.

There is a large demand on the DSN stations. Since the stations are restricted in the num-ber of spacecraft they can communicate with at the same time some priorities have to bemade. The large 70 meter dishes have larger beamwidths, i.e. a larger angle in the radio an-tenna pattern of the peak radiating power of the main lobe, than their smaller counterparts.They also have the capability to pick up weaker signals. That makes them able to pinpointand improve signal communication to very far away spacecraft. However the smaller 34meter dishes can work synchronously with each other to mimic the functionality of a largerantenna. They can also work together with a 70 meter antenna to extend the functionality ofboth of them. This functionality is called arraying [16] and it is not a standard service, but acapability of DSN that has proven very useful. Another capability of the DSN is called Mul-tiple Spacecraft Per Aperture (MSPA) which allows multiple spacecraft to transmit downlinkdata to the same station, providing that they are both within the reach of the beamwidth ofstation. This capability is especially useful when there are scheduling conflicts. At popularresearch locations such as Mars it is not unusual that multiple spacecraft are within the samestation beamwidth. For this particular functionality it requires the DSN station to have mul-tiple receivers, usually two (2-MSPA), although an extension of up to four (4-MSPA) is being

7

3.1. Technical details of the Deep Space Network and Communication

developed. For MSPA to work all spacecraft have to transmit on different frequencies that areconsistent with the station capabilities. Currently only one uplink signal can be transmittedat a time, but sometimes the scheduled time will be split among multiple spacecraft to allowsequential uplink communication [16].

3.1.2 Spacecraft

"Spacecraft" in this work refers to all spacecraft using the DSN for support. This includesmany different types of machines, for example space probes, orbiting satellites, landers andmore. Today, there are too many active spacecraft to support transmission from all of themat the same time with the current DSN. While most spacecrafts are on specialized missionsto collect different scientific data this is not the only type of data that is transmitted. Forexample certain missions also work together with others as relay support. That means onespacecraft communicates with another spacecraft that in turn transmits to a DSN station. Thisis common with landers, such as Mars Science Laboratory, that are transmitting to orbiters,such as Mars Reconnaissance Orbiter. This means it is possible to reach a lander on a planeteven when there is no direct line of contact to Earth due to the other planet’s rotation [17].This also means that the direct communication with Earth is not evenly distributed across allspacecraft, but instead a schedule is made based on the current relevance and interest of amission as well as its capability of being in line of contact.

The role of the DSN as an international cooperation also means that it schedules commu-nication with missions developed by other space agencies. Hayabusa 2 by the Japanese spaceagency (JAXA) and Mars Orbiter Mission by Indian Space Research Organization (ISRO) areexamples of such missions.

The range of missions are constantly changing as new missions are planned and launchedand older ones are decommissioned or lost. Further information about how many spacecraftare operating can be found in section 6.2.

The most distant spacecraft that are part of the Deep Space Network are Voyager 1 and 2that were launched in 1977. They are nearly 20 light hours away and are outbound from oursolar system. Some spacecrafts communicating through the DSN are still in their planningphase and therefore have not yet left earth. To test the instruments there are communicationsscheduled to spacecraft even pre-launch. Whilst no actual transmissions are taking place,certain compatibility tests and other tests are made in order to make sure all equipment isworking as expected before launch.

Apart from mission specific instruments the spacecraft are all equipped with radio trans-mitters and receivers to communicate with DSN stations.

3.1.3 Communication between stations and spacecraft

The communication between spacecraft and DSN can be divided into uplink and downlink,see Figure 3.2. Uplink is a signal sent from a station out to a spacecraft, downlink is a signalsent from the spacecraft down to a station. Both types of communication are transmitted asradio waves that travel at the speed of light. The radio waves have different frequencies tonot interfere with other communication and minimize noise. Uplink communication consistsof commands, spacecraft software loads, sequence loads and more as decribed by Tai et. al[16]. Downlink communication consists of telemetry data, tracking data and science datathat could be radio science, Very-long-baseline interferometry (VLBI), Radio Astronomy andmore. One example of science data is the filtered out noise in the downlink data caused byradioactivity in space. This means the downlink acquires information about radio active phe-nomena on its way down to Earth. However this also means that many outer disturbancescan corrupt the data on its way. To handle that issue NASA has developed encoding anddecoding algorithms to restore corrupt data that would otherwise be lost. Often the com-

8

3.2. Precision issues while navigating in OpenSpace

munication is two-way since the transmitters and receivers operate independently of eachother.

Radio waves are hard to receive across great distances because as they propagate the sig-nal power becomes weaker. NASA and JPL have made large improvements with the tech-nology of the DSN stations for them to be able to pick up on extremely weak signals. NASAalso use amplifiers both on the receiving and transmitting end. Through exact tracking andcalculations NASA can pinpoint the transmissions for the signal power to be as concentratedas possible [14].

To communicate in these extreme circumstances requires, as previously mentioned, veryexact navigation. This is also a challenge in OpenSpace where positioning should be as accu-rate as possible.

Figure 3.2: Overview of the DSN spacecraft communication. The figure represents the flowof the data between the Flight Systems, the DSN and the Mission Operations Systems.

3.2 Precision issues while navigating in OpenSpace

OpenSpace strives to provide a seamless interactive navigation across the whole known uni-verse as described in section 1.2. The navigation focus in OpenSpace can be set by pickinga focus node that the rendering camera will have at the center of its view. Using the zoomfunction in that mode will make the user navigate towards the scene graph node and is acommon way to navigate within the OpenSpace environment. As of the time of this project,the OpenSpace coordinate system has the sun as origin and uses meters as units along theaxis. Dealing with scaling in such a large environment leads to certain problems that do notusually occur in smaller coordinate systems. One common issue is that floating point preci-sion is not enough to express the world position of the scene graph nodes in OpenSpace withaccuracy. While double precision values may help solve some problems arising, it leads toworse performance. The phenomena is described further by Axelsson et al. [4] who state thattranslation causes the most serious problem known as catastrophic cancellation, while scalingand rotation do not pose those issues. These defects are more noticeable the closer the cam-era is to a scene graph node that is placed far from the world origin, and Axelsson et al.also describes why the sensitivity of a visible vertex displacement is inversely proportionalto the distance of the vertex in view space. This makes precision issue handling a continuouschallenge while developing the OpenSpace software. In particular this has to be taken intoconsideration when positioning nodes in OpenSpace.

9

3.3. Date reference frames and celestial coordinate systems

3.3 Date reference frames and celestial coordinate systems

One of the biggest challenges to positioning in space is the fact that everything in the universeis constantly moving. To describe a position, a fixed point of reference is needed. There aredifferent ways of setting reference points in space. It is common that celestial coordinate sys-tems are defined relative to the vernal equinox, see figure 3.3. However, the vernal equinoxis in itself not constant and because of that, the vernal equinox of a certain date is used asa reference. Today it is common to use J2000, which refers to January first, the year 2000 at12AM UTC. Reference systems from 1950 and 1900 were the most commonly used prior[2].

There are many different celestial coordinate systems used to describe position in space.Some coordinate systems are expressed in spherical coordinates and some in rectangular co-ordinates. For spherical coordinates there are different systems that define the fundamentalplane from which the angles are measured. The equatorial system uses Earth as center andhas its fundamental plane defined as the infinite projection of Earth’s equator. The eclipticsystem has the ecliptic plane (Earth’s orbit) as its fundamental plane and galactic uses theapproximate plane of the galaxy as reference with the solar system as origin. Figure 3.3 givesa further explanation as to how the celestial coordinates work. Below is information abouttwo of the most commonly used celestial coordinate systems [10].

Figure 3.3: The celestial equator and the vernal equinox is used to express Right Ascensionand Declination. The gray circle represents Earth. Right Ascension and Declination is repre-sented by the colored fields marked in the picture.

3.3.1 Equatorial coordinates (Right Ascension and Declination)

Right ascension and declination are used to map outer space much like latitude and longi-tude are used to map Earth. Instead of Earth, right ascension and declination are based onthe celestial sphere, also called equatorial sphere since it uses the fundamental plane of theequatorial system. The celestial sphere is an imaginary sphere with infinite radius and Earthcenter as its center. The celestial equator is aligned to Earth’s equator and used as a referencepoint for measuring declination. Declination is used to describe the elevation above the celes-tial equator and is measured in degrees. The reference point for right ascension is the VernalEquinox and is dependant on time frame. The right ascension is usually measured in hours,minutes and seconds [10].

10

3.4. JPL data

3.3.2 Horizontal coordinates (Azimuth and Elevation)

Much like right ascension and declination, Azimuth and Elevation are used to position celes-tial bodies and spacecraft. Instead of using Earth center as the origin, azimuth and elevationare measured from the current position of the viewer and are both angles. This means thatthe Horizontal coordinate system is fixed to the viewers position and not the stars. There-fore the coordinates of a celestial body varies depending on where the viewer is located. Thecoordinates of a celestial body also vary with time, since Earth is constantly rotating.

Azimuth angle is used to describe the direction of the celestial body on a plane perpen-dicular to the viewers horizon. Usually true north is used as a zero point. Elevation angle isused to describe the altitude of the celestial body with the observer’s horizon as a referencepoint [10].

3.4 JPL data

There are several types of data available from JPL. Some data sets are publicly available andsome data sets have been generated specifically for this project with the help of staff from JPL.The publicly available data used in this project is the SPICE (Spacecraft Planet Instrument C-matrix Events) data, explained in further detail later in this section, for positioning somespacecrafts and latitude and longitude data for positioning the stations. The data generatedspecifically for this project is the CSV positioning data and the scheduled files describing theDSN communication.

SPICE data, is provided by the NASA ancillary Information Facility (NAIF), and is pub-licly available for anyone to use for free. SPICE data is collected from spacecraft, missioncontrol center, spacecraft instrument builders and scientists. The data describes trajectories,location, orientation and more both for various spacecraft and known celestial bodies. SPICEdata is often referred to as SPICE kernels. The Kernels describing the position of these space-craft and celestial bodies are called SPK (Spacecraft and Planet Kernel) files [1]. Data express-ing the positions of the different dishes on Earth is also publicly available from JPL in theform of latitude and longitude [9].

There are also 3D models of some of the different spacecraft, planets, instruments publiclyavailable from NASA.

Data describing the positions of the spacecraft have been specifically generated for thisproject in CSV format. The data contains the information shown in table 3.1. This CSV datacomes in two data sets. One set that is sampled every minute within the transmission win-dows. Another that is sampled every hour for the 5 year period that was the decided time-frame for this project.

The upleg data describes the location of the spacecraft when the signals left the groundstations and the downleg data describes the position of the spacecraft at the time the signalsleft the spacecraft, relative to Earth at the specific time. The data is separated per spacecraftand has information from January 2014 to January 2019. The data is sampled every minuteduring the windows of transmission, i.e when there are transmissions, and every hour con-tinuously for the rest of the time frame.

Another type of data specifically generated for this project is the schedule files of NASA’scommunication. It shows when all spacecraft are scheduled to transmit, to which station andfor how long. There is also information about what type of transmission is scheduled. Theavailable data has information about January 2014 to January 2019. The data is separatedinto weeks and not split up per spacecraft. There is no parameter describing if the signal is anuplink or a downlink, i.e if the signal is going towards the spacecraft or towards the station onEarth, as described in section 3.1.3. However, a list of instrument used for the communicationhas been included. Depending on which instruments has been used for the transmission, it ispossible to determine if the signal is an uplink or a downlink as the instruments used for anuplink is not the same as used for a downlink. The schedule also contains transmissions with

11

3.5. DSN Now XML data

Data type DSN Now XML data JPL CSV position data

Position for all spacecraft - 1/hourPosition for transmitting spacecraft 1/5sec 1/minute

Light travel time roundtrip upleg, downleg and roundtripAzimuth/Elevation yes, up- and downleg unspecified upleg and downleg

Ra/Dec - upleg and downlegDoppler - one-way and two-way

Table 3.1: Positioning data table. The first two rows indicate how often there are data samplesand for what spacecraft. The rows following are the parameters in every sample. "Upleg"means from station to spacecraft and "downleg" is from spacecraft to station.

Data type DSN Now XML data JPL schedule data

Start and end time - yesFrequency, power and data rate yes -

Light travel time yes -MSPA yes -Array yes -

Is Downlink/Uplink yes yes

Table 3.2: Transmission data table. The DSN Now XML data are snapshots that can be col-lected approximately every five seconds from DSN Now. Thus they do not have a set startand end time for the transmission by default, which the JPL schedule data has.

different work categories (workcat). Workcat identifies the type of track it is. According toJPL staff, one would typically want 1A1 for visualizing the actual activity since this indicatesan operational track. Other codes are tests, training sessions or some other science relatedactivities.

3.5 DSN Now XML data

The data used by the DSN Now web page is in an XML format. It has information bothabout the positioning of the spacecraft and about the transmissions, see tables 3.1 and 3.2.Further, it has information about how much data is transmitted, at what frequency, powerand more. The data does not contain information about right ascension and declination forthe spacecraft. However, it does contain information about range as well as the azimuthand elevation angles, described in section 3.3.2, of the dish when it receives or transmits.This means a position could be derived, however it would not be the current position of thespacecraft but rather an estimation of where it was when it sent the downlink or where it isgoing to be when it receives an uplink. Depending on the velocity of the spacecraft and itsdistance from Earth this positional difference can be quite large.

Unlike the data generated by JPL, the DSN Now data only contain information about thespacecraft that are actually in communication at a given time, sampled every five second.The structure of this data means that there is no way of knowing for how long a spacecraft isgoing to be in communication, only if it is connected or not at the given time for the data.

12

4 Visual representation

The available data described in section 3.4 and section 3.5 contain different types of data.Ideally both data sets could be used to visualize the DSN communication since they containdifferent types of data. In this chapter the different ways of representing the visual compo-nents of the system are described. The options were considered with the aim of answeringthe research questions in section 1.4. The considered alternatives of visualizing spacecrafthave put extra demands on the data used to position them. While labels are deemed usefulfor spacecraft, they are less useful for the stations where representative colors have played alarge role which also connects to representing their coverage. To properly visualize the radiowave communication multiple different options for line rendering were considered.

4.1 Spacecraft

The role of the spacecraft in this visualization have three purposes. One is to offer a 3Dposition to be an end point of the communication lines, another to be a visible node one cannavigate to in OpenSpace, and third to show the connections of the work the DSN performswith an overview representation.

The visual representation as an end point of communication is described in the section4.3. To visually represent the node one can use a 3D model which is a common way ofrepresentation in OpenSpace. The overview representation is a bit more difficult. Since it isnot intuitive which spacecraft are part of DSN there is need to show this. OpenSpace has aGUI that can list scene graph nodes. To keep the universal view clean one method could beto only show the fleet as a whole in the GUI and use the navigation within OpenSpace to geta closer look on the scene graph node. However this would make it difficult to determinewhere the communication is travelling to and from. Thus labels were considered since theyhave been used before in OpenSpace, for example when visualizing stars. This meant thatspacecraft could be visible even from very far distances since a label does not have to followworld proportions the same way a 3D model would.

However, with the spacecraft always visible there were potential issues with the differ-ent data sets used for positioning. The XML data only contained the spacecraft positioningduring the transmission windows, described in chapter 3. This meant that certain space-craft would not get their position updated for long periods of time because they do not haveevenly distributed transmission times. This could lead to misleading visual impressions. An

13

4.2. Ground stations and their coverage

option would be to only show the spacecraft that are in current communication. However,this would conflict with the goal of showing the extensiveness of the network. To be able toshow this accurately, there was a need to get updated positioning even outside of the trans-mission windows, which was possible through the CSV positioning data from JPL. While thegoal of showing all spacecraft at all times was an ambition, this meant a method of handlinglabel cluttering would also be necessary later in the process.

4.2 Ground stations and their coverage

The ground stations of the DSN had several options of representation. With exact positioningone should be able to see the huge dishes from the detailed Earth texture that was alreadyimplemented with the globe browsing feature by Bladin et. al [5]. However there are 3Dmodels of the different NASA dishes available online. Because of the nature of OpenSpace asa scaled down version of the universe there was an idea that the visual representation of thenodes would also have a 3D model. Ideally these models would be scaled to world propor-tions. Ideally the model would also come in parts which could hypothetically be animatedbased on data.

Moreover, there was also a need to connect the stations to the signals. In contrast to thespacecraft, labels are less useful for this case. Mainly because they would easily clutter sinceall stations are placed on Earth. One option would be to have labels on the ground, butsimilar to the 3D models, these would only be visible once navigated close to the node. Froman overview from space it would not be suitable to use labels. This is where a decision to usecolors representing the different locations on Earth became an option. By coloring the radiowave communication lines according to where on Earth the transmission is one can determinewhere the communication is from by association. The disadvantage with this method is thattoo many colors become hard to keep track of, and there are over 12 stations part of the DSN.However, by separating on location it would be more intuitive where the signals come from,even if it is not possible to know exactly what dish is working without navigating closer to it.

To illustrate the coverage of the DSN stations to an observer there was an idea of simulat-ing their field of view with cones. To connect them to each ground station location the fieldof views would be colored the same way as the signals. Though this would not be as exactas using an actual terrain mask, as described in the section [11] it would convey the conceptof their vast coverage. Because the size of the coverage would they would easily become thefocus of the visualization, while the intention is for it to be a helping tool to understand thetransmission coverage. To combat this it was decided that this part would not be activatedby default but a feature that should be easily activated and deactivated.

4.3 Radio wave communication

Regarding the radio wave communication visualization there were several alternatives con-sidered. The first was a, fully colored line going from spacecraft to station, only active duringthe transmission window and not showing any travelling through space, see figure 4.1. Thissolution was similar to DSN Now, see section 2, since it shows the current activity of theground stations. Though this is a great way of indicating the current activity on Earth it doesnot show how far it will take the signals to reach that spacecraft, or that incoming signals toDSN often have been sent hours before arriving. In short, it would be a point-to-point visu-alization of the current activity of the ground station, with a possibility to visually indicateuplink or downlink with an effect. However this would create a bigger demand on the ef-fect to be clearly discernible since the lines of both uplink and downlink would both be fullydrawn from spacecraft to station. The advantage of using this visual representation is that itonly requires the position of the spacecraft during the transmission window, and that couldbe derived from both data sets. However, whether the position of the spacecraft is accurate

14

4.3. Radio wave communication

would be a question of relativity. A question to be considered is whether the position wouldbe where the spacecraft is located currently according to time in OpenSpace or whether itwould be the position of it when the transmission is sent or received. Communication onEarth where the speed of light means almost instantaneous communication does not posethis problem which have to be considered here.

Figure 4.1: Point to point communication visualization. P1 and P2 represent the dish locationand the spacecraft location. The line represents the transmission between the two.

An alternative method of storing more lines for each transmission was also considered,with the end points being expressed in OpenSpace world coordinates for that particulartimestamp. A short colored segment of a line would be drawn from that particular pointin time, travelling at the speed of light and aimed towards the position where the spacecraftor station will be after the signal has travelled through space, as seen to the left in figure 4.2.Slightly later a new short segment would travel from a slightly different start and end po-sition, while the previous segment continues its course from the previous positions, see thecenter and right part of figure 4.2. This method would be more similar to the actual physicsof photons that occur since it considers that everything is in constant motion, but it wouldalso require further considerations in estimating where the end point will be positioned inthe light travel time compensated future. Thus to simply position the spacecraft during thetransmissions would not be enough. This would require more focus on the data handlingand storage of line end points at runtime.

Figure 4.2: Li’s represents lines where L1 is the first one occurring followed by new lines astime progress, from left to right. The black dots represent positions of two moving objects(station and spacecraft) at the current time, while the grey represent them at previous andfuture points in time.

With these methods there is also a challenge of showing what direction the signals aretravelling, i.e. whether they are uplink or downlink. Even with the methods that use seg-ments travelling at the speed of light this is a challenge for the outer space signals because ofthe immense distance. A flow effect is a good way of making this more clear.

Another challenge was overlapping communication lines. The cases with MSPA, de-scribed in section 3.1.1 is one such case, but also two-way communication mentioned earlier.Since there can be multiple downlink there could possibly be a need for indicating this. Onesuch method could be to have a different color indicator or to curve the lines so they do notoverlap.

The third visualization method is a compromise between the previous two. Similar to themore physically accurate method it requires spacecraft positioning outside of the transmis-

15


sion windows. However it only keeps track of one start point and one end point for eachtransmission in memory, so it is not as computationally and implementation heavy as themore physically accurate one. The idea is to retrieve the start and end position of the trans-mission line from the OpenSpace scene graph nodes. Similar to the previously describedmethod it will send out segments in succession, but instead of keeping the start and endposition in memory for that particular moment in time, it keeps track of how far the signalhas supposedly travelled since the beginning of the transmission. The difference in positionbetween the more physically accurate version will be visually minuscule from an overviewwhere the difference in distance that the end points will move will be insignificant comparedto the distance light travels in that time. Thus the line would appear almost straight. If look-ing at the transmission course in detail the physically accurate method would not have itssegments in a straight line, however this latest described method would, as seen in Figure4.3.

Figure 4.3: Concept of the visualization of a signal travelling through space from a dish to-wards a spacecraft or from a spacecraft towards a dish. P1 and P2 represent the start and endpoint of the transmission and the orange rectangles represent the signal.

How these different visual representations were implemented is described in greater de-tail in the next chapter.

16

5 Implementation

The implementation of the NASA deep space network visualization is described in this chap-ter. Throughout our contact with JPL staff some data samples were given that originallycontained data sampled every minute. However this was later changed due to the effort andtime to generate this data for the whole fleet. A compromise was made where continuousdata was sampled once every hour and the transmission windows contained samples everyminute.

Since the different data sets contain different information a decision to focus on the JPLdata instead of the XML data was made. The reason for this was that it would convey moreinformation to look at the history of the communication, while the XML data was more suit-able for a live mode. The JPL data contained more essential information regarding the trans-mission which are the start and end time as well as uplink and downlink, while also havingpositioning for spacecraft at all times. Though the light travel time was not originally in thetransmission schedule, it could be added from the position data.

This chapter describes the preprocessing of that data and what data format this resultedin and what it was used for. There are also a description of the chosen implementations thatwere discussed in chapter 4. This includes the ground stations, the individual spacecraftand the radio waves representing the signal transmission. The last part is the station field ofviews, where the transmission coverage from each ground station is simulated.

5.1 Preprocessing of raw data and Data formats

In order for the data obtained by JPL to be usable in OpenSpace, it has to be preprocessed toa certain format. OpenSpace has its own time handling that keeps track of the current timein the software timeline. This time can be used to decide what data is relevant for the currenttime frame. There were two types of original data that was obtained through contacts at JPLand those are CSV positioning data and scheduled communication, see section 3.4.

The positioning data was originally only separated per spacecraft. Since looping throughall files and objects to find a matching time is not an option performance wise both data setswere preprocessed using Python scripts. The first Python script was used to create a desiredJSON format designed to be read into OpenSpace. The sample files was sorted by time andinitially the Python script was designed with this in mind. The files were sampled everyminute during the transmission times. Some of them contained errors explaining that no

17

5.1. Preprocessing of raw data and Data formats

ephemeris data could be retrieved for that time, resulting in no positioning data for that time.These errors were removed manually and meant there were some gaps in the data, howeverfor such tightly sampled data this was not considered an issue because the gaps in data werenot big enough to be visible in the visualization. The next problem discovered was that somefiles, often but not exclusively the same ones that included an error, contained duplicateddata or partially unsorted data. This lead to errors later on since the scripts worked on thepremise that the data was sorted. Thus another script was created that first sorted the rawdata and got rid of duplicate data. The mentioned errors as well as unsorted and duplicatedata were never found in the hourly sampled data, however the sorting scripts were also runon these even though no difference were found in the files afterwards.

In order to speed up the search for the correct timestamp when OpenSpace reads fromdisk, the CSV positioning data got separated into smaller JSON files. Only the data neededto position the spacecraft got transferred to the processed data formats, making the new datafiles smaller than the old ones. Also the files were renamed with a timestamp which can beused to determine where the data is located by comparison with the filename rather thanhaving to open the file and look through all timestamps of the JSON objects inside.

The final processed positioning data used in the visualization is in JSON format. Thepositioning data is separated per spacecraft and hour. Each file contains a timestamp, rightascension, declination, range and light travel time for the spacecraft. The data files are namedas the timestamp with an hourly precision. The format of the data is shown in figure 5.1.

Figure 5.1: Sample of the positioning data. From top to bottom the values represent times-tamp, right ascension measured in degrees, declination measured in degrees, range measuredin kilometers and light travel time measured in seconds.

The original scheduled communication data had information about all spacecraft in thesame file, but is separated into one file per week. This data is also split up into smaller files,one file per day, and turned into JSON format. The reason it was divided by day was be-cause the longest light travel time is almost one day. To handle transmissions over midnight,a buffer of one day before the transmission and one day after the transmission is kept in thesystem at all times. The light travel time information is a part of the positioning data butoriginally not part of the scheduled communication. However while working on the Voyagersignals with very long light travel time it became apparent that it was necessary to include itin order to visualize the uplink and downlink transmissions travelling through space. In or-der to add the light travel time to the scheduled communication, each signal was compared tothe closest timestamp for the particular spacecraft in the positioning data and the light traveltime was copied from that file to the scheduled communication data. To see the workflow ofthe preprocessing, see figure 5.2.

18

5.1. Preprocessing of raw data and Data formats

Figure 5.2: Preprocessing work flow chart. The numbers represent different scripts used onthe different sets of data. The same sorting script, (1), was used to sort the raw CSV data bothwith hourly and minute precision. Script (2) combined the hourly and minute position datawhich was used in OpenSpace. Script (3) converted the raw CSV schedule to suitable JSONformat. Script (4) added the light travel time from the positioning data into the transmissiondata which was used to visualize the signals in OpenSpace.

The total size of the processed data per spacec raft vary in size because some have mostlybeen sampled every hour, while others with lots of transmission time have been sampledevery minute for long times. On average the processed data is approximately 200 MB, com-pared to the total size of the original raw data which is approximately 300 MB per spacecraft.However by dividing the data into smaller files, they are only around 10 KB in size. At mostthree of the smaller data files per spacecraft are kept in memory at the same time. Thereare almost 70 spacecrafts part of this visualization which means in total, if all spacecrafts areactive at the same time, around 2 MB are kept in memory at all time.

The final processed scheduled transmission data is also in JSON format. The data hasinformation about all transmissions scheduled on the DSN, separated per day. The data con-tains the start time of the transmission, the name of the station used to communicate, the endtime of the transmission, the name of the spacecraft, the direction of the signal and the lighttravel time from Earth to the relevant spacecraft. This is shown in figure 5.3. The data filesare named as the timestamp, with a daily precision.

The total size of the processed scheduled transmission data is approximately 16 MB com-pared to the original data which is approximately 22 MB. The smaller data files separated perday however are only around 10 KB. The position data from three of these smaller files arekept in memory at all time.

There was some error handling and warnings implemented in OpenSpace for the parsingof JSON data. Invalid JSON objects are logged and can be traced to the file where the erroroccurs. However there are no checks for validating that the data are within correct valueranges.

19

5.2. Stations

Figure 5.3: Sample of the processed signal data. From top to bottom the values representend time for the transmission, dish name, start time for the transmission, spacecraft name,direction of the transmission, and light travel time measured in seconds.

5.2 Stations

To create the stations in OpenSpace there was a need to position the different stations for eachcommunication complex. The longitude and latitude data that was found in documentationfrom JPL by Folkner et al. [9] was not available from the start. Because of that, the initialplacement of the stations were quite rough. By using the publicly available latitude andlongitude data from JPL described in section 3.4 the placement became precise. The function-ality to place scene graph nodes on Earth using latitude and longitude was already a part ofOpenSpace since a globe browsing feature was implemented by Bladin et al [5]. All of theDSN stations have been placed using this functionality.

In order to visually represent the stations on Earth, the publicly available 3D modelsmentioned in section 3.4, have been used. Two different models for the 70 meter antennasand 34 meter antennas have been used since the models were already scaled properly andOpenSpace has a coordinate system in meters.

When the stations are positioned, they are rotated to stand perpendicular to the Earth sur-face, no matter how Earth is rotated. Since the stations were spread out over three locations,three different rotation matrices have been used. A property was implemented to be able torotate the models around their axes within their local coordinate system. This feature wasused to find the appropriate static rotation matrices.

5.3 Spacecraft

To insert the spacecraft into the scene there was a need to create a new translation class thathandled the data that was available to us. As mentioned in section 5.2 the initial placementof the stations were not exact. Thus a decision to use right ascension and declination insteadof the observer relative azimuth and elevation was taken early on. This section describes the

20

5.3. Spacecraft

work of implementing this positioning class. It further describes the work of representing theindividual spacecraft visually as well as the complete fleet of spacecraft.

5.3.1 Spacecraft positioning

To position all of the spacecraft nodes in OpenSpace two different methods were used. Afew spacecraft had SPICE data available for the relevant time frame of this visualization. Forthose spacecraft, an already existing function in OpenSpace was used for positioning usingthat data.

However, most of the spacecraft did not have any continuous SPICE data available forlonger time periods. For these spacecraft, right ascension and declination from preprocessedpositioning data have been used, see section 3.4. Functionality to position scene graph nodeswith information about right ascension, declination and range from Earth center have beenimplemented for this project as follows.

The data files are sorted and named after the relevant timestamp as described in section5.1, and those timestamps are stored in a vector upon application start. This method to nameand choose files from disk named by dates was described by Carlbaum and Novén [8]. Anupper bound binary search is used to match the current time in OpenSpace to the closesttimestamp from that vector. Another binary search matched the current time in OpenSpaceto the closest timestamp within that data file. In order to accurately create the positioningthe light travel time had to be taken into consideration. The light travel time is subtractedfrom the current time and used to retrieve the light travel compensated data file. When thecorrect data file is found a chunk of data with all positions for the previous, current and nexthour are loaded into OpenSpace. Since the file parsing is slow the previous and next hour areincluded so that the data is preloaded no matter if the time in OpenSpace move backwards orforwards. Thus the data for an active spacecraft will contain between three and 180 positionsdepending if there is data sampled every hour or every minute. The current right ascension,declination and range was converted into Earth relative Cartesian coordinates. The Earthrelative Cartesian coordinates got rotated to match the equatorial sphere, already a part ofOpenSpace, and translated again to world Cartesian coordinates with the sun as the origin,same as for the rest of OpenSpace.

5.3.2 Close up representation

To represent the close up view of the spacecraft 3D models were added, in the same fashionas for the stations. However there was a problem that not all spacecraft had a 3D modelpublicly available. Since the fleet consisted of a lot of spacecraft the option would either beto omit models or using dummy models since there was not enough time to custom makeall. The choice was to omit models, thus only a few of the spacecraft has a 3D model closeup representation. However, even by using a 3D model of the spacecraft it is not enough torepresent the spacecraft from an overview perspective of the DSN. The solution to this wasto add labels for each spacecraft.

5.3.3 Overview representation

To give an accurate understanding of how many spacecraft are part of DSN a class to renderlabels was implemented. The labels were created in part by using an already implementedfont renderer in OpenSpace. This font renderer kept track of transformations and made surethe labels would be oriented correctly as camera-facing billboards. The label was attached toa scene graph node by using its world position.

Using the world position of the objects causes issues with precision, described in section3.2 and an example can be seen in figure 5.4. Instead of using the actual world position for thelabels, a set distance from the camera was used to place the font billboard in 3D space. This

21


made it possible to place the font further away from the camera than the object is, technicallynever moving closer to the font position. This meant the precision problems would not causecatastrophic error for the label even when approaching the object it was representing.

Since the label was rendered at a set distance from the camera in the direction of the object,the effect of something being small at a distance and gradually growing when approachingwas lost. To make a visual impression of approaching the object, the label size was givena maximum size and a minimum size. It also was given two distances, a maximum anda minimum, between which the current distance between the camera and the object wasnormalized to a font size in the defined interval. This concept is illustrated in Figure 5.5.

The labels solved the spacecraft visibility problem, but brought new issues. The hugenumber of spacecraft and the size of each label meant that the view of the solar system becamecluttered. When the camera is close to Earth, with its frustum facing out in space in differentdirections, most spacecraft will be spread out in the solar system at screen space. This viewallows visibility of most labels. However, moving away from Earth while the camera viewis rotated towards it quickly puts most labels at the same screen space point. This means alllabels closer to Earth are stacked on top of each other. A solution to this was to separate thelabels into groups depending on how far they are from Earth and using different distancesfrom the camera to fade the labels in and out during OpenSpace navigation.

Some spacecraft are close to each other even after some label visibility culling has takenplace. For example the case with the Mars missions. When rendering individual labels foreach of these spacecraft some labels inevitably end up on top of each other, making themhard to read. To avoid this, an additional label, referred to as a cluster label, is created and at-tached to a common node, for example Mars. The fade in and fade out distances are tweakedtogether with the individual labels for the spacecraft. When the camera gets closer to thoselabels it will eventually fade and the individual labels will fade in.

Since the labels could be larger than the planets in screen space and sometimes not veryfar from each other it was difficult to see exactly which spacecraft the communication wasgoing to or where exactly it was positioned relative to the label. Another design feature wasadded by adding a dot in the lower left corner of the label. An offset was added to the fontrendered on the billboard to make sure the communication line would always go through thedot. This helped to further clarify the position of the spacecraft.

Figure 5.4: A label rendered with precision uncertainty. The crooked look of the text is due tothe precision uncertainty caused by the vast distance between the camera and the label.

5.4 Radio wave communication

Another important part to the visualization was to implement the actual signals, or radiowaves, travelling through space. The visual result that was the goal of the implementationwas the last representation mentioned in chapter 4.3 and seen in figure 4.3. The signals are

22


Figure 5.5: A scene graph node position is projected onto a view frustum plane at a staticdistance from the camera to determine the label position. The label size is scaled dependingon the distance from the object.

represented as lines and the lines are implemented with an OpenGL function called GL Lines[3]. The lines were also translated to start at the top of the 3D models used to represent thedifferent stations instead of starting at the station origin. This was done by calculating thevector outgoing from Earth towards the station, then translating by the height of the stationin that direction. The lines are given different colors depending on which ground station issending or receiving the signal.

Precision uncertainties, described in section 3.2 occurred when using the world positionsof the station and spacecraft nodes. This resulted in flickering lines. This problem becamemore apparent the closer one navigated to the end points. To combat this issue the OpenSpacefocus node is used by using a translation matrix that is made at runtime with its current worldposition. The world positions of the station and spacecraft are expressed relative to the worldposition of the focus node. This means that if a station is chosen as focus node, the x, y and zcoordinates used to express the line end would become smaller as one navigates towards it.This counteracts the precision problem that became more visible when navigating closer. Thetranslation matrix is multiplied with the view matrix of the camera before the other calcula-tions are made on the shader. Since multiplication with the view matrix expresses the worldbeing rendered relative to the camera, a translation subtraction is made with double preci-sion. The large precision prone numbers, i.e. world positions, were eliminated before theshader calculations are performed. Thus the shader can compute the rendering on smallernumbers using floating precision while maintaining high accuracy.

Information about for how long time the transmission line is going to be visible is takeninto account. The beginning of track (BOT) and end of track (EOT) from the processed sched-uled communication is used to determine for how long the line is going to be active. Depend-ing on if the signal is an uplink or a downlink, the light travel time is taken into considerationto extend the active time frame in the direction that the signal is active. If the transmission istwo-way two signals are handled independently, one for uplink and one downlink. To visu-alize the signal transmission travelling through space a cutoff was made at transmission startand transmission end, where the rest of the line had zero opacity, see Figure 5.6. The visiblepart of the line is moving with the speed of light, until the end of the signal had reached itsend destination.

To determine what signals to render at any given time in OpenSpace, the correct datafile is found through a binary search. When the relevant file is found, all signals from thatfile was compared to the current time in OpenSpace. If the current time was in between thelight travel time adjusted BOT and EOT the transmission would still be active and the signalwould be rendered.

To be able to handle signals transmitting over midnight and to be able to handle spacecraftwith a long light travel time, a buffer is used. Since the longest light travel time is approx-

23

5.5. Station field of view

Figure 5.6: Signal line concept where a signal travels from position P1 to position P2 withvelocity Vt. The flow speed effect of the signal segments have velocity Vs.

imately 18 hours, only one file (24 hours worth of data) after the current time and one filebefore the current time is needed as a buffer since no signal would ever be active out of thattime frames.

To visually represent if the signals were travelling towards the spacecraft or towards thedishes, a flow speed effect, is implemented on the fragment shader. These have a set speedthat by default is set to the speed of light, see figure 5.6, but can be changed to travel faster toindicate uplink and downlink.

5.5 Station field of view

To convey the coverage of the DSN described in section 3.1.1, a class for the station fieldof view (FOV) was implemented. Before that, a cone class was created. This was the baseclass of the station FOV. The station FOV was then customized to attach its cone apex to anOpenSpace scene graph node and to specify the direction vector to the center of the cone base.The apex tip of each field of view cone was positioned at the the 70 meter dish for each of thethree ground stations and the direction to the base center as outgoing from the node of Earth,see Figure 5.7. The colors of the station field of views follow the same color as the radio wavesignal transmissions for the respective locations.

Figure 5.7: Station field of view is represented by the cone in this figure. The tip of the coneis where the station is located.

The station FOV was implemented to have a radius so that everything more than tendegrees above the horizon for each station would be part of the station field of view. Thebase of each cone was faded out in order to simulate the decay of the signal strength that

24

5.5. Station field of view

comes with great distance. The height or length of the cone was preset to a value that is bestviewed from an overview of the solar system. No particular formulae were implementedfor this since it is not based on data, but merely strives to deliver the concept for a betterunderstanding. The fading was made using the default linear interpolation of the fragmentshader. The precision problems were handled in the same way as for the radio waves, seesection 5.4.

25

6 Results

The final result of this project is an interactive visualization of the NASA deep space networkimplemented as a part of the OpenSpace software. The visualization consists of labels and 3Dmodels to represent spacecraft, 3D models to represent communication complexes on Earth,line segments to represent the radio wave communication and cones to visualize the stationfield of views. This chapter will further describe the results of the final visualization.

Figure 6.1: Four dishes from the Goldstone ground station. Two 34 meter dishes are trans-mitting signals.

6.1 Visualization of the DSN stations

There are 15 stations, split up into three ground stations part of the DSN and representedin this visualization. Each station has been represented with a real world scaled 3D modelas can be seen in Figure 6.1. The figure shows two of the stations transmitting and differentmodels used for the different sizes of the dish.

26

6.2. Visualization of the spacecraft

6.2 Visualization of the spacecraft

There are approximately 60 spacecraft visualized from January 2014 to January 2019. Thesespacecraft are active missions that have scheduled transmissions some time within that time-frame. In other words, there are even more spacecraft out in space that have the capabilitiesto communicate with DSN, but some are not in use because the transmissions are not fundedanymore. A few Earth orbiters are also using DSN for communication, and these have beenincluded as well. Those that have been omitted from the schedule are certain spacecraft withanother configuration code than 1A1, see section 3.4. Only 1A1 was the actual scheduledtransmission according to JPL staff. This matched the observations regarding the data, forexample James Webb Telescope was included in the data but had a different code than 1A1and is yet to be launched. All spacecraft are represented with a label, see Figure 6.2, andsome spacecraft are represented with a 3D model as well. The 3D model is only visible whenthe camera is close to the spacecraft 6.3. Since the labels occupy a lot of screen space, smalldots in front of the labels are used to represent a more precise position of the spacecraft. Thespacecraft are divided into groups, those near Earth, those in the inner part of the solar sys-tem, those in the outer part of the solar system and those that have left the solar system. Thedistance from the camera to the group of spacecraft is used to decide if the group of labelsshould be visible or not. As the camera moves away from its original position near Earth, thelabels of the spacecraft in the near Earth group are faded out and so on.

To position the whole fleet of spacecraft by reading from JSON files from disk bringsdown the performance. A binary search of the name only have logarithmic complexity,log2(last ´ f irst) where last and first represent the last and first value in a sorted vector. Thisis an improvement from the linear case of looping, however the biggest performance save ismade by being able to do this on the filename without having to open a file and parse thedata inside to be able to determine if the time is correct.

Figure 6.2: Close up of the Voyager space-craft showing the 3D model from NASA.The red line indicates current incomingor outgoing signal communication fromCanberra.

Figure 6.3: Spacecraft labels near Earththat fade in and out upon navigating to-wards and away from them. The dot inthe lower left corner of each label indi-cates the spacecraft position.

The case with cluster labels were used for multiple cases, such as for Lunar missions andMars missions including the voyage of InSight, MarCOA and MarCOB from Earth. A clusterlabel of multiple spacecraft merged into one label is shown in Figure 6.4.

27

6.3. Visualization of the radio wave communication

Figure 6.4: The labels for the spacecraft near Mars merged into two clusters i.e. "InSight,MarCOA & MarCOB" and "MarsOdyssey, MRO ..." which reduces the cluttering on screenwhen many spacecraft are visible at the same time.

6.3 Visualization of the radio wave communication

The DSN communication have been visualized as line segments travelling through space, asdescribed in section 5.4. Its length would be the light travel time multiplied with the time thetransmission is being sent, thus a three hour transmission will show up as a shorter line seg-ment than a five hour transmission. The signals are travelling with the speed of light, towardsthe spacecraft if the transmission is an uplink and towards the stations if the transmission isa downlink.

In order to visualize how far away the transmissions are going or coming from, the trans-missions lines have been split up into smaller segments. The greater the distance from thestation to the spacecraft, the bigger the segments. This makes it possible to approximatelytell the distance to a spacecraft even if the spacecraft is not in view. In order to further clarifythe direction of the transmission, these smaller segments are moving within the transmissionlines. The default speed is set to the speed of light, but a property to change this is available.

To clarify which ground station is handling which communication, the signals have beenvisualized with different colors. Blue for communication with the Goldstone ground station,red for Canberra and green for Madrid. Communication with all three ground stations areshown in Figure 6.5.

6.4 Ground station field of view

The ground FOVs are simulated as three cones colored the same way as the signals, bluefor Goldstone, red for Canberra and green for Madrid. They are not activated by defaultbut can be activated by shortcut commands. The width of the cone bases are set so thatthe station FOVs are approximately ten degrees above the surface in all directions whichserve an illustrative purpose. To simulate the decay of the signal strength that occurs withgreat distances, the cone opacity have been faded out with distance. The station FOV for allcommunication complexes are shown in figure 6.6.

From some angles, it is hard to tell the shape of the ground station FOV. To improve thisa wire frame representation is also available. The wire frame representation of the stationFOVs is shown in Figure 6.7.

28

6.4. Ground station field of view

Figure 6.5: Signals going from and towards all three ground stations, colored according tolocation. The pale orange clustered labels helps the readability around Mars. The grey labelsrepresent individual spacecraft.

Figure 6.6: Station field of views colored according to ground station with Goldstone as blue,Madrid as green and Canberra as red. They illustrate the potential range of each groundstation location on Earth.

29

6.4. Ground station field of view

Figure 6.7: Wire frame representation of the station field of views colored according to groundstation with Goldstone as blue, Madrid as green and Canberra as red. They illustrate thepotential range of each ground station location on Earth.

30

7 User test

User tests were performed on two people who had a good basic understanding about spaceand inter planetary communication. They had limited experience with OpenSpace, but werefamiliar with other similar systems like Uniview [12].

7.1 Design and purpose

User tests were split into two phases. The user was guided through both phases by the testleader. Notes about the users’ actions were taken by the secretary. The user’s answers to thequestions were also written down as well as basic information such as age, occupation andprevious experience with similar software.

The first phase of the user test was designed to evaluate how intuitive the visualizationis. The user was asked to freely navigate and explore the visualization and at the same timethink out loud and describe what was seen. Everything was written down, both the questionsand comments provided by the user and the actions that was taken by the user to navigatearound the visualization.

The second phase was designed to get feedback on things that did not get mentionedin the first phase. Here the user got to answer questions about the visualization while stillnavigating through it. The questions were designed to test if the user would navigate throughthe system in the intended way, when answering the questions.

7.2 Result

Over all the user test showed that the visualization was understandable and educational. Themeaning of the lines travelling through space was clear to both test persons as well as whatthe different colors represented. The visualization made the test persons think about howslow the speed of light looked in relation to the distance between Earth and Voyager andthrough that how big the universe is compared to Earth.

One thing that caused some confusion was the orientation of the station field of viewcones. One test person suggested that they should be shaded on the inside to help clarifythe direction of the field of view. Another improvement suggestion was to shade the parts ofspace that got lit up by it instead of rendering cones.

31

7.2. Result

Another minor deficiency of the visualization was the fact that none of the test personsused the dashboard in the top left corner. When confronted with this after the test, they bothsaid that they had not seen it but that it contained information they had been looking for.

There were also some confusion towards the signals going both towards the spacecraftsand the station at the same time. The two lines rendered on top of each other made it hard totell which direction the flow particles were going. Both of the test persons mentioned this asan issue that could be improved.

32

8 Discussion and analysis

In this section the result and implementation of the visualization will be evaluated. Whatturned out as planned and what did not turn out as planned? What could have been donebetter and which difficulties were faced during the project design and implementation?

8.1 Results

In addition to a few structured user tests, an informal presentation of the project was alsoarranged at AMNH where further feedback was given from the audience. All people testingand giving feedback have been working at AMNH or are using UniView for educational pur-poses. Thus their understanding and interest of the system may be higher than the averagemuseum visitor, however most were not familiar with DSN before. The main purpose of thisvisualization was to increase the knowledge and understanding of how the DSN works. Theuser tests showed that the visualization did just that. It clarified, and gave the user a basicunderstanding of how the different ground stations complement each other.

The extensiveness of the DSN was visualized through the large number of spacecraftsbeing seen at the same time, as well as the coloring of the signals, telling the viewer what partof DSN was responsible for the transmission. The visualization of signals travelling throughspace even after transmission stopped on Earth gave further understanding of the vastnessof space and the challenge of communicating in it. The user test showed that it was a greatway to create a visual understanding of the network.

The stations on Earth were represented as 3D models and the actual radio waves travel-ling through space were represented as line segments. The user test, as well as presentationshowed that everybody understood what the different stations on Earth represented and howthey were used to send radio waves through space. The users understood that the transmis-sion lines were travelling at the speed of light and that they indicated signal transmissions.There were some confusion about the sizing of the line segments. One tester expressed thatshe thought it could be related to the frequency or wavelength of the signal. This is mostlikely due to the fact that wave patterns in 2D is a common way to represent radio waves,thus there could be a pre learned association which could be worth exploring further. An-other question arising during a presentation was if the segments were scaled to the amountof data being transmitted. The segments were initially an implementation to make the direc-tion of the signal more apparent. The segments were initially inspired by barber poles and

33

8.1. Results

only had slightly faded areas moving through the lines, but were later changed to include aspacing. This was implemented in a phase where only data for the Voyagers had been given.As mentioned in section 3.1.2, the Voyagers are an edge case. Later on more spacecrafts nearEarth were introduced. First it became apparent that the segments were too big, so the lighttravel time was included in the shader and used as a factor to rescale the segments. The nextthing was that for the near Earth case that the flow effect of the segments travelled faster thanthe signal transmission. For cases where the light travel time was shorter than the transmis-sion time this meant that it looked like the radio wave transmission travelled faster than thespeed of light. This physical impossibility might go unnoticed by a user who simply wouldunderestimate the light travel time distance to the spacecrafts instead. Thus the segmentswere changed to travel at the speed of light by default, but keeping a property controllingthe speed of the effect. This proved useful to be able to differentiate between uplink anddownlink for the Voyagers in real time.

The implementation of station FOVs aims to give an understanding of the immense areasthat are covered by each individual ground station and why the network would not beecomplete without all three of them. It was clear to the test subjects what this meant, howeverit was sometimes hard to tell the direction these FOVs are pointing. The station FOVs alsogave a better understanding of how the DSN works and how the ground stations complementeach other. It was possible in some cases to see the line segments, representing the radiowaves, arriving at a station precisely at the same time it came in to the station field of view.This shows the precision and amount of planning put in to the network.

One thing that the user test subjects had not thought about before, was how far awaysome of the spacecrafts actually are and how long it takes for radio waves to reach them.Most people using the visualization for the first time were surprised by the fact that the radiowaves, travelling with the speed of light, looked almost frozen in the zoomed out view of thesolar system. This illustrates that the visualization, in a way comprehensible to a layperson,is visualizing the vastness of space and how slow interplanetary communication actually is.

The user test also showed that some people had a problem understanding the represen-tation of communication going both towards the spacecraft and towards the station at thesame time, i.e a two-way communication. It was represented by two signals going over eachother in different direction which resulted in one line, pretty much without flow particle rep-resentation. An adjustment was made that enlarged the spacing between the segments, butthis could be improved in many other ways, either fairly easily by representing it with adifferent pattern or color. It could also be improved, by changing the representation of thecommunication completely from a line to a wave pattern. This potentially would make iteasier to distinguish if there are two lines on top of each other. Although this visualizationillustrates some of the major challenges of creating the DSN, many of the challenges NASAfaces have not been visualized. For examples, the complications brought by space weather,tectonic plates movements causing stations to move, other planets covering the field of viewto some spacecrafts and the precise aim necessary to make the signals reach the spacecrafts.Another thing that has to be taken into consideration when creating the DSN is the fact thatthe radio waves used to transmit are very strong and actually dangerous to humans. Becauseof this, NASA has to clear the air space before transmitting. All of these difficulties are a partof what makes the DSN such a delicate system but have not been shown in this visualization.

The data used to position the spacecrafts was sampled every minute during the windowsof transmission and every hour continuously. The movements of the spacecrafts are verysmooth during transmission, i.e when there is minute data available. However when thereis only hourly data available, the spacecraft movement becomes jagged as a result of onlybeing updated once per hour. For the spacecrafts far away, it is not very noticeable. Forthe spacecrafts orbiting a planet however, the hourly data is not sufficient. As a result ofthe sparse sampling of positioning data and the fast movements of the spacecrafts aroundthe planet it is very hard to tell that the spacecrafts are orbiting. In the time between thesampling points, the spacecrafts position have often moved to the other side of the planet

34

8.2. Implementation

or in some cases almost all the way around. Another issue with the hourly sampled data fororbiting spacecrafts is the movement of the planets. Between the sampling points, the planetswill keep moving while the spacecrafts are frozen in space. This causes the spacecrafts to lagbehind the planets and then catch up again when new data is available. For the spacecraftsfar away, a linear interpolation would be enough to smooth out the jaggedness. For theplanet orbiters however, the data has to be sampled more often than once per hour or anothertranslation class would have to be implemented to position the spacecrafts relative the planet.

The positioning of the spacecraft with right ascension and declination works as expected,however the data range from the data seem to have way too high resolution, down to mil-limeter precision, which is not reasonable. This leads to the conclusion that the data probablycontains some noise.

The labels used to visualize the spacecraft have some erroneous behavior when thereare other 3D objects closely behind the node that the label is attached to. Since the methodimplemented renders the label on a set distance from the camera, this becomes an issue whenthis distance is longer than the distance to an object behind the node the label is attached tobecause the label is placed behind it. However this is mainly a problem while navigatingmore closely to orbiters and landers.

The labels are overall performing the task of giving an overview of the spacecraft fleetvery well. They are working as designed and transition in visibility and sizing smoothlywhile navigating in the universe. They are seldom overlapping and when they do it is fromcertain angles with particularly closely placed spacecraft.

8.2 Implementation

One challenge through out this project has been the limited access to data. The design of thedata handling had to be implemented before access to all of the data was available and beforethe final format and sampling frequency of the data was set. If all of the data was available inan earlier stage of the project, some other design choices could have been made. Full accessto the CSV data from JPL, on which this visualization is based, was not available until the lastcouple of weeks of the project since it was generated during the course of the project.

The DSN Now XML data, see section 3.5, are however publicly available and have beenavailable throughout this project. There is also similar information in that data set as in theJPL data. One of the major reasons that this data was not used for the visualization is thebecause it only contains information about the current time. It is possible to collect and savedata from that DSN Now, and functionality to save XML documents were implemented forthis project, although they were never used. However, even if the data was collected from thevery start of the project, there would only be five month worth of data available. One of thegoals for this project was to be able to show communication over a long time, and that is oneof the reasons the JPL data was chosen over the XML data from DSN.

Another big part of this project was to increase understanding the extensiveness of theDSN and about the complexity to plan the communication. In order to do so, a major partwas to visualize the entire fleet of spacecrafts at all times. For that to be possible, the data hadto contain information about the location of the spacecrafts even when they were not com-municating through DSN. Apart from only showing live data, the biggest difference betweenDSN Now and the work described in this report is the physical representation of the space-crafts and their relation to Earth and other celestial bodies. The DSN Now XML data onlycontained some information, such as range, about the spacecrafts that were communicatingat the given time. This is enough on a web page like DSN Now where only the numbers show,but becomes more difficult when they should be accurately represented in 3D space. A visualmethod to approximate the spacecraft position was initially considered with the azimuth andelevation for the station combined with the range to the spacecraft. Azimuth and elevationare local coordinates and changes quickly as Earth rotates. This would require tighter sam-

35

8.3. Future improvements

pling for accuracy. Since the communication of each spacecraft was not evenly scheduled thislead to difficulties when we striving to visualize the whole fleet. If a similar project wouldbe conducted that already had the positioning of the spacecrafts, the DSN Now data wouldbe more useful using the currently chosen implementation. However this was not an optionduring the time of this project. That is another reason why the JPL data was the better choicefor this case.

8.3 Future improvements

An optimization of the data handling is something that would improve the performance ofthis visualization. Instead of dividing the data into many small files, separated per hour andday, bigger time frames could have been used. For example, the positioning data could havebeen separated per week or even month instead of per hour. This would not only improvethe performance of the visualization but also make the handling of the data faster.

Performance improvement is also true for the signal segment effect that could be replacedwith a sine function instead of looping through calculations of where the segments and spac-ings are based on speed multiplied with time. Also the representation of the segments as awhole could be revisited. As mentioned in section 8.1, there were some question marks re-garding the size of the segments. The flow particles described by Carlbaum and Novén arean example of other ways to indicate flow direction in lines [8]. They used brightly coloredtravelling particles with higher opacity than the lines to indicate direction of magnetic fieldlines. To implement a similar effect for the signal transmissions is possible and may lead toless questions. Another solution to the sizing issue could be to automatically rescale all thesegments depending on how close the camera is to Earth instead of passing the individuallight travel times for each signal. This would make the transmissions more uniform in theirlook and could thus lead to less confusion.

One thing that would keep this visualization relevant through time is to show the currentcommunication in a live mode. The data used by DSN Now, see section 3.5, could be used toshow the current communication. However, there is no information in that data about the po-sition of the spacecrafts when they are not transmitting. Either that information would haveto be obtained from some where else or the live mode would only show the spacecrafts thatare actually in communication. The data used by DSN Now is, as opposed to the data usedin this visualization, updated every five seconds and therefore does not contain informationabout a start time or end time for the transmissions. This means that for a live mode to work,some changes would have to be made to the implementation of this visualization. Either theway the signals are handled in the code would have to be changed or the DSN Now datawould have to be stored and pre processed in a way that makes it possible to obtain a startand end time for the transmissions.

36

9 Conclusion

The project resulted in a visualization showing the NASA communication between Earth andthe fleet of spacecraft. The main goal of the project was to increase the public understandingof the DSN, and to visualize the difficulties of communication in space brought by the vastdistances and constantly changing environment. Further, the system can be used to showcommunication for individual spacecraft in order to enhance the visualization of a specificevent. Throughout the course of the project there was an aim to respond to four researchquestions posed in section 1.4. By revisiting the initial research questions and answer them isa way of concluding the outcome of the work that has been performed.

How do we show the extensiveness of the network so that someone who is not familiar

with the system could understand it?

The extensiveness of the NASA deep space network is visualized through the large numberof spacecraft and signals part of the fleet. The fact that the whole fleet of spacecraft is visibleat all times, compared to only the spacecraft in current communication, creates a visual un-derstanding of how many spacecraft there are out there. The color-coded representation ofthe signals enhances the understanding of the fundamentals of the system, where the groundstations are spread out on Earth to provide the possibility for constant observation.

How do we visualize radio wave communication across widely varying distances when

celestial bodies and spacecraft are constantly changing positions in space?

In order to visualize the radio wave communication through space both the radio waves,ground stations and spacecraft have been shown. The radio wave communication have beenrepresented by lines travelling between the ground stations and the spacecraft. Instead ofdrawing a full line between the two positions, the line length is dependant on the length ofthe transmission and the line position is dependant on how far the light has travelled at thegiven time. This makes it possible to see how the line leaves the ground station and thenkeeps moving in the same direction, even though Earth’s rotation moves the ground stationaway and out of sight. In the same way it is possible to see downlink arrive at the groundstation just in time for Earths rotation to bring the station to the correct position. The mainfocus of the visualization have been Earth, and to convey the vast differences in distance fromEarth to the spacecraft the lines have been split up into segments that vary in length.

How do we visualize the vast transmission coverage of the deep space network in away

that shows the timing of the transmission schedule?

In order to visualize the vast transmission coverage of the strategically placed ground sta-

37

tions, the field of view for each location have been visualized as a color coded cone. When allcones are visible, i.e the field of view for all ground stations are visible, it becomes clear thatno matter where a spacecraft is located it will be within reach for communication. Havingcolor coded signals reach the ground station at the precise time it comes into the station fieldof view is how the timing and planning of the DSN have been visualized.

How do we visualize to a layperson how vast space is and how slow interplanetary

communication is?

The signals travelling with the speed of light is how the vastness of space is visualized. Whenthe spacecraft furthest away are communicating, it takes almost 20 hours for the radio wavesto reach them. Visualized in real time with both Earth and the spacecraft in the same frame, itlooks like the signals are almost stationary even though they are actually travelling with thespeed of light. With the common understanding of the speed of light as incredibly fast thefact that the signals look almost stationary travelling towards the spacecraft gives an idea ofhow far away it actually is.

38

Bibliography

[1] Ch Acton, N Bachman, L Elson, B Semenov, F Turner, and E Wright. “Extend-ing NASA’s SPICE ancillary information system to meet future mission needs”. In:SpaceOps 2002 Conference. 2005, p. 31.

[2] S Aoki, M Soma, H Kinoshita, and K Inoue. “Conversion matrix of epoch B 1950.0 FK4-based positions of stars to epoch J 2000.0 positions in accordance with the new IAUresolutions”. In: Astronomy and Astrophysics 128 (1983), pp. 263–267.

[3] Dave Astle and Kevin Hawkins. Beginning OpenGL game programming. Cengage Learn-ing, 2004.

[4] Axelsson, Emil and Costa, Jonathas and Silva, Cláudio T. and Emmart, Carter and Bock,Alexander and Ynnerman, Anders. “Dynamic Scene Graph: Enabling Scaling, Position-ing, and Navigation in the Universe”. In: Computer Graphics Forum, Proceedings of Euro-Vis. 2017.

[5] Bladin, Karl and Axelsson, Emil and Broberg, Erik and Emmart, Carter and Ljung,Patric and Bock, Alexander and Ynnerman, Anders. “Globe Browsing: ContextualizedSpatio-Temporal Planetary Surface Visualization”. In: IEEE Transactions on Visualizationand Computer Graphics. 2017.

[6] Alexander Bock, Carter Emmart, Masha Kuznetsova, and Anders Ynnerman.“OpenSpace: Changing the narrative of public disseminations in astronomical visu-alization from what to how”. In: Computer Graphics & Applications. 2018.

[7] Alexander Bock, Charles Hansen, and Anders Ynnerman. “OpenSpace: BringingNASA Missions to the Public”. In: IEEE Computer Graphics and Applications 38.5 (Sept.2018), pp. 112–118.

[8] Oskar Carlbaum and Michael Novén. Real-Time Magnetohydrodynamic Space Weather Vi-sualization. 2017.

[9] WM Folkner. “DSN station locations and uncertainties”. In: TDA Progress Report (1996),pp. 42–128.

[10] Mohinder S Grewal, Lawrence R Weill, and Angus P Andrews. Global positioning sys-tems, inertial navigation, and integration. John Wiley & Sons, 2007.

[11] Obadiah Kegege, Michael Fuentes, Nicholas Meyer, and Amy Sil. “Three-dimensionalanalysis of deep space network antenna coverage”. In: 2012 IEEE Aerospace Conference.IEEE. 2012, pp. 1–9.

39

Bibliography

[12] Staffan Klashed, Per Hemingsson, Carter Emmart, Matthew Cooper, and Anders Yn-nerman. “Uniview - Visualizing the Universe”. In: Eurographics 2010 - Areas Papers. TheEurographics Association, 2010.

[13] Jet Propulsion Laboratory. DSN Now, a live online representation of the DSN. Ed. by KevinHussey, Michael Rodrigues and Shannon McConnell. URL: https://eyes.nasa.gov/dsn/dsn.html (visited on 02/20/2019).

[14] JW Layland and LL Rauch. The evolution of technology in the deep space network: A historyof the advanced systems program. 1994.

[15] Douglas J Mudgway and Roger Launius. Uplink-Downlink: A History of the Deep SpaceNetwork, 1957-1997. 2001.

[16] Wallace S Tai, Alaudin M Bhanji, Edward B Luers, and Yuhsyen Shen. Deep Space Net-work Services Catalog. 2009.

[17] Jessica Williams, Premkumar Menon, and Stuart Demcak. “Mars reconnaissance orbiternavigation strategy for Mars science laboratory entry, descent and landing telecommu-nication relay support”. In: AIAA/AAS Astrodynamics Specialist Conference. 2012, p. 4747.

40

Interaktiv 3D-visualisering av NASAs Deep Space Network...

Documents

Transcript of Interaktiv 3D-visualisering av NASAs Deep Space Network...