Interactive 3D Visualization of the NASA Deep Space Network activity

Department of Science and Technology

Institutionen för teknik och naturvetenskap

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

Interaktiv 3D-visualisering

av NASAs Deep Space Network

kommunikation

Lovisa Hassler

Agnes Heppich

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

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/

Copyright

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/

Linköpings universitet SE–581 83 Linköping

Linköping University | Department of Science and Technology

Master’s thesis, 30 ECTS | Medieteknik

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

Interactive 3D Visualization of

the NASA Deep Space Network

activity

–

Visualizing communication across great distances

Interaktiv 3D visualisering av NASAs Deep Space Network

kom-munikation

Agnes Heppich, Lovisa Hassler

Supervisor : Emil Axelsson, Carter Emmart Examiner : Anders Ynnerman

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

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

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to 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/.

Abstract

This report describe the master thesis project developed by students from Linkoping University. The project was executed at the American Museum of Natural History and is a contribution to an open source software called OpenSpace. The report presents the design and development of an interactive visualization of the NASA Deep Space Network (DSN). Data from the Jet Propulsion Laboratory (JPL) was used to create a visualization de-signed to enhance the public understanding of the network as well as highlighting the chal-lenges of interplanetary communication. The research topics for this work has been how to visualize communication while considering the temporal aspects in space communication as well as showing all of the active components of the DSN in a comprehensible manner for laypeople. The result was an interactive visualization showing all spacecrafts, commu-nication complexes and radio wave commucommu-nication that are part of the NASA Deep Space Network between 2014 and 2019. User tests showed that the visualization was in general satisfying the main goals of the project. Some future improvements have been identified and described as well.

Acknowledgments

We would like to express our gratitude to everyone at Linköping University (LiU) and 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

Bockfor 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 con-nected us to people with expertise about DSN. Special thanks to Shan Malhotra for his willingness to generate custom file 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 Trakinskiand 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.

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 field of view . . . 24

6 Results 26 6.1 Visualization of the DSN stations . . . 26

6.2 Visualization of the spacecraft . . . 27

6.4 Ground station field 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

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

rep-resents 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. P1and P2represent the dish location

and the spacecraft location. The line represents the transmission between the two. 15 4.2 Li’s represents lines where L1is the first 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

to-wards a spacecraft or from a spacecraft toto-wards 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

times-tamp, right ascension measured in degrees, declination measured in degrees, range measured in kilometers and light travel time measured in seconds. . . 18 5.2 Preprocessing work flow chart. The numbers represent different scripts used 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

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

transmit-ting 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 space-craft position. . . 27 6.4 The labels for the spacecraft near Mars merged into two clusters i.e. "InSight,

MarCOA & MarCOB" and "MarsOdyssey, MRO ..." which reduces the 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 field of views colored according to ground station with Goldstone as blue,

Madrid as green and Canberra as red. They illustrate the potential range of each ground station location on Earth. . . 29 6.7 Wire frame representation of the station field of views colored according to ground

station with Goldstone as blue, Madrid as green and Canberra as red. They illus-trate the potential range of each ground station location on Earth. . . 30

List of Tables

3.1 Positioning data table. The first two rows indicate how often there are data ples and for what spacecraft. The rows following are the parameters in every sam-ple. "Upleg" means from station to spacecraft and "downleg" is from spacecraft to station. . . 12 3.2 Transmission data table. The DSN Now XML data are snapshots that can be

col-lected approximately every five seconds from DSN Now. Thus they do not have a set start and end time for the transmission by default, which the JPL schedule data has. . . 12

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-tific successes made during The Space Race during the Cold War being a major contributor. Newly acquired knowledge about the universe and about new missions are written 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 sta-tion" refers to a communication complex that is either in Canberra, Goldstone or Madrid. The DSN is developed for transmissions with spacecraft far out in our solar system 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.2. OpenSpace software

1.2

OpenSpace software

OpenSpace is an open source space data visualization software. It is an interactive 3D rep-resentation of the known universe as well as a cooperative effort by Linköping University (LiU), American Museum of Natural History (AMNH), the Scientific Computing and Imag-ing Institute at the University of Utah, and New York University. With a foundation of data from NASA, the software uses advanced computer graphics to e.g render scientific represen-tations of celestial bodies in the solar system with high resolution image data sets, 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 audi-ence. 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 repre-sentation 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 fits 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 inter-planetary communication is?

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 han-dling 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.

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 scientific visualizations to better understand space, the task of displaying the communication activity of the DSN in 3D has barely been explored. The article Three-dimensional analysis of deep space network antenna coverage by Kegege et al. 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 con-ducted by people at NASA Glenn Research Center and the Space Communications and Nav-igation (SCaN) team. It was made with the purpose of exploring the coverage gap and 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 calcu-lations. Since the focus on their work was to explore the coverage gap they used the az-imuth/elevation terrain masks around the stations. This was important to get details 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

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 five 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 figure 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 com-munication 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.

3

Theory

The challenge of visualizing the DSN requires some understanding of the different compo-nents of the network. In this chapter the different types of stations and their capabilities are described in greater detail. It also contains information about the spacecraft and the com-munication between them and the stations. To be able to follow the placement of these DSN components into OpenSpace the theory of celestial coordinate systems as well as OpenSpace specific 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 dis-tances 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 cov-erage 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

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 rep-resents 30 000 kilometers from Earth. Outside of that radius the DSN stations coverage over-lap, and there are nearly no blind spots left.

The DSN station antennas have different sizes and are designed to solve different prob-lems. There are 70 meter dish antennas and 34 meter dish antennas that are currently used. Smaller dishes at sizes 26 meters and 9 meters are used for Earth orbiting missions but 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 Efficiency (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 com-mands (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 num-ber 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 an-tenna pattern of the peak radiating power of the main lobe, than their smaller counterparts. They also have the capability to pick up weaker signals. That makes them able to 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 mulMul-tiple 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 conflicts. 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 mul-tiple receivers, usually two (2-MSPA), although an extension of up to four (4-MSPA) is being

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 scientific 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 commu-nication 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 specific instruments the spacecraft are all equipped with radio trans-mitters and receivers to communicate with DSN stations.

3.1.3

Communication between stations and spacecraft

The communication between spacecraft and DSN can be divided into uplink and downlink, see Figure 3.2. Uplink is a signal sent from a station out to a spacecraft, downlink is a 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 filtered out noise in the downlink data caused by radioactivity in space. This means the downlink acquires information about radio active phe-nomena on its way down to Earth. However this also means that many outer 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-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 sig-nal power becomes weaker. NASA and JPL have made large improvements with the tech-nology of the DSN stations for them to be able to pick up on extremely weak signals. NASA also use amplifiers 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 accu-rate as possible.

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

3.2

Precision issues while navigating in OpenSpace

OpenSpace strives to provide a seamless interactive navigation across the whole known uni-verse as described in section 1.2. The navigation focus in OpenSpace can be set by 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 floating point preci-sion 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 cam-era is to a scene graph node that is placed far from the world origin, and Axelsson et al. also describes why the sensitivity of a visible vertex displacement is inversely 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.

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 sys-tems 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 co-ordinates. 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 repre-sented by the colored fields marked in the picture.

3.3.1

Equatorial coordinates (Right Ascension and Declination)

Right ascension and declination are used to map outer space much like latitude and longi-tude are used to map Earth. Instead of Earth, right ascension and declination are based 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 infinite 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 celes-tial 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].

3.4. JPL data

3.3.2

Horizontal coordinates (Azimuth and Elevation)

Much like right ascension and declination, Azimuth and Elevation are used to position celes-tial bodies and spacecraft. Instead of using Earth center as the origin, azimuth and elevation are measured from the current position of the viewer and are both angles. This means that the Horizontal coordinate system is fixed to the viewers position and not the stars. There-fore the coordinates of a celestial body varies depending on where the viewer is located. 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 perpen-dicular 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 pub-licly 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 space-craft and celestial bodies are called SPK (Spacespace-craft 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 win-dows. Another that is sampled every hour for the 5 year period that was the decided time-frame for this project.

The upleg data describes the location of the spacecraft when the signals left the 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 con-tinuously 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

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 unspecified upleg and downleg

Ra/Dec - upleg and downleg

Doppler - one-way and two-way

Table 3.1: Positioning data table. The first 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 col-lected approximately every five 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 identifies 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 five 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.

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 compo-nents 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 differ-ent 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 space-craft 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

4.2. Ground stations and their coverage option would be to only show the spacecraft that are in current communication. However, this would conflict with the goal of showing the extensiveness of the network. To be able to show this accurately, there was a need to get updated positioning even outside of the trans-mission windows, which was possible through the CSV positioning data from JPL. While 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 propor-tions. 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 field of view with cones. To connect them to each ground station location the field 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 con-sidered. The first was a, fully colored line going from spacecraft to station, only active during the transmission window and not showing any travelling through space, see figure 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 visu-alization 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 ef-fect 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

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. P1and P2represent 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 figure 4.2. Slightly later a new short segment would travel from a slightly different start and end po-sition, while the previous segment continues its course from the previous positions, see the center and right part of figure 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 L1is the first 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 seg-ments travelling at the speed of light this is a challenge for the outer space signals because of the immense distance. A flow effect is a good way of making this more clear.

Another challenge was overlapping communication lines. The cases with MSPA, de-scribed in section 3.1.1 is one such case, but also two-way communication mentioned earlier. Since there can be multiple downlink there could possibly be a need for indicating this. 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-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 trans-mission 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 insignificant compared to the distance light travels in that time. Thus the line would appear almost straight. If look-ing at the transmission course in detail the physically accurate method would not have 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 to-wards a spacecraft or from a spacecraft toto-wards 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 de-tail in the next chapter.

5

Implementation

The implementation of the NASA deep space network visualization is described in this chap-ter. Throughout our contact with JPL staff some data samples were given that originally contained data sampled every minute. However this was later changed due to the effort and time to generate this data for the whole fleet. 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 suit-able for a live mode. The JPL data contained more essential information regarding the trans-mission which are the start and end time as well as uplink and downlink, while also 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 field 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

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 times-tamp, 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 be-cause the longest light travel time is almost one day. To handle transmissions over midnight, a buffer of one day before the transmission and one day after the transmission is kept in 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 or-der 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.

5.1. Preprocessing of raw data and Data formats

Figure 5.2: Preprocessing work flow 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, com-pared to the total size of the original raw data which is approximately 300 MB per spacecraft. However by dividing the data into smaller files, they are only around 10 KB in size. At 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 con-tains 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 com-pared 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.

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 function-ality 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 sur-face, no matter how Earth is rotated. Since the stations were spread out over three locations, three different rotation matrices have been used. A property was implemented to be able to rotate the models around their axes within their local coordinate system. This feature was used to find the appropriate static rotation matrices.

5.3

Spacecraft

To insert the spacecraft into the scene there was a need to create a new translation class 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

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 fleet 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 fleet 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 figure 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