Interaktiv 3D-Visualisering Av Nasas Deep Space Network Kommunikation Lovisa Hassler Agnes Heppich

Home , Glenn Research Center, NASA Deep Space Network

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

Interaktiv 3D-visualisering av NASAs Deep Space Network kommunikation Lovisa Hassler Agnes Heppich

2019-04-30

Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings universitet nedewS ,gnipökrroN 47 106-ES 47 ,gnipökrroN nedewS 106 47 gnipökrroN LIU-ITN-TEK-A-19/005--SE

Interaktiv 3D-visualisering av NASAs Deep Space Network kommunikation Examensarbete utfört i Medieteknik vid Tekniska högskolan vid Linköpings universitet Lovisa Hassler Agnes Heppich

Handledare Emil Axelsson Examinator 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ör ickekommersiell forskning och för undervisning. Ö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äkerheten och tillgängligheten finns det 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 upphovsmannens 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/

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on 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 be mentioned when 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/

Interactive 3D Visualization of the NASA Deep Space Network activity – Visualizing communication across great distances

Interaktiv 3D visualisering av NASAs Deep Space Network kommunikation

Agnes Heppich, Lovisa Hassler

Supervisor : Emil Axelsson, Carter Emmart Examiner : Anders Ynnerman

Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publiceringsdatum 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 kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Ö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 ﬁnns 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 upphovsmannens 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/.

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 download, 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 be mentioned when 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/.

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 designed to enhance the public understanding of the network as well as highlighting the challenges 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, communication 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 identiﬁed and described as well. Acknowledgments

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

Thanks to Emil Axelsson for being our educational supervisor and supporting us with valuable 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 zones to help us out. Also great thanks to Micah Acinapura who introduced us to the project code and for his great patience whenever we needed his help. Thanks again, to all of you for making us feel welcome into the OpenSpace team.

We want to show our gratitude to Kevin Hussey at Jet Propulsion Laboratory who connected us to people with expertise about DSN. Special thanks to Shan Malhotra for his willingness to generate custom ﬁle formats with the necessary data for this project. This work 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 to Vivian Trakinski and Ro Kinzler who showed interest in our work and invited us to after work events. Also thanks to Camera Walrond-Joshua, Barbara Green and Eric Hamilton at AMNH 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 ...... 1 1.2 OpenSpace software ...... 2 1.3 Motivation and Aim ...... 2 1.4 Research questions ...... 2 1.5 Delimitations ...... 3

2 Related Work 4 2.1 Three-dimensional analysis of deep space network antenna coverage ...... 4 2.2 Deep Space Network Now ...... 5

3 Theory 6 3.1 Technical details of the Deep Space Network and Communication ...... 6 3.2 Precision issues while navigating in OpenSpace ...... 9 3.3 Date reference frames and celestial coordinate systems ...... 10 3.4 JPL data ...... 11 3.5 DSN Now XML data ...... 12

4 Visual representation 13 4.1 Spacecraft ...... 13 4.2 Ground stations and their coverage ...... 14 4.3 Radio wave communication ...... 14

5 Implementation 17 5.1 Preprocessing of raw data and Data formats ...... 17 5.2 Stations ...... 20 5.3 Spacecraft ...... 20 5.4 Radio wave communication ...... 22 5.5 Station ﬁeld of view ...... 24

6 Results 26 6.1 Visualization of the DSN stations ...... 26 6.2 Visualization of the spacecraft ...... 27 6.3 Visualization of the radio wave communication ...... 28

v 6.4 Ground station ﬁeld of view ...... 28

7 User test 31 7.1 Design and purpose ...... 31 7.2 Result ...... 31

8 Discussion and analysis 33 8.1 Results ...... 33 8.2 Implementation ...... 35 8.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 the communication complex sites and their individual stations. Above each station there are names of spacecraft that are in current communication. Animated radio waves indicate activity and goes in different directions. To the right more detailed information can be found about the spacecraft and the transmission...... 5

3.1 Illustration of the coverage of the communication complexes.The dotted line represents 30 000 kilometers from Earth. Outside of that radius the DSN stations coverage overlap, and there are nearly no blind spots left...... 7 3.2 Overview of the DSN spacecraft communication. The figure represents the flow of the 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 Ascension and 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 location and the spacecraft location. The line represents the transmission between the two. 15 4.2 Li’s represents lines where L1 is the ﬁrst one occurring followed by new lines as time 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 and future points in time...... 15 4.3 Concept of the visualization of a signal travelling through space from a dish towards a spacecraft or from a spacecraft towards a dish. P1 and P2 represent the start and end point of the transmission and the orange rectangles represent the signal...... 16

5.1 Sample of the positioning data. From top to bottom the values represent timestamp, 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 ﬂow chart. The numbers represent different scripts used on the different sets of data. The same sorting script, (1), was used to sort the raw CSV data both with hourly and minute precision. Script (2) combined the hourly and minute position data which was used in OpenSpace. Script (3) converted the raw CSV schedule to suitable JSON format. Script (4) added the light travel time from the positioning data into the transmission data which was used to visualize the signals in OpenSpace...... 19 5.3 Sample of the processed signal data. From top to bottom the values represent end time for the transmission, dish name, start time for the transmission, spacecraft name, 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 to the precision uncertainty caused by the vast distance between the camera and the label...... 22

vii 5.5 A scene graph node position is projected onto a view frustum plane at a static distance from the camera to determine the label position. The label size is scaled depending on the distance from the object...... 23 5.6 Signal line concept where a signal travels from position P1 to position P2 with velocity 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 is where the station is located...... 24

6.1 Four dishes from the Goldstone ground station. Two 34 meter dishes are transmitting signals...... 26 6.2 Close up of the Voyager spacecraft showing the 3D model from NASA. The red line indicates current incoming or outgoing signal communication from Canberra. 27 6.3 Spacecraft labels near Earth that fade in and out upon navigating towards and away from them. The dot in the lower left corner of each label indicates the spacecraft 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 cluttering on screen when many spacecraft are visible at the same time...... 28 6.5 Signals going from and towards all three ground stations, colored according to location. The pale orange clustered labels helps the readability around Mars. The grey labels represent individual spacecraft...... 29 6.6 Station ﬁeld 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 ground station location on Earth...... 29 6.7 Wire frame representation of the station ﬁeld 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 ground station location on Earth...... 30

viii List of Tables

3.1 Positioning data table. The ﬁrst two rows indicate how often there are data samples and 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...... 12 3.2 Transmission data table. The DSN Now XML data are snapshots that can be collected approximately every ﬁve seconds from DSN Now. Thus they do not have a set start and end time for the transmission by default, which the JPL schedule data 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 visualization has been incorporated. An introduction is also given to what the Deep Space Network is. An overall motivation with the aim to educate has been the driving force for this project. The challenges 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 these goals. This chapter also mentions some delimitations taken to narrow down the main focus of the work.

1.1 The Deep Space Network

Space missions have since their infancy been of great interest to the public, with the scien- tiﬁc 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 about frequently but the general public is usually not familiar with the system that supports these missions 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 heard of 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]. Since then 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 number of parabolic dish antennas, also called stations, that together support communication with over 50 spacecraft missions today. Throughout this report the terms "dish" and "station" are used when referring to the individual communication points on Earth, while "ground station" 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 which require extra specialized equipment and technology. Although there is more than one Deep Space Network, such as the Chinese Deep Space Network and Indian Deep Space Network, it should be noted that all mentions of Deep Space Network with the abbreviation DSN within this 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 representation of the known universe as well as a cooperative effort by Linköping University (LiU), American Museum of Natural History (AMNH), the Scientiﬁc Computing and Imag- ing Institute at the University of Utah, and New York University. With a foundation of data from NASA, the software uses advanced computer graphics to e.g render scientiﬁc representations of celestial bodies in the solar system with high resolution image data sets, volumetric space weather phenomena and space missions [6]. The software has the ability to run on multiple types of platforms such as desktops, dome theatres and touch displays. The fact that it is free to use and develop as open source further makes it more accessible than other similar softwares that are commercial [7]. OpenSpace is used at The American Museum of Natural history in New York that is the home of Hayden Planetarium, one of the world’s most renowned planetariums, which brings knowledge of space directly to an international audience. OpenSpace aims to continue to visualize the ongoing efforts of exploring the universe and 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 extensive work that DSN performs daily based on data from NASA. The challenge to create a representation of DSN that is intuitively understood in a 3D environment is something that has not previously been done. To show the complexity of the DSN in a comprehensible way for a layperson who may not have previous knowledge of the topic is also part of the motivation. This also ﬁts into the greater goal of OpenSpace as a way of showing NASA’s work to the general public. The main target group for this project are educators such as teachers or museum staff who wants to educate an audience using the OpenSpace software. This means the visualization should be easy to navigate, understand and explore for a user who is familiar to OpenSpace or similar software such as Uniview, but may not have much previous knowledge about the DSN. Also the visualization on its own should be intuitive enough to help an audience get a better understanding of communication in space and draw their own conclusions from the data visualized.

1.4 Research questions

To satisfy the overall aim the following research questions were formed that each targeted some 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 with the system could understand it?

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

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

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

2 1.5. Delimitations

1.5 Delimitations

Since the research questions have been the main goal of the project, some other things have not been a priority due to lack of time. The optimization and improvement of data handling have not been covered within the scope of this project. Some basic optimization such as binary 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 improve the data pipeline.

3 2 Related Work

To visualize different phenomena in space is what OpenSpace has been developed for. Since it is a scaled down version of the universe it offers unique opportunities for 3D visualization. Though a lot of effort has been put into scientiﬁc 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. was presented in 2012. It focused on the so called coverage gap of the DSN which was visualized in both 2D and 3D[11]. Another effort to portray the work that the DSN performs is Deep Space Network Now (DSN Now) which focuses on live streaming data from the stations. This is 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 conducted 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 what to consider regarding it for future missions. For more info about the DSN coverage, read section 3.1.1. This communication coverage gap was analyzed using NASA’s Integrated SCaN (Space Communication 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 various deep space altitudes. The simulations incorporated antenna parameters and uplink calculations. Since the focus on their work was to explore the coverage gap they used the azimuth/elevation terrain masks around the stations. This was important to get details about signal obstruction from the surrounding area for each antenna which potentially constrain the line of sight to spacecraft. Also, the SCaN model library and Satellite Tool Kit (STK) were used to develop the simulations. Since no current missions fall within the coverage gap most data was simulated and the case 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 as frequency bands, polarization and transmitting power were taken into consideration to give detailed 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 the coverage gap.

2.2 Deep Space Network Now

DSN Now is a public outreach project that aims to give more information about what work the DSN is currently performing. It is developed and maintained by people at Jet Propulsion Laboratory (JPL). DSN Now is a web page that presents live stream data every ﬁve seconds directly 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 in ﬁgure 2.1. The right hand panel shows the currently chosen dish and its transmission. It contains detailed numerical information about the current signal such as data rate, frequency and power, see section 3.1.3. Other numbers are also provided for the spacecraft such as range and round trip light time as well as azimuth (more information in section 3.3.2 ). and elevation of the dish, see section 3.3.2 for more information. JPL has generated their own data format 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 communication complex sites and their individual stations. Above each station there are names of spacecraft that are in current communication. Animated radio waves indicate activity and goes in different directions. To the right more detailed information can be found about the spacecraft and the transmission.

5 3 Theory

The challenge of visualizing the DSN requires some understanding of the different components of the network. In this chapter the different types of stations and their capabilities are described in greater detail. It also contains information about the spacecraft and the communication between them and the stations. To be able to follow the placement of these DSN components into OpenSpace the theory of celestial coordinate systems as well as OpenSpace speciﬁc precision issues have been included. Furthermore the types of data available are presented.

3.1 Technical details of the Deep Space Network and Communication

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

3.1.1 Stations The DSN Network communication complexes are located approximately 120 degrees apart on Earth, see Figure 3.1. This is essential to be able to provide a nearly continuous line of communication 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 fall within this gap [11]. Since all planets are near the ecliptic plane which does not fall within the coverage gap this has not posed a communication problem for any current or planned missions 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 view around 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 represents 30 000 kilometers from Earth. Outside of that radius the DSN stations coverage overlap, and there are nearly no blind spots left.

The DSN station antennas have different sizes and are designed to solve different problems. 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 these are not included as part of the DSN. The height of each DSN station is that it is almost as high as its dish diameter [9]. The 34 meter dishes replaced the previous 26 meter antennas and the 70 meter in diameter dish replaced the earlier 60 meter dishes [14]. There are two different types of 34 meter dish antennas and those are High Efﬁciency (HEF) and Beam Wave Guide (BWG) antennas. Each communication complex has one 70 meter station and multiple 34 meter stations [16]. The same station antennas are used for both uplink data commands (transmission from station to spacecraft) and receiving downlink data (transmission from 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 number of spacecraft they can communicate with at the same time some priorities have to be made. The large 70 meter dishes have larger beamwidths, i.e. a larger angle in the radio antenna 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 pinpoint and improve signal communication to very far away spacecraft. However the smaller 34 meter dishes can work synchronously with each other to mimic the functionality of a larger antenna. They can also work together with a 70 meter antenna to extend the functionality of both of them. This functionality is called arraying [16] and it is not a standard service, but a capability 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 downlink data to the same station, providing that they are both within the reach of the beamwidth of station. This capability is especially useful when there are scheduling conﬂicts. At popular research locations such as Mars it is not unusual that multiple spacecraft are within the same station beamwidth. For this particular functionality it requires the DSN station to have multiple 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 are consistent with the station capabilities. Currently only one uplink signal can be transmitted at a time, but sometimes the scheduled time will be split among multiple spacecraft to allow sequential uplink communication [16].

3.1.2 Spacecraft "Spacecraft" in this work refers to all spacecraft using the DSN for support. This includes many different types of machines, for example space probes, orbiting satellites, landers and more. Today, there are too many active spacecraft to support transmission from all of them at the same time with the current DSN. While most spacecrafts are on specialized missions to collect different scientiﬁc data this is not the only type of data that is transmitted. For example certain missions also work together with others as relay support. That means one spacecraft communicates with another spacecraft that in turn transmits to a DSN station. This is 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 planet even 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 all spacecraft, but instead a schedule is made based on the current relevance and interest of a mission 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 communication with missions developed by other space agencies. Hayabusa 2 by the Japanese space agency (JAXA) and Mars Orbiter Mission by Indian Space Research Organization (ISRO) are examples of such missions. The range of missions are constantly changing as new missions are planned and launched and older ones are decommissioned or lost. Further information about how many spacecraft are operating can be found in section 6.2. The most distant spacecraft that are part of the Deep Space Network are Voyager 1 and 2 that were launched in 1977. They are nearly 20 light hours away and are outbound from our solar system. Some spacecrafts communicating through the DSN are still in their planning phase and therefore have not yet left earth. To test the instruments there are communications scheduled 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 is working as expected before launch. Apart from mission speciﬁc instruments the spacecraft are all equipped with radio transmitters 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 signal sent from the spacecraft down to a station. Both types of communication are transmitted as radio waves that travel at the speed of light. The radio waves have different frequencies to not interfere with other communication and minimize noise. Uplink communication consists of 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 data that could be radio science, Very-long-baseline interferometry (VLBI), Radio Astronomy and more. One example of science data is the ﬁltered out noise in the downlink data caused by radioactivity in space. This means the downlink acquires information about radio active phenomena on its way down to Earth. However this also means that many outer disturbances can corrupt the data on its way. To handle that issue NASA has developed encoding and decoding 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 each other. Radio waves are hard to receive across great distances because as they propagate the signal power becomes weaker. NASA and JPL have made large improvements with the technology of the DSN stations for them to be able to pick up on extremely weak signals. NASA also use ampliﬁers both on the receiving and transmitting end. Through exact tracking and calculations NASA can pinpoint the transmissions for the signal power to be as concentrated as possible [14]. To communicate in these extreme circumstances requires, as previously mentioned, very exact navigation. This is also a challenge in OpenSpace where positioning should be as accurate as possible.

Figure 3.2: Overview of the DSN spacecraft communication. The ﬁgure represents the ﬂow of 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 universe as described in section 1.2. The navigation focus in OpenSpace can be set by picking a focus node that the rendering camera will have at the center of its view. Using the zoom function in that mode will make the user navigate towards the scene graph node and is a common 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 the axis. Dealing with scaling in such a large environment leads to certain problems that do not usually occur in smaller coordinate systems. One common issue is that ﬂoating point precision is not enough to express the world position of the scene graph nodes in OpenSpace with accuracy. While double precision values may help solve some problems arising, it leads to worse performance. The phenomena is described further by Axelsson et al. [4] who state that translation causes the most serious problem known as catastrophic cancellation, while scaling and rotation do not pose those issues. These defects are more noticeable the closer the camera 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 proportional to the distance of the vertex in view space. This makes precision issue handling a continuous challenge while developing the OpenSpace software. In particular this has to be taken into consideration 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 universe is constantly moving. To describe a position, a fixed point of reference is needed. There are different ways of setting reference points in space. It is common that celestial coordinate systems are defined relative to the vernal equinox, see figure 3.3. However, the vernal equinox is in itself not constant and because of that, the vernal equinox of a certain date is used as a reference. Today it is common to use J2000, which refers to January first, the year 2000 at 12AM 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 coordinates. For spherical coordinates there are different systems that define the fundamental plane from which the angles are measured. The equatorial system uses Earth as center and has its fundamental plane defined as the infinite projection of Earth’s equator. The ecliptic system has the ecliptic plane (Earth’s orbit) as its fundamental plane and galactic uses the approximate plane of the galaxy as reference with the solar system as origin. Figure 3.3 gives a further explanation as to how the celestial coordinates work. Below is information about two of the most commonly used celestial coordinate systems [10].

Figure 3.3: The celestial equator and the vernal equinox is used to express Right Ascension and Declination. The gray circle represents Earth. Right Ascension and Declination is represented by the colored ﬁelds 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 longitude are used to map Earth. Instead of Earth, right ascension and declination are based on the celestial sphere, also called equatorial sphere since it uses the fundamental plane of the equatorial system. The celestial sphere is an imaginary sphere with inﬁnite radius and Earth center as its center. The celestial equator is aligned to Earth’s equator and used as a reference point for measuring declination. Declination is used to describe the elevation above the celestial equator and is measured in degrees. The reference point for right ascension is the Vernal Equinox 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 celestial bodies and spacecraft. Instead of using Earth center as the origin, azimuth and elevation are measured from the current position of the viewer and are both angles. This means that the Horizontal coordinate system is ﬁxed to the viewers position and not the stars. There- fore the coordinates of a celestial body varies depending on where the viewer is located. The coordinates 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 perpendicular to the viewers horizon. Usually true north is used as a zero point. Elevation angle is used to describe the altitude of the celestial body with the observer’s horizon as a reference point [10].

3.4 JPL data

There are several types of data available from JPL. Some data sets are publicly available and some 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 some spacecrafts and latitude and longitude data for positioning the stations. The data generated specifically for this project is the CSV positioning data and the scheduled files describing the DSN communication. SPICE data, is provided by the NASA ancillary Information Facility (NAIF), and is publicly available for anyone to use for free. SPICE data is collected from spacecraft, mission control center, spacecraft instrument builders and scientists. The data describes trajectories, location, orientation and more both for various spacecraft and known celestial bodies. SPICE data is often referred to as SPICE kernels. The Kernels describing the position of these spacecraft 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 the form of latitude and longitude [9]. There are also 3D models of some of the different spacecraft, planets, instruments publicly available from NASA. Data describing the positions of the spacecraft have been specifically generated for this project in CSV format. The data contains the information shown in table 3.1. This CSV data comes in two data sets. One set that is sampled every minute within the transmission windows. 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 ground stations and the downleg data describes the position of the spacecraft at the time the signals left the spacecraft, relative to Earth at the specific time. The data is separated per spacecraft and has information from January 2014 to January 2019. The data is sampled every minute during the windows of transmission, i.e when there are transmissions, and every hour continuously for the rest of the time frame. Another type of data specifically generated for this project is the schedule files of NASA’s communication. It shows when all spacecraft are scheduled to transmit, to which station and for how long. There is also information about what type of transmission is scheduled. The available data has information about January 2014 to January 2019. The data is separated into weeks and not split up per spacecraft. There is no parameter describing if the signal is an uplink or a downlink, i.e if the signal is going towards the spacecraft or towards the station on Earth, as described in section 3.1.3. However, a list of instrument used for the communication has been included. Depending on which instruments has been used for the transmission, it is possible to determine if the signal is an uplink or a downlink as the instruments used for an uplink 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/hour Position for transmitting spacecraft 1/5sec 1/minute Light travel time roundtrip upleg, downleg and roundtrip Azimuth/Elevation yes, up- and downleg unspeciﬁed upleg and downleg Ra/Dec - upleg and downleg Doppler - one-way and two-way

Table 3.1: Positioning data table. The ﬁrst two rows indicate how often there are data samples and 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 - yes Frequency, 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 collected approximately every ﬁve seconds from DSN Now. Thus they do not have a set start and end time for the transmission by default, which the JPL schedule data has.

different work categories (workcat). Workcat identiﬁes the type of track it is. According to JPL staff, one would typically want 1A1 for visualizing the actual activity since this indicates an operational track. Other codes are tests, training sessions or some other science related activities.

3.5 DSN Now XML data

The data used by the DSN Now web page is in an XML format. It has information both about 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, power and more. The data does not contain information about right ascension and declination for the spacecraft. However, it does contain information about range as well as the azimuth and 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 the spacecraft but rather an estimation of where it was when it sent the downlink or where it is going to be when it receives an uplink. Depending on the velocity of the spacecraft and its distance from Earth this positional difference can be quite large. Unlike the data generated by JPL, the DSN Now data only contain information about the spacecraft that are actually in communication at a given time, sampled every ﬁve second. The structure of this data means that there is no way of knowing for how long a spacecraft is going 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 contain different types of data. In this chapter the different ways of representing the visual components of the system are described. The options were considered with the aim of answering the research questions in section 1.4. The considered alternatives of visualizing spacecraft have put extra demands on the data used to position them. While labels are deemed useful for spacecraft, they are less useful for the stations where representative colors have played a large role which also connects to representing their coverage. To properly visualize the radio wave 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 3D position to be an end point of the communication lines, another to be a visible node one can navigate to in OpenSpace, and third to show the connections of the work the DSN performs with an overview representation. The visual representation as an end point of communication is described in the section 4.3. To visually represent the node one can use a 3D model which is a common way of representation in OpenSpace. The overview representation is a bit more difficult. Since it is not intuitive which spacecraft are part of DSN there is need to show this. OpenSpace has a GUI that can list scene graph nodes. To keep the universal view clean one method could be to only show the fleet as a whole in the GUI and use the navigation within OpenSpace to get a closer look on the scene graph node. However this would make it difficult to determine where the communication is travelling to and from. Thus labels were considered since they have been used before in OpenSpace, for example when visualizing stars. This meant that spacecraft could be visible even from very far distances since a label does not have to follow world proportions the same way a 3D model would. However, with the spacecraft always visible there were potential issues with the different data sets used for positioning. The XML data only contained the spacecraft positioning during the transmission windows, described in chapter 3. This meant that certain spacecraft would not get their position updated for long periods of time because they do not have evenly 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 conﬂict with the goal of showing the extensiveness of the network. To be able to show this accurately, there was a need to get updated positioning even outside of the transmission windows, which was possible through the CSV positioning data from JPL. While the goal of showing all spacecraft at all times was an ambition, this meant a method of handling label 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 positioning one should be able to see the huge dishes from the detailed Earth texture that was already implemented with the globe browsing feature by Bladin et. al [5]. However there are 3D models of the different NASA dishes available online. Because of the nature of OpenSpace as a scaled down version of the universe there was an idea that the visual representation of the nodes would also have a 3D model. Ideally these models would be scaled to world proportions. Ideally the model would also come in parts which could hypothetically be animated based on data. Moreover, there was also a need to connect the stations to the signals. In contrast to the spacecraft, labels are less useful for this case. Mainly because they would easily clutter since all stations are placed on Earth. One option would be to have labels on the ground, but similar to the 3D models, these would only be visible once navigated close to the node. From an overview from space it would not be suitable to use labels. This is where a decision to use colors representing the different locations on Earth became an option. By coloring the radio wave communication lines according to where on Earth the transmission is one can determine where the communication is from by association. The disadvantage with this method is that too 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 ﬁeld of view with cones. To connect them to each ground station location the ﬁeld of views would be colored the same way as the signals. Though this would not be as exact as using an actual terrain mask, as described in the section [11] it would convey the concept of their vast coverage. Because the size of the coverage would they would easily become the focus of the visualization, while the intention is for it to be a helping tool to understand the transmission coverage. To combat this it was decided that this part would not be activated by 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 considered. The ﬁrst was a, fully colored line going from spacecraft to station, only active during the transmission window and not showing any travelling through space, see ﬁgure 4.1. This solution was similar to DSN Now, see section 2, since it shows the current activity of the ground stations. Though this is a great way of indicating the current activity on Earth it does not show how far it will take the signals to reach that spacecraft, or that incoming signals to DSN often have been sent hours before arriving. In short, it would be a point-to-point visualization of the current activity of the ground station, with a possibility to visually indicate uplink or downlink with an effect. However this would create a bigger demand on the effect to be clearly discernible since the lines of both uplink and downlink would both be fully drawn from spacecraft to station. The advantage of using this visual representation is that it only requires the position of the spacecraft during the transmission window, and that could be 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 would be where the spacecraft is located currently according to time in OpenSpace or whether it would be the position of it when the transmission is sent or received. Communication on Earth where the speed of light means almost instantaneous communication does not pose this problem which have to be considered here.

Figure 4.1: Point to point communication visualization. P1 and P2 represent the dish location and 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 particular timestamp. A short colored segment of a line would be drawn from that particular point in time, travelling at the speed of light and aimed towards the position where the spacecraft or station will be after the signal has travelled through space, as seen to the left in ﬁgure 4.2. Slightly later a new short segment would travel from a slightly different start and end position, while the previous segment continues its course from the previous positions, see the center and right part of ﬁgure 4.2. This method would be more similar to the actual physics of photons that occur since it considers that everything is in constant motion, but it would also require further considerations in estimating where the end point will be positioned in the light travel time compensated future. Thus to simply position the spacecraft during the transmissions would not be enough. This would require more focus on the data handling and storage of line end points at runtime.

Figure 4.2: Li’s represents lines where L1 is the ﬁrst one occurring followed by new lines as time 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 and future points in time.

With these methods there is also a challenge of showing what direction the signals are travelling, i.e. whether they are uplink or downlink. Even with the methods that use segments travelling at the speed of light this is a challenge for the outer space signals because of the immense distance. A ﬂow effect is a good way of making this more clear. Another challenge was overlapping communication lines. The cases with MSPA, described 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. One such method could be to have a different color indicator or to curve the lines so they do not overlap. The third visualization method is a compromise between the previous two. Similar to the more physically accurate method it requires spacecraft positioning outside of the transmis-

15 4.3. Radio wave communication sion windows. However it only keeps track of one start point and one end point for each transmission in memory, so it is not as computationally and implementation heavy as the more physically accurate one. The idea is to retrieve the start and end position of the transmission line from the OpenSpace scene graph nodes. Similar to the previously described method it will send out segments in succession, but instead of keeping the start and end position in memory for that particular moment in time, it keeps track of how far the signal has supposedly travelled since the beginning of the transmission. The difference in position between the more physically accurate version will be visually minuscule from an overview where the difference in distance that the end points will move will be insigniﬁcant compared to the distance light travels in that time. Thus the line would appear almost straight. If looking at the transmission course in detail the physically accurate method would not have its segments in a straight line, however this latest described method would, as seen in Figure 4.3.

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

How these different visual representations were implemented is described in greater detail in the next chapter.

16 5 Implementation

The implementation of the NASA deep space network visualization is described in this chapter. Throughout our contact with JPL staff some data samples were given that originally contained data sampled every minute. However this was later changed due to the effort and time to generate this data for the whole ﬂeet. A compromise was made where continuous data was sampled once every hour and the transmission windows contained samples every minute. Since the different data sets contain different information a decision to focus on the JPL data instead of the XML data was made. The reason for this was that it would convey more information to look at the history of the communication, while the XML data was more suitable for a live mode. The JPL data contained more essential information regarding the transmission which are the start and end time as well as uplink and downlink, while also having positioning for spacecraft at all times. Though the light travel time was not originally in the transmission schedule, it could be added from the position data. This chapter describes the preprocessing of that data and what data format this resulted in and what it was used for. There are also a description of the chosen implementations that were discussed in chapter 4. This includes the ground stations, the individual spacecraft and the radio waves representing the signal transmission. The last part is the station ﬁeld of views, 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 to a certain format. OpenSpace has its own time handling that keeps track of the current time in the software timeline. This time can be used to decide what data is relevant for the current time frame. There were two types of original data that was obtained through contacts at JPL and those are CSV positioning data and scheduled communication, see section 3.4. The positioning data was originally only separated per spacecraft. Since looping through all files and objects to find a matching time is not an option performance wise both data sets were preprocessed using Python scripts. The first Python script was used to create a desired JSON format designed to be read into OpenSpace. The sample files was sorted by time and initially the Python script was designed with this in mind. The files were sampled every minute 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, however for such tightly sampled data this was not considered an issue because the gaps in data were not big enough to be visible in the visualization. The next problem discovered was that some files, often but not exclusively the same ones that included an error, contained duplicated data or partially unsorted data. This lead to errors later on since the scripts worked on the premise that the data was sorted. Thus another script was created that first sorted the raw data and got rid of duplicate data. The mentioned errors as well as unsorted and duplicate data were never found in the hourly sampled data, however the sorting scripts were also run on 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 from disk, the CSV positioning data got separated into smaller JSON files. Only the data needed to position the spacecraft got transferred to the processed data formats, making the new data files smaller than the old ones. Also the files were renamed with a timestamp which can be used to determine where the data is located by comparison with the filename rather than having 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. The positioning data is separated per spacecraft and hour. Each file contains a timestamp, right ascension, declination, range and light travel time for the spacecraft. The data files are named as 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 timestamp, right ascension measured in degrees, declination measured in degrees, range measured in kilometers and light travel time measured in seconds.

The original scheduled communication data had information about all spacecraft in the same 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 because 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 the system at all times. The light travel time information is a part of the positioning data but originally not part of the scheduled communication. However while working on the Voyager signals with very long light travel time it became apparent that it was necessary to include it in order to visualize the uplink and downlink transmissions travelling through space. In order to add the light travel time to the scheduled communication, each signal was compared to the closest timestamp for the particular spacecraft in the positioning data and the light travel time was copied from that file to the scheduled communication data. To see the workflow of the preprocessing, see figure 5.2.

18 5.1. Preprocessing of raw data and Data formats

Figure 5.2: Preprocessing work ﬂow chart. The numbers represent different scripts used on the different sets of data. The same sorting script, (1), was used to sort the raw CSV data both with hourly and minute precision. Script (2) combined the hourly and minute position data which was used in OpenSpace. Script (3) converted the raw CSV schedule to suitable JSON format. Script (4) added the light travel time from the positioning data into the transmission data 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 mostly been sampled every hour, while others with lots of transmission time have been sampled every minute for long times. On average the processed data is approximately 200 MB, compared 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 most three of the smaller data files per spacecraft are kept in memory at the same time. There are almost 70 spacecrafts part of this visualization which means in total, if all spacecrafts are active 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 has information about all transmissions scheduled on the DSN, separated per day. The data contains the start time of the transmission, the name of the station used to communicate, the end time of the transmission, the name of the spacecraft, the direction of the signal and the light travel time from Earth to the relevant spacecraft. This is shown in figure 5.3. The data files are named as the timestamp, with a daily precision. The total size of the processed scheduled transmission data is approximately 16 MB compared to the original data which is approximately 22 MB. The smaller data files separated per day however are only around 10 KB. The position data from three of these smaller files are kept in memory at all time. There was some error handling and warnings implemented in OpenSpace for the parsing of JSON data. Invalid JSON objects are logged and can be traced to the file where the error occurs. However there are no checks for validating that the data are within correct value ranges.

19 5.2. Stations

Figure 5.3: Sample of the processed signal data. From top to bottom the values represent end 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 each communication complex. The longitude and latitude data that was found in documentation from JPL by Folkner et al. [9] was not available from the start. Because of that, the initial placement of the stations were quite rough. By using the publicly available latitude and longitude data from JPL described in section 3.4 the placement became precise. The functionality to place scene graph nodes on Earth using latitude and longitude was already a part of OpenSpace since a globe browsing feature was implemented by Bladin et al [5]. All of the DSN stations have been placed using this functionality. In order to visually represent the stations on Earth, the publicly available 3D models mentioned in section 3.4, have been used. Two different models for the 70 meter antennas and 34 meter antennas have been used since the models were already scaled properly and OpenSpace has a coordinate system in meters. When the stations are positioned, they are rotated to stand perpendicular to the Earth surface, 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 to rotate the models around their axes within their local coordinate system. This feature was used to ﬁnd 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 that handled the data that was available to us. As mentioned in section 5.2 the initial placement of the stations were not exact. Thus a decision to use right ascension and declination instead of 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 the individual spacecraft visually as well as the complete ﬂeet of spacecraft.

5.3.1 Spacecraft positioning To position all of the spacecraft nodes in OpenSpace two different methods were used. A few spacecraft had SPICE data available for the relevant time frame of this visualization. For those spacecraft, an already existing function in OpenSpace was used for positioning using that data. However, most of the spacecraft did not have any continuous SPICE data available for longer time periods. For these spacecraft, right ascension and declination from preprocessed positioning data have been used, see section 3.4. Functionality to position scene graph nodes with information about right ascension, declination and range from Earth center have been implemented for this project as follows. The data files are sorted and named after the relevant timestamp as described in section 5.1, and those timestamps are stored in a vector upon application start. This method to name and choose files from disk named by dates was described by Carlbaum and Novén [8]. An upper bound binary search is used to match the current time in OpenSpace to the closest timestamp from that vector. Another binary search matched the current time in OpenSpace to the closest timestamp within that data file. In order to accurately create the positioning the light travel time had to be taken into consideration. The light travel time is subtracted from the current time and used to retrieve the light travel compensated data file. When the correct data file is found a chunk of data with all positions for the previous, current and next hour are loaded into OpenSpace. Since the file parsing is slow the previous and next hour are included so that the data is preloaded no matter if the time in OpenSpace move backwards or forwards. Thus the data for an active spacecraft will contain between three and 180 positions depending 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 Earth relative Cartesian coordinates got rotated to match the equatorial sphere, already a part of OpenSpace, 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 fashion as for the stations. However there was a problem that not all spacecraft had a 3D model publicly available. Since the ﬂeet consisted of a lot of spacecraft the option would either be to omit models or using dummy models since there was not enough time to custom make all. The choice was to omit models, thus only a few of the spacecraft has a 3D model close up representation. However, even by using a 3D model of the spacecraft it is not enough to represent the spacecraft from an overview perspective of the DSN. The solution to this was to 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 render labels was implemented. The labels were created in part by using an already implemented font renderer in OpenSpace. This font renderer kept track of transformations and made sure the labels would be oriented correctly as camera-facing billboards. The label was attached to a scene graph node by using its world position. Using the world position of the objects causes issues with precision, described in section 3.2 and an example can be seen in ﬁgure 5.4. Instead of using the actual world position for the labels, a set distance from the camera was used to place the font billboard in 3D space. This

21 5.4. Radio wave communication made it possible to place the font further away from the camera than the object is, technically never moving closer to the font position. This meant the precision problems would not cause catastrophic 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 approaching was lost. To make a visual impression of approaching the object, the label size was given a maximum size and a minimum size. It also was given two distances, a maximum and a minimum, between which the current distance between the camera and the object was normalized to a font size in the deﬁned interval. This concept is illustrated in Figure 5.5. The labels solved the spacecraft visibility problem, but brought new issues. The huge number of spacecraft and the size of each label meant that the view of the solar system became cluttered. When the camera is close to Earth, with its frustum facing out in space in different directions, most spacecraft will be spread out in the solar system at screen space. This view allows visibility of most labels. However, moving away from Earth while the camera view is rotated towards it quickly puts most labels at the same screen space point. This means all labels closer to Earth are stacked on top of each other. A solution to this was to separate the labels into groups depending on how far they are from Earth and using different distances from 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 taken place. For example the case with the Mars missions. When rendering individual labels for each of these spacecraft some labels inevitably end up on top of each other, making them hard to read. To avoid this, an additional label, referred to as a cluster label, is created and attached to a common node, for example Mars. The fade in and fade out distances are tweaked together with the individual labels for the spacecraft. When the camera gets closer to those labels 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 very far from each other it was difﬁcult to see exactly which spacecraft the communication was going to or where exactly it was positioned relative to the label. Another design feature was added by adding a dot in the lower left corner of the label. An offset was added to the font rendered on the billboard to make sure the communication line would always go through the dot. 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 to the 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 radio waves, travelling through space. The visual result that was the goal of the implementation was the last representation mentioned in chapter 4.3 and seen in ﬁgure 4.3. The signals are

22 5.4. Radio wave communication

Figure 5.5: A scene graph node position is projected onto a view frustum plane at a static distance from the camera to determine the label position. The label size is scaled depending on 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 the different stations instead of starting at the station origin. This was done by calculating the vector outgoing from Earth towards the station, then translating by the height of the station in that direction. The lines are given different colors depending on which ground station is sending or receiving the signal. Precision uncertainties, described in section 3.2 occurred when using the world positions of the station and spacecraft nodes. This resulted in flickering lines. This problem became more apparent the closer one navigated to the end points. To combat this issue the OpenSpace focus node is used by using a translation matrix that is made at runtime with its current world position. The world positions of the station and spacecraft are expressed relative to the world position of the focus node. This means that if a station is chosen as focus node, the x, y and z coordinates 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. The translation matrix is multiplied with the view matrix of the camera before the other calculations are made on the shader. Since multiplication with the view matrix expresses the world being rendered relative to the camera, a translation subtraction is made with double precision. The large precision prone numbers, i.e. world positions, were eliminated before the shader calculations are performed. Thus the shader can compute the rendering on smaller numbers using floating precision while maintaining high accuracy. Information about for how long time the transmission line is going to be visible is taken into account. The beginning of track (BOT) and end of track (EOT) from the processed scheduled 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 consideration to extend the active time frame in the direction that the signal is active. If the transmission is two-way two signals are handled independently, one for uplink and one downlink. To visualize the signal transmission travelling through space a cutoff was made at transmission start and transmission end, where the rest of the line had zero opacity, see Figure 5.6. The visible part of the line is moving with the speed of light, until the end of the signal had reached its end destination. To determine what signals to render at any given time in OpenSpace, the correct data file is found through a binary search. When the relevant file is found, all signals from that file was compared to the current time in OpenSpace. If the current time was in between the light travel time adjusted BOT and EOT the transmission would still be active and the signal would be rendered. To be able to handle signals transmitting over midnight and to be able to handle spacecraft with a long light travel time, a buffer is used. Since the longest light travel time is approx-

23 5.5. Station ﬁeld of view

Figure 5.6: Signal line concept where a signal travels from position P1 to position P2 with velocity 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 file before the current time is needed as a buffer since no signal would ever be active out of that time frames. To visually represent if the signals were travelling towards the spacecraft or towards the dishes, a flow speed effect, is implemented on the fragment shader. These have a set speed that by default is set to the speed of light, see figure 5.6, but can be changed to travel faster to indicate uplink and downlink.

5.5 Station ﬁeld of view

To convey the coverage of the DSN described in section 3.1.1, a class for the station field of view (FOV) was implemented. Before that, a cone class was created. This was the base class of the station FOV. The station FOV was then customized to attach its cone apex to an OpenSpace 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 the three 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 wave signal transmissions for the respective locations.

Figure 5.7: Station ﬁeld of view is represented by the cone in this ﬁgure. The tip of the cone is where the station is located.

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

24 5.5. Station ﬁeld of view comes with great distance. The height or length of the cone was preset to a value that is best viewed from an overview of the solar system. No particular formulae were implemented for this since it is not based on data, but merely strives to deliver the concept for a better understanding. The fading was made using the default linear interpolation of the fragment shader. The precision problems were handled in the same way as for the radio waves, see section 5.4.

25 6 Results

The final result of this project is an interactive visualization of the NASA deep space network implemented as a part of the OpenSpace software. The visualization consists of labels and 3D models to represent spacecraft, 3D models to represent communication complexes on Earth, line segments to represent the radio wave communication and cones to visualize the station field 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 transmitting signals.

6.1 Visualization of the DSN stations

There are 15 stations, split up into three ground stations part of the DSN and represented in this visualization. Each station has been represented with a real world scaled 3D model as can be seen in Figure 6.1. The ﬁgure shows two of the stations transmitting and different models 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. These spacecraft 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 capabilities to communicate with DSN, but some are not in use because the transmissions are not funded anymore. A few Earth orbiters are also using DSN for communication, and these have been included as well. Those that have been omitted from the schedule are certain spacecraft with another configuration code than 1A1, see section 3.4. Only 1A1 was the actual scheduled transmission according to JPL staff. This matched the observations regarding the data, for example James Webb Telescope was included in the data but had a different code than 1A1 and is yet to be launched. All spacecraft are represented with a label, see Figure 6.2, and some spacecraft are represented with a 3D model as well. The 3D model is only visible when the camera is close to the spacecraft 6.3. Since the labels occupy a lot of screen space, small dots in front of the labels are used to represent a more precise position of the spacecraft. The spacecraft are divided into groups, those near Earth, those in the inner part of the solar system, those in the outer part of the solar system and those that have left the solar system. The distance from the camera to the group of spacecraft is used to decide if the group of labels should be visible or not. As the camera moves away from its original position near Earth, the labels 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 brings down 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. This is an improvement from the linear case of looping, however the biggest performance save is made by being able to do this on the filename without having to open a file and parse the data inside to be able to determine if the time is correct.

Figure 6.2: Close up of the Voyager space- Figure 6.3: Spacecraft labels near Earth craft showing the 3D model from NASA. that fade in and out upon navigating to- The red line indicates current incoming wards and away from them. The dot in or outgoing signal communication from the lower left corner of each label indi- Canberra. cates the spacecraft position.

The case with cluster labels were used for multiple cases, such as for Lunar missions and Mars missions including the voyage of InSight, MarCOA and MarCOB from Earth. A cluster label 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 screen when 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, as described in section 5.4. Its length would be the light travel time multiplied with the time the transmission is being sent, thus a three hour transmission will show up as a shorter line segment than a ﬁve hour transmission. The signals are travelling with the speed of light, towards the spacecraft if the transmission is an uplink and towards the stations if the transmission is a downlink. In order to visualize how far away the transmissions are going or coming from, the transmissions lines have been split up into smaller segments. The greater the distance from the station to the spacecraft, the bigger the segments. This makes it possible to approximately tell the distance to a spacecraft even if the spacecraft is not in view. In order to further clarify the direction of the transmission, these smaller segments are moving within the transmission lines. 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 been visualized with different colors. Blue for communication with the Goldstone ground station, red for Canberra and green for Madrid. Communication with all three ground stations are shown in Figure 6.5.

6.4 Ground station ﬁeld of view

The ground FOVs are simulated as three cones colored the same way as the signals, blue for Goldstone, red for Canberra and green for Madrid. They are not activated by default but can be activated by shortcut commands. The width of the cone bases are set so that the station FOVs are approximately ten degrees above the surface in all directions which serve an illustrative purpose. To simulate the decay of the signal strength that occurs with great distances, the cone opacity have been faded out with distance. The station FOV for all communication complexes are shown in ﬁgure 6.6. From some angles, it is hard to tell the shape of the ground station FOV. To improve this a wire frame representation is also available. The wire frame representation of the station FOVs is shown in Figure 6.7.

28 6.4. Ground station ﬁeld of view

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

Figure 6.6: Station ﬁeld 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 ground station location on Earth.

29 6.4. Ground station ﬁeld of view

Figure 6.7: Wire frame representation of the station ﬁeld 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 ground station location on Earth.

30 7 User test

User tests were performed on two people who had a good basic understanding about space and inter planetary communication. They had limited experience with OpenSpace, but were familiar 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 test leader. Notes about the users’ actions were taken by the secretary. The user’s answers to the questions were also written down as well as basic information such as age, occupation and previous experience with similar software. The ﬁrst phase of the user test was designed to evaluate how intuitive the visualization is. The user was asked to freely navigate and explore the visualization and at the same time think out loud and describe what was seen. Everything was written down, both the questions and comments provided by the user and the actions that was taken by the user to navigate around the visualization. The second phase was designed to get feedback on things that did not get mentioned in the ﬁrst phase. Here the user got to answer questions about the visualization while still navigating through it. The questions were designed to test if the user would navigate through the 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. The meaning of the lines travelling through space was clear to both test persons as well as what the different colors represented. The visualization made the test persons think about how slow the speed of light looked in relation to the distance between Earth and Voyager and through that how big the universe is compared to Earth. One thing that caused some confusion was the orientation of the station ﬁeld of view cones. One test person suggested that they should be shaded on the inside to help clarify the direction of the ﬁeld of view. Another improvement suggestion was to shade the parts of space that got lit up by it instead of rendering cones.

31 7.2. Result

Another minor deﬁciency of the visualization was the fact that none of the test persons used the dashboard in the top left corner. When confronted with this after the test, they both said 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 spacecrafts and the station at the same time. The two lines rendered on top of each other made it hard to tell which direction the ﬂow particles were going. Both of the test persons mentioned this as an issue that could be improved.

32 8 Discussion and analysis

In this section the result and implementation of the visualization will be evaluated. What turned out as planned and what did not turn out as planned? What could have been done better and which difﬁculties 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 also arranged at AMNH where further feedback was given from the audience. All people testing and giving feedback have been working at AMNH or are using UniView for educational purposes. Thus their understanding and interest of the system may be higher than the average museum visitor, however most were not familiar with DSN before. The main purpose of this visualization was to increase the knowledge and understanding of how the DSN works. The user tests showed that the visualization did just that. It clariﬁed, and gave the user a basic understanding of how the different ground stations complement each other. The extensiveness of the DSN was visualized through the large number of spacecrafts being seen at the same time, as well as the coloring of the signals, telling the viewer what part of DSN was responsible for the transmission. The visualization of signals travelling through space even after transmission stopped on Earth gave further understanding of the vastness of space and the challenge of communicating in it. The user test showed that it was a great way to create a visual understanding of the network. The stations on Earth were represented as 3D models and the actual radio waves travelling through space were represented as line segments. The user test, as well as presentation showed that everybody understood what the different stations on Earth represented and how they were used to send radio waves through space. The users understood that the transmission 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 that she thought it could be related to the frequency or wavelength of the signal. This is most likely 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 amount of data being transmitted. The segments were initially an implementation to make the direction 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 a spacing. 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 near Earth were introduced. First it became apparent that the segments were too big, so the light travel time was included in the shader and used as a factor to rescale the segments. The next thing was that for the near Earth case that the flow effect of the segments travelled faster than the signal transmission. For cases where the light travel time was shorter than the transmission time this meant that it looked like the radio wave transmission travelled faster than the speed of light. This physical impossibility might go unnoticed by a user who simply would underestimate the light travel time distance to the spacecrafts instead. Thus the segments were changed to travel at the speed of light by default, but keeping a property controlling the speed of the effect. This proved useful to be able to differentiate between uplink and downlink for the Voyagers in real time. The implementation of station FOVs aims to give an understanding of the immense areas that are covered by each individual ground station and why the network would not bee complete without all three of them. It was clear to the test subjects what this meant, however it was sometimes hard to tell the direction these FOVs are pointing. The station FOVs also gave a better understanding of how the DSN works and how the ground stations complement each other. It was possible in some cases to see the line segments, representing the radio waves, 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 away some 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 radio waves, travelling with the speed of light, looked almost frozen in the zoomed out view of the solar 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 representation of communication going both towards the spacecraft and towards the station at the same time, i.e a two-way communication. It was represented by two signals going over each other in different direction which resulted in one line, pretty much without flow particle representation. An adjustment was made that enlarged the spacing between the segments, but this could be improved in many other ways, either fairly easily by representing it with a different pattern or color. It could also be improved, by changing the representation of the communication completely from a line to a wave pattern. This potentially would make it easier to distinguish if there are two lines on top of each other. Although this visualization illustrates some of the major challenges of creating the DSN, many of the challenges NASA faces 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 view to 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 that the radio waves used to transmit are very strong and actually dangerous to humans. Because of this, NASA has to clear the air space before transmitting. All of these difficulties are a part of 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 windows of transmission and every hour continuously. The movements of the spacecrafts are very smooth during transmission, i.e when there is minute data available. However when there is only hourly data available, the spacecraft movement becomes jagged as a result of only being updated once per hour. For the spacecrafts far away, it is not very noticeable. For the spacecrafts orbiting a planet however, the hourly data is not sufficient. As a result of the sparse sampling of positioning data and the fast movements of the spacecrafts around the planet it is very hard to tell that the spacecrafts are orbiting. In the time between the sampling 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 for orbiting spacecrafts is the movement of the planets. Between the sampling points, the planets will keep moving while the spacecrafts are frozen in space. This causes the spacecrafts to lag behind the planets and then catch up again when new data is available. For the spacecrafts far away, a linear interpolation would be enough to smooth out the jaggedness. For the planet orbiters however, the data has to be sampled more often than once per hour or another translation 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 probably contains some noise. The labels used to visualize the spacecraft have some erroneous behavior when there are other 3D objects closely behind the node that the label is attached to. Since the method implemented renders the label on a set distance from the camera, this becomes an issue when this distance is longer than the distance to an object behind the node the label is attached to because the label is placed behind it. However this is mainly a problem while navigating more closely to orbiters and landers. The labels are overall performing the task of giving an overview of the spacecraft ﬂeet very well. They are working as designed and transition in visibility and sizing smoothly while navigating in the universe. They are seldom overlapping and when they do it is from certain 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 the data handling had to be implemented before access to all of the data was available and before the final format and sampling frequency of the data was set. If all of the data was available in an earlier stage of the project, some other design choices could have been made. Full access to the CSV data from JPL, on which this visualization is based, was not available until the last couple 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 been available throughout this project. There is also similar information in that data set as in the JPL data. One of the major reasons that this data was not used for the visualization is the because it only contains information about the current time. It is possible to collect and save data from that DSN Now, and functionality to save XML documents were implemented for this project, although they were never used. However, even if the data was collected from the very start of the project, there would only be five month worth of data available. One of the goals for this project was to be able to show communication over a long time, and that is one of 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 the DSN and about the complexity to plan the communication. In order to do so, a major part was to visualize the entire fleet of spacecrafts at all times. For that to be possible, the data had to contain information about the location of the spacecrafts even when they were not communicating through DSN. Apart from only showing live data, the biggest difference between DSN Now and the work described in this report is the physical representation of the spacecrafts and their relation to Earth and other celestial bodies. The DSN Now XML data only contained some information, such as range, about the spacecrafts that were communicating at 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 visual method to approximate the spacecraft position was initially considered with the azimuth and elevation for the station combined with the range to the spacecraft. Azimuth and elevation are 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 this lead to difﬁculties when we striving to visualize the whole ﬂeet. If a similar project would be conducted that already had the positioning of the spacecrafts, the DSN Now data would be more useful using the currently chosen implementation. However this was not an option during the time of this project. That is another reason why the JPL data was the better choice for this case.

8.3 Future improvements

An optimization of the data handling is something that would improve the performance of this visualization. Instead of dividing the data into many small files, separated per hour and day, bigger time frames could have been used. For example, the positioning data could have been separated per week or even month instead of per hour. This would not only improve the 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 replaced with 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 a whole could be revisited. As mentioned in section 8.1, there were some question marks regarding the size of the segments. The flow particles described by Carlbaum and Novén are an example of other ways to indicate flow direction in lines [8]. They used brightly colored travelling particles with higher opacity than the lines to indicate direction of magnetic field lines. To implement a similar effect for the signal transmissions is possible and may lead to less questions. Another solution to the sizing issue could be to automatically rescale all the segments depending on how close the camera is to Earth instead of passing the individual light travel times for each signal. This would make the transmissions more uniform in their look and could thus lead to less confusion. One thing that would keep this visualization relevant through time is to show the current communication in a live mode. The data used by DSN Now, see section 3.5, could be used to show the current communication. However, there is no information in that data about the position of the spacecrafts when they are not transmitting. Either that information would have to be obtained from some where else or the live mode would only show the spacecrafts that are actually in communication. The data used by DSN Now is, as opposed to the data used in this visualization, updated every five seconds and therefore does not contain information about 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 the way the signals are handled in the code would have to be changed or the DSN Now data would have to be stored and pre processed in a way that makes it possible to obtain a start and end time for the transmissions.

36 9 Conclusion

The project resulted in a visualization showing the NASA communication between Earth and the fleet of spacecraft. The main goal of the project was to increase the public understanding of the DSN, and to visualize the difficulties of communication in space brought by the vast distances and constantly changing environment. Further, the system can be used to show communication for individual spacecraft in order to enhance the visualization of a specific event. Throughout the course of the project there was an aim to respond to four research questions posed in section 1.4. By revisiting the initial research questions and answer them is a 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 number of spacecraft and signals part of the fleet. The fact that the whole fleet of spacecraft is visible at all times, compared to only the spacecraft in current communication, creates a visual understanding of how many spacecraft there are out there. The color-coded representation of the signals enhances the understanding of the fundamentals of the system, where the ground stations 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 been represented by lines travelling between the ground stations and the spacecraft. Instead of drawing a full line between the two positions, the line length is dependant on the length of the transmission and the line position is dependant on how far the light has travelled at the given time. This makes it possible to see how the line leaves the ground station and then keeps moving in the same direction, even though Earth’s rotation moves the ground station away and out of sight. In the same way it is possible to see downlink arrive at the ground station just in time for Earths rotation to bring the station to the correct position. The main focus of the visualization have been Earth, and to convey the vast differences in distance from Earth 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 all cones are visible, i.e the field of view for all ground stations are visible, it becomes clear that no matter where a spacecraft is located it will be within reach for communication. Having color coded signals reach the ground station at the precise time it comes into the station field of 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. When the spacecraft furthest away are communicating, it takes almost 20 hours for the radio waves to reach them. Visualized in real time with both Earth and the spacecraft in the same frame, it looks like the signals are almost stationary even though they are actually travelling with the speed of light. With the common understanding of the speed of light as incredibly fast the fact that the signals look almost stationary travelling towards the spacecraft gives an idea of how 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 FK 4-based positions of stars to epoch J 2000.0 positions in accordance with the new IAU resolutions”. 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: Contextualized Spatio-Temporal Planetary Surface Visualization”. In: IEEE Transactions on Visualization and Computer Graphics. 2017. [6] Alexander Bock, Carter Emmart, Masha Kuznetsova, and Anders Ynnerman. “OpenSpace: Changing the narrative of public disseminations in astronomical visualization from what to how”. In: Computer Graphics & Applications. 2018. [7] Alexander Bock, Charles Hansen, and Anders Ynnerman. “OpenSpace: Bringing NASA 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 systems, inertial navigation, and integration. John Wiley & Sons, 2007. [11] Obadiah Kegege, Michael Fuentes, Nicholas Meyer, and Amy Sil. “Three-dimensional analysis 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. The Eurographics Association, 2010. [13] Jet Propulsion Laboratory. DSN Now, a live online representation of the DSN. Ed. by Kevin Hussey, 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 history of the advanced systems program. 1994. [15] Douglas J Mudgway and Roger Launius. Uplink-Downlink: A History of the Deep Space Network, 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 orbiter navigation strategy for Mars science laboratory entry, descent and landing telecommu- nication relay support”. In: AIAA/AAS Astrodynamics Specialist Conference. 2012, p. 4747.