2012 COSGC Space Research Symposium Page 1 A Distributed Common Ground Segment for Educational Nanosatellites Quinn McGehan, Michael Mozingo, Megan O’Sullivan, Michael Trowbridge University of Colorado (Boulder) Faculty Advisors: Brian Sanders, Bill Irelan [email protected], [email protected], [email protected], [email protected]April 19 th , 2012 Abstract This paper describes the general architecture of the Colorado Space Grant Consortium Ground Segment, its ability to command multiple types of spacecraft from multiple ground stations, our Service Oriented Architecture (SOA) and a specific implementation for the DANDE spacecraft. Data downlink capabilities could be 8 times larger if two additional ground stations were added to the Ground segment. Custom Java extensions to L-3 InControl satellite mission management software will be discussed, including a novel configuration to command a spacecraft over a cellular data link (3G/4G). The T- Mobile EDGE 2G network was successfully used to command the DANDE spacecraft, but the team was unable to command the satellite over the Verizon 4G LTE network. 1 Introduction Before describing the design of the Distributed Ground Segment that the Colorado Space Grant Consortium (COSGC) has developed, it is necessary to understand the problems that it has been designed to solve. For educational Nanosatellites launches are often difficult to come by, so when they do they are not passed up due to the suboptimal orbits they offer. The orbits that these satellites are usually placed in are very low altitude orbits. The problems that arise from these orbits have to do with the pass lengths that they provide. It is known from basic orbital mechanics [1] that objects in low orbits travel at high speeds. These high speeds result in short orbital periods, meaning that a low altitude satellite passes over large areas of the Earth very quickly. A good example of this is the International Space Station. The ISS is in roughly a 300 Km orbit and orbits the earth about once every 90 minutes. The unfortunate result of the orbits provided to educational satellites is that they pass over the visible horizon of their university in a matter of minutes. This drastically limits the amount of data that can be downlinked from the satellites during a single pass. For an educational satellite, the orbit is usually non-negotiable, so the question that universities are left with is how to maximize the amount of data they can downlink given a low altitude orbit. The route taken by the Colorado Space Grant Consortium located at the University of Colorado at Boulder was to increase the number of geographic locations at which they could contact their satellites. Instead of just a few short passes a day over CU, the ground segment infrastructure can get numerous passes a day over many different locations. The Drag and Neutral Density Explorer (DANDE) satellite illustrates how severe the limited contact time problem can be. Figure 1, which was taken from STK, shows the potential DANDE passes over three different universities over a one year time span. The individual lines that are visible in the figure represent predicted passes, with the blue lines representing passes over CU, the orange lines representing passes over Cornell University, and the yellow lines representing passes over the University of Puerto Rico. Figure 1. Potential ground station locations The density of the pass lines is clearly greater at the two other universities, meaning they are actually geographically better locations to contact DANDE then CU. This result is also confirmed numerically in Table 1 below, where it is seen that on average per day CU has far less contact time that the other two universities. It is important to understand that these daily contact times directly impact the actual amount of data that can be downlinked from the satellite.
Transcript
2012 COSGC Space Research Symposium Page 1
A Distributed Common Ground Segment for Educational Nanosatellites
Quinn McGehan, Michael Mozingo, Megan O’Sullivan, Michael Trowbridge University of Colorado (Boulder)
Abstract This paper describes the general architecture of the Colorado Space Grant Consortium Ground Segment, its ability to command multiple types of spacecraft from multiple ground stations, our Service Oriented Architecture (SOA) and a specific implementation for the DANDE spacecraft. Data downlink capabilities could be 8 times larger if two additional ground stations were added to the Ground segment. Custom Java extensions to L-3 InControl satellite mission management software will be discussed, including a novel configuration to command a spacecraft over a cellular data link (3G/4G). The T-Mobile EDGE 2G network was successfully used to command the DANDE spacecraft, but the team was unable to command the satellite over the Verizon 4G LTE network.
1 Introduction Before describing the design of the Distributed
Ground Segment that the Colorado Space Grant Consortium (COSGC) has developed, it is necessary to understand the problems that it has been designed to solve. For educational Nanosatellites launches are often difficult to come by, so when they do they are not passed up due to the suboptimal orbits they offer. The orbits that these satellites are usually placed in are very low altitude orbits. The problems that arise from these orbits have to do with the pass lengths that they provide. It is known from basic orbital mechanics [1] that objects in low orbits travel at high speeds. These high speeds result in short orbital periods, meaning that a low altitude satellite passes over large areas of the Earth very quickly. A good example of this is the International Space Station. The ISS is in roughly a 300 Km orbit and orbits the earth about once every 90 minutes. The unfortunate result of the orbits provided to educational satellites is that they pass over the visible horizon of their university in a matter of minutes.
This drastically limits the amount of data that can be downlinked from the satellites during a single pass. For an educational satellite, the orbit is usually non-negotiable, so the question that universities are left with is how to maximize the amount of data they can downlink given a
low altitude orbit. The route taken by the Colorado Space Grant Consortium located at the University of Colorado at Boulder was to increase the number of geographic locations at which they could contact their satellites. Instead of just a few short passes a day over CU, the ground segment infrastructure can get numerous passes a day over many different locations.
The Drag and Neutral Density Explorer (DANDE) satellite illustrates how severe the limited contact time problem can be. Figure 1, which was taken from STK, shows the potential DANDE passes over three different universities over a one year time span. The individual lines that are visible in the figure represent predicted passes, with the blue lines representing passes over CU, the orange lines representing passes over Cornell University, and the yellow lines representing passes over the University of Puerto Rico.
Figure 1. Potential ground station locations
The density of the pass lines is clearly greater at the two other universities, meaning they are actually geographically better locations to contact DANDE then CU. This result is also confirmed numerically in Table 1 below, where it is seen that on average per day CU has far less contact time that the other two universities. It is important to understand that these daily contact times directly impact the actual amount of data that can be downlinked from the satellite.
2012 COSGC Space Research Symposium Page 2
Knowing of how long, on average, the ground will be in contact with the satellite per day, and the anticipated throughput, the total amount of data downlinked per day can be computed. Testing has shown that the average downlink rate is 483 bytes per second for a link with a bit error rate on the order of 10-5. Assuming that the entire day’s pass time can be used to downlink data, multiplying the average contact time per day (in seconds) by the average downlink rate yields the upper bound on the amount of data that can be downlinked in one day. Table 1 that adding two ground stations to the ground segment would allow more than 8 times more data could be downlinked from the DANDE spacecraft per day.
Table 1. Average Daily Contact Time
Location Pass time/day (min)
Data Downlinked
(Bytes) Boulder 3.49 101,140
Cornell 14.66 424,847
Puerto Rico 11.41 330,661
Total 29.56 856,648
Another key driver in the design of the Distributed Ground Segment is compatibility. The COSGC has produced several student built satellites, including the cubesat Hermes (launch vehicle failure, February 2011), DANDE (projected launch in 2012) and the ALLSTAR 3U cubesat bus (under development). Moving forward, the COSGC anticipates a continuous production and launch of cubesats and an ongoing need for a ground segment to operate them. For this reason, the infrastructure employed on the ground must be able to communicate with all of the satellites that are built by the COSGC. This makes the distributed ground segment permanent infrastructure that must support many educational satellites, rather than a short term project built with a specific satellite in mind.
1.1 General architecture Figure 2 shows an overview of the ground segment
architecture. Each of the rounded boxes is a geographically separated ground station. The ground stations are operated be personnel on each site, but the InControl server in Boulder, Colorado is the source of commands and destination for telemetry.
Blue Cloud Farms UPR (Puerto Rico)CU Boulder
Remote Gateway
InControl FLITE Client workstations
TNC/Modem
RF Chain
Future satellites
TCP/IP
InControl Server
TNC/Modem
RF Chain
TNC/Modem
RF Chain
ALLSTAR
TCP/IPTCP/IP
DANDE
Remote GatewayRemote Gateway
Mission Operators
Figure 2. Ground Segment Overview
2012 COSGC Space Research Symposium Page 3
The InControl server stores satellite telemetry, generates and sends commands to the satellite, and downloads data files from the satellite. It does not talk to hardware directly – it talks to hardware indirectly, through the Remote Gateway computers on each site.
The Remote Gateway computers provide a bridge between the serial port on the TNC or other baseband equipment and the internet. Their function is purely data relay – they do not control the ground station radio or antenna. If a satellite requires special framing that is not provided by the TNC or baseband equipment, that framing may also be implemented here as a special mode of the Remote Gateway. The Remote Gateways are not part of InControl – they can accept TCP/IP connections from satellite commanding applications other than InControl.
FLITE clients are user-facing front ends of the InControl server. They are used by the satellite operators and engineers to:
• View telemetry graphs through JADE displays • Export telemetry as CSV files for MATLAB • Generate and transmit commands to spacecraft • Quickly find out of limits telemetry parameters • Change which remote gateway the InControl server
uses to command the spacecraft
1.2 Resource sharing At the time of writing, the exact details of ground
station co-op agreements are still being negotiated. Currently, the mission management software (InControl) is treated as satellite specific and private to the institution that is operating the spacecraft. Universities will not be permitted to use another university’s InControl server. This kind of sharing is technically possible but there are unresolved licensing concerns.
The Remote Gateway is the point of interface that allows one university to enter the ground station of another university and command a spacecraft. Access will be restricted by a firewall on the Remote Gateway itself that only accepts incoming connections over secure shell (ssh).
A remote management interface is exposed to other universities (over the ssh tunnel). This remote management interface allows other universities to check to see if another university is currently using the remote gateway, check the current gateway configuration mode, and command the remote gateway to a different configuration (data layers, serial ports, etc) if necessary.
1.3 Network layers Because the architecture relies heavily on the internet
to communicate between the main InControl server and the geographically separated remote gateways it is necessary to look more in depth at the network layers that
make up the internet connection of the design. Figure 3 breaks down the section of the architecture that utilizes the Internet and shows the protocols used at each step.
Remote Gateway
SOAP Web Service
InControl Server
TCP/IP
TCP/IP
SOAP client TCP socket
ssh (AES)
ssh (AES)
socat,KISS and AX25 framing
TCP/IP
Commands, Telemetry
Commands, telemetry
Hardware Gateway
Gateway reconfiguration
To TNC
RS-232
User commands, GUI
UnencryptedEncrypted
Figure 3. Network layers
There are two pathways that the hardware gateway uses when communicating with the remote gateway. The first, is used for sending commands and receiving telemetry, and opens a Transmission Control Protocol (TCP) socket to connect to the remote gateway server. The second pathway is used for reconfiguring the remote gateway, and it utilizes Simple Object Access Protocol (SOAP). Data leaves the TCP socket, or the SOAP client, using TCP/IP. To ensure the security of the data being sent between the InControl server and the remote
2012 COSGC Space Research Symposium Page 4
gateway, the TCP/IP connection is routed through a secure shell that implements the Advanced Encryption Standard (AES). The encrypted sections of the network are depicted by black boxes in Figure 3.
After encryption, the data leaves the InControl server and goes out over the public Internet. The data remains encrypted until it reaches the remote gateway. After being decrypted, the data either goes to SOAP Web Service or the socat/tnc bridge, depending on port it entered the ssh tunnel on. If the data came from the socket connection, it is piped through the socat/tnc bridge where it is converted from TCP, framed in KISS frames, framed in AX.25 frames, and then transmitted as RS-232 serial data. The data leaves the remote gateway over an RS-232 cable and goes to the Terminal Node Controller (TNC) for transmission.
Access to the network is restricted to two places. The first is the hardware gateway, which transmits commands, receives telemetry, and configures the remote gateway using the SOAP client.
The second access point is from the remote gateway. The socat connection can be monitored locally, which is necessary for testing and debugging of the remote gateway as well as the full communication path. This access point does not pose a security risk because the remote gateway is password protected, and only those with access can use it.
1.4 Custom software The Colorado Space Grant Consortium uses L-3
InControl satellite mission management software to operate its spacecraft. The platform includes a hardware gateway that can transmit commands over a serial port, but does not include a gateway that can tunnel through ssh and connect to a TCP socket. Satellite specific behaviors for the DANDE and Hermes spacecraft also required custom telemetry processing code.
Using the source code Mitch Seybold provided for the serial hardware gateway as a starting point, the Colorado Space Grant Consortium produced a new hardware
gateway class (TcpBiDirGateway). It uses the Trilead ssh2 library to connect the ssh port forwarding to the remote gateway and a SOAP web service client to manage and configure the Remote Gateway it connects to. The TcpBiDirGateway class is an abstract class that implements socket connection and input stream reading, but requires a satellite-specific derivative of it to implement two helper methods – hasPacket() and processPacket(), which tell the input stream (downlink) reader whether or not a full frame for the has been received, given the satellite’s current operating configuration, or instructs the satellite-specific derived class to process the packet according to current state of the satellite.
The TcpGateway project also includes specialized parsers that can handle the major/minor frame scheme employed by some data files on the DANDE spacecraft and also to correct the measurement time that was recorded by the satellite.
1.5 Service Oriented Architecture (SOA) The common ground segment uses a limited service
oriented architecture. The Remote Gateway was designed to be a separate enterprise application from the mission management software (InControl). Decoupling these two components allows the University of Colorado to share its ground segment with partner institutions that use mission management software other than InControl.
In this architecture, the remote gateway is a service provider and the InControl mission management software is a service consumer. Because the Remote Gateway must reconfigure its data layers to support more than one type of satellite, it also requires a control channel between the mission management software and the Remote Gateway. We opted for an out-of-band control channel to keep the command/telemetry data layer simple – as a straight-through TCP socket stream from the mission management software to the Remote Gateway (Figure 4).
Figure 4. Out-of-band Remote Gateway control interface
2012 COSGC Space Research Symposium Page 5
Table 2. SOAP operations provided by the Remote Gateway
SOAP Operation Returns Description countConnected(String satellitePath) Integer Number of InControl servers connected to the
TCP Socket Server for satellitePath getMode(String satellitePath) String The current data layer configuration mode for
the satellitePath getPaths() Array of Strings List of all satellitePath (data layer
configurations) that this remote gateway supports
measureSatelliteOffset(String satellitePath) TimeOffset Measures the offset between the satellite’s clock and the remote gateway’s NTP synchronized ground clock for the satellitePath specified
setMode(String satellitePath, String mode) N/A Changes the data layer configuration to the mode for the satellitePath specified
Simple Object Access Protocol (SOAP) was chosen as
the protocol for the out-of-band control channel because it is mature, supported with code-generating wizards in most modern development environments, and includes an embedded interface specification – in the form of the Web Services Definition Language (WSDL) document hosted by the web service provider. Figure 4 is a diagram showing where these parallel control channels are implemented.
The primary service that the remote gateway provides is a path out to baseband equipment over an RS-232 serial port. This includes any specific framing or deframing required to interface with the baseband equipment. As secondary services, the Remote Gateway can return its current configuration or change its data layer configuration for use with a different satellite. The Remote Gateway also provides services for low-latency operations that require it to autonomously command a spacecraft, such as DANDE’s time offset measurement. Table 2 describes the SOAP web service methods exposed by the Remote Gateway.
2 Experiment: commanding a satellite over a smartphone data link
When the Colorado Space Grant Consortium delivers the DANDE satellite to the Air Force Research Lab (AFRL), the satellite must be commanded and its telemetry must be analyzed at several points in the satellite testing process. If a remote gateway were delivered to the AFRL along with the satellite, then engineers in Boulder, Colorado would be able to
command the spacecraft and examine its telemetry in the same manner that they would when the satellite is on orbit. This would speed the post-test data analysis and verify that the ground segment can still operate the satellite after each test.
Unfortunately, Department of Defense (DoD) information assurance policies prevent the AFRL from connecting a University of Colorado remote gateway computer to their network. Instead, the AFRL will provide the DANDE project with access to the internet through a Verizon Wireless 4G LTE Wi-Fi hotspot. The goal of this experiment is to determine whether or not the DANDE satellite control ground segment can function, end-to-end, with a low quality mobile data link in the path. None of the mobile broadband providers were notified prior to this test.
2.1 Experimental Apparatus The project team does not have access to the exact Wi-
Fi hotspot that will be used when the satellite is delivered to the Air Force Research Lab (AFRL). The closest equipment that was available to test with were Android cellphones with the personal Wi-Fi hotspot application enabled. A 4G LTE Verizon Wireless USB dongle was also tested and compared with an older 3G Verizon Wireless USB dongle in a 2011 proof of concept similar to this experiment. Figure 5 shows the physical network diagram for the experiment.
MOCC stands for Mission Operations Control Center. It is the facility that the Colorado Space Grant Consortium uses to command its spacecraft.
2012 COSGC Space Research Symposium Page 6
Android Smartphone
`
Remote Gateway,InControl Client
3G/4G Data
WiFi tethering
CU TCP/IP
`InControl Client (MOCC)
InControl Server
CU Firewall
RS-232
DANDE
Public Internet Cell phone
tower
Radio
TNC
UHF/VHF
Figure 5. Physical connections of mobile data experiment
For the USB dongle test, the Android smartphone was removed from the chain and replaced with a Pantech UML 290 USB wireless internet dongle. This also removes Wi-Fi tethering from the network path.
2.2 Equipment List Table 3 describes each major system component and
the specifications of the device tested, except for the smartphones and USB mobile broadband adapter. The smartphones and mobile data configurations are listed in Table 4.
TNC Symek TNC31S Radio Yaesu FT-847 InControl Version Training-5.8.11.2.35476
The Motorola Atrix 4G phone used in tests 2 and 3 is
an unlocked, AT&T branded phone that was later switched to the T-Mobile network. While the phone can send data over the T-Mobile EDGE network, its radio is tuned to the AT&T network frequencies for 4G. This
prevents the phone from using 3G or 4G speeds on the T-Mobile network.
2.3 Experiment procedure Detailed procedures for the experiment are found in
Appendix A. For each mobile data configuration in Table 4, the basic test process was:
1. Connect the remote gateway to the internet. 2. Measure throughput to the general internet
(speakeasy.net). 3. Determine if the VPN client is needed
a. Connect the remote gateway to the CU VPN if blocked by the firewall
4. Test latency & throughput to the InControl server 5. Attempt to launch the remote FLITE client 6. Test the DANDE command/telemetry link over RF
a. Monitor beacon frames b. Log in to the satellite c. Measure spacecraft time offset d. Upload a file using zmodem e. Download a file using zmodem
If the flight client could not be started over the wireless data link, the Mission Operations Control Center (MOCC) InControl client was used to command the spacecraft.
The connectivity was tested by running the ping command from the Remote Gateway (to the InControl server). The connectivity from the InControl server to the Remote Gateway was tested by attempting to connect the InControl hardware gateway to the Remote Gateway. If either of these failed, the VPN client was started on the Remote Gateway to establish a secure tunnel to the CU network.
2012 COSGC Space Research Symposium Page 7
Table 4. Mobile data configurations tested
Test Manufacturer Model Configuration Carrier Connection 1 N/A N/A Ethernet cable (control) CU 100 mbps 2 Motorola Atrix 4G OpenGarden Wi-Fi tethering T-Mobile US EDGE (2G) 3 Motorola Atrix 4G Android mobile Wi-Fi hotspot T-Mobile US EDGE (2G) 4 Motorola Droid X Android mobile Wi-Fi hotspot Verizon 4G LTE 5 Pantech UML290 wvdial ppp client (USB) Verizon 4G LTE
3 Results We were able to test two different cellular networks
following our test plan. First, we tested closing the link and commanding the DANDE spacecraft using T-Mobile’s network and second we tested using Verizon’s network. For testing the T-Mobile network, the Android phone we used was an Atrix. The account must be activated for Wi-Fi tethering on the T-Mobile network. We were able to connect to the Wi-Fi hotspot created by the Android phone using our remote gateway computer that is running 64-bit Ubuntu.
After connecting to the mobile Wi-Fi hotspot, we tested the bandwidth of the link using the speakeasy.net speed test. For this test, we were not connected to the university’s network. To connect to the university’s network, a Virtual Private Network (VPN) is required to get past the University’s firewall, although the ports could also be forwarded for a long term solution.
After setting up the VPN with vpnc, we were able to connect to the university’s internet. The VPN is also required because we are utilizing a domain name service (DNS) server to connect to the remote gateway computer. The DNS keeps us from having to reconfigure each time the computers IP address changes. We were unable to resolve the DNS correctly without the VPN. Using Linux’s nslookup, we checked the resolution for the remote gateway computer. Without the VPN nslookup did not see the DNS server address, with the VPN however, we were able to resolve to the DNS.
After we had connected to the network, we ran two tests of the speed and stability of the connection. First we checked the bandwidth again. This time, using the Linux utility iperf hosted on one of our InControl servers at the Colorado Space Grant Consortium. The reason for this second bandwidth test is to examine the impact the VPN has on the link and it a different routing path has any effect. We also tested our latency to the InControl server using the ping command. All of the bandwidth and ping results can be seen in Table 5.
Table 5. Bandwidth and latency
Control Test 3 speakeasy Downlink 87601 kbps 194 kbps
speakeasy Uplink 53022 kbps 95 kbps InControl server
(iperf) 94100 kbps 102 kbps
Latency (ping) 0.228 ms 258.62 ms For our final test in this configuration, we tried
connecting to the In Control server and commanding the satellite. We were unable to connect the In Control FLITE client to the serer remotely, due to a misconfiguration of the In Control activator daemon configuration file that was not detected until after the test. We were able to circumvent the problem during testing by using a local FLITE client on a mission operations control center computer. This does not invalidate the test because we would be able to use this setup at the AFRL facility. The important part of the test is whether or not the link is stable enough to transmit commands and receive telemetry from the satellite.
Once the link was established and the hardware gateway was connected, we tried commanding the DANDE spacecraft. The satellite received and executed the commands successfully. We were able to login, uplink a file and downlink a file. The slow speed of the Wi-Fi network (100kbps) did not affect the link as it was still above the maximum transmission speed between the satellite and the ground. During the file uploads and downloads, we observed rates that were within a reasonable margin of the Ethernet connection we used as a control. We did not experience any dropped packets or data corruption errors during the test.
We also tried a time offset measurement test. This utilized NTP to calculate the time offset between the satellite and the ground. This command did not work over the mobile network because of latency in the mobile network, while it does work over the Ethernet connection. The mobile time was too far out of sync with the NTP time, and an exception was thrown. The results of the tests are summarized in Table 6 (next page).
2012 COSGC Space Research Symposium Page 8
Table 6. Testing results
Test Control Test 3 FLITE client initialization Yes No Hardware gateway able to connect Yes Yes Dynamic DNS updates remote gateway address
Yes Yes
Receive beacon frames Yes Yes Login attempt successful Yes Yes Time offset measurement Yes No VPN client needed No Yes File upload bytes/second 512 369 File download bytes/second 545 835
3.1 Test failures Test 2 failed because the OpenGarden Wi-Fi tethering
app on the Motorola Atrix 4G blocked incoming VPN traffic. This prevented the iperf program on The InControl server from completing the throughput test. The vpnc client on the Remote Gateway was also unable to connect to the CU VPN through OpenGarden.
Test 4 failed because the remote ground station was unable to connect to the Motorola Droid X phone when its mobile Wi-Fi hotspot was active. We tried to connect with several different devices including a laptop and the Atrix phone. Both were able to connect to the Droid X, so a hardware compatibility issue between the network interface card (NIC) on the ground station computer and the NIC inside the Droid X is assumed to be the cause. For future work to solve the issues seen with the Verizon connection with the Droid X we plan to purchase a NIC card with a different chipset.
Test 5 used Bill Irelan’s personal Verizon Wireless 4G USB dongle. When we tried to use this device, we were able to connect and got good results using the speakeasy throughput test and low latency compared to the connection with the Atrix. Unfortunately, the support for such a device in Ubuntu and Linux is very limited at the time and as such we were unable to get the VPN to connect over this network. The prevented us from testing with In Control because we were being blocked by the University firewall.
4 Discussion
4.1 Network throughput requirements The experiment showed that spacecraft login, free text
commanding, file upload and download all functioned when the net throughput between the InControl Server and Remote Gateway was 102 kbits/sec. While the time
offset measurement command failed, it failed a pre-command sanity check because Remote Gateway’s Network Time Protocol synchronization was out of tolerance. This is most likely due to high (and inconsistent) latency of the network – not raw throughput. This experiment did not find a lowest throughput threshold required for satellite commanding, but it did find that reliable satellite commanding is possible with a throughput of 102 kbits/sec.
4.2 Maximum tolerable latency There was not enough variation in latency observed in
this experiment to form conclusions on the maximum tolerable network latency. It is clear, however, that latency of 258 milliseconds it too much latency to maintain NTP time synchronization – which prevents the Remote Gateway from accurately measuring satellite time offset when it is connected over a mobile broadband network.
General spacecraft commanding, on the other hand, is not very sensitive to any of the network latencies observed in this test. The upper limit on tolerable network latency should be a function of the maximum command timer length in the InControl hardware gateway and the login process on the spacecraft itself. Both of these are two orders of magnitude larger than the largest latencies observed in this test, which should make them relatively immune.
File transfer using zmodem is moderately sensitive to network latency. The zmodem upload throughput dropped from 512 bytes/sec over an Ethernet cable to 369 bytes/sec over the Motorola Atrix 4G, but the downlink throughput increased significantly. The increase in downlink throughput may be misleading – it may be a false report caused by delays in transmission acknowledgement from the TCP layer that delayed the start of the ground’s zmodem file transfer timer.
4.3 Overall reliability and maturity The mobile broadband networks tested in this
experiment are almost mature enough to use for commanding educational nanosatellites. The most important parts of the ground segment did function reliably over the T-Mobile EDGE network using the Motorola Atrix 4G, but the EDGE network’s high latency and low throughput degraded the zmodem uplink throughput.
The throughput measured over the Verizon Wireless 4G LTE dongle was quite promising. While the dongle itself may not be an option because of its immature support in Ubuntu Linux, it does suggest that a Verizon 4G LTE Wi-Fi hotspot should have the raw throughput to work. It would combine the stability of a standard Wi-Fi
2012 COSGC Space Research Symposium Page 9
connection with the best throughput observed in the experiment.
All of the mobile broadband options suffer from the same drawback – using a VPN client makes DNS was difficult to configure on the Remote Gateway. Connecting the VPN client causes the Remote Gateway to ignore DNS search prefixes specified in the NetworkManager configuration files. This causes jacorb, the CORBA implementation used by InControl, to resolve the hostname using the CU domain name service. When jacorb cannot resolve the hostname of the client, the Remote Gateway’s FLITE client cannot receive updates from the InControl Server’s CORBA ORB and ceases to function. One possible workaround would be to open a remote desktop session from the Remote Gateway to a MOCC workstation in Boulder and execute the FLITE client on the MOCC workstation.
5 Conclusion Low Earth orbits make it difficult to operate
nanosatellites because of their extremely short contact windows. Adding two more geographically separated ground stations could allow more than 8 times more data to be downlinked from the DANDE spacecraft in one day.
Flexibility and modularity are also key traits of the Colorado Space Grant Consortium’s distributed ground segment architecture. The current design allows for more than one ground station to be used to command more than one type of satellite. It also includes the ability to share the COSGC ground station with other universities.
The modularity of the network was tested by configuring a ground station to operate over a mobile broadband data link and tested with two different carriers. The T-Mobile EDGE network was found to be fast enough to command an educational nanosatellite as long as time offset measurements are not required. The Verizon Wireless 4G LTE network was found to be significantly faster, but equipment incompatibility and immature support in Ubuntu Linux prevented us from using it to command a spacecraft.
5.1 Recommendations for future work Register the remote gateway web services with a
Universal Description, Discover and Integration (UDDI) server. This would allow for a centralized listing of remote gateways and the operations that each supports.
Currently, the ground segment does not automate control of the radio or antenna actuators. This is performed by a human operator using SatPC32. The process of commanding over a geographically separated terminal would be much easier if the Remote Gateway were capable of pointing the antenna and tuning the radio.
The Remote Gateways would also be easier to maintain if the software packages that they use were
stored in a repository as a .deb package. Currently, each remote gateway is built by hand, with custom applications compiled from scratch.
The experiment should be repeated on 4G Wi-Fi hotspots from AT&T, T-Mobile and Verizon Wireless.
6 Acknowledgements The Ground Segment team would like to thank Mitch
Seybold of L-3 Telemetry Systems for the countless late nights and weekends he spent helping us optimize our InControl deployment and debugging our TCP Bidirectional gateway class.
The InControl mission management software that is used by the Colorado Space Grant Consortium was donated by L-3 Telemetry Systems.
Special thanks to Bill Irelan for loaning us the Verizon Wireless 4G LTE dongle for testing.
7 References [1] Howard D. Curtis, Orbital Mechanics for
8.1 Establish the network connection Preconditions: ● The Android phone has been rooted ● The Superuser application has been installed on the Android phone ● The Open Garden WiFi tethering application has been installed on the Android phone ● The Android phone is configured for data ● The Android phone has tethering/mobile hotspot services enabled through the carrier 1. On the cell phone (OpenGarden):
1. Turn WiFi off 2. Run the Open Garden WiFi Tethering application 3. Press the “Start Open Garden Tethering” button
2. On the cell phone (Android mobile Wi-Fi hotspot): 1. Select Applications 2. Press the Mobile Hotspot button 3. Press the Mobile Hotspot checkbox
3. On the computer: 1. Disconnect the CAT-5 ethernet cable from the ethernet port 2. Disconnect from any WiFi networks 3. Either:
• Connect to the OpenGarden SSID from Android phone Note: you may need to manually add it as a hidden network and explicitly specify the SSID, band (2.4 GHz), channel, and WEP key
Or: • Connect to the Android mobile Wi-Fi hotspot SSID
8.2 Verify network connectivity 1. Check DNS configuration
a. Open a shell prompt on the remote gateway computer. b. Run this command and record the computer's IP address on wlan0:
ifconfig c. Verify that dynamic DNS is updating. Run the command
nslookup <remotegateway>.dyndns-work.org d. Verify that the colorado.edu search prefix resolves correctly. Run the command:
nslookup <incontrolserver> 2. Test speed to the internet
a. In Firefox, open the URL http://www.speakeasy.net/speedtest/ b. Click on the Dallas, TX server c. Record the uplink and downlink speeds in kbps after the test completes
3. Test throughput to the InControl server a. Open shell prompt on a computer that isn't the remote gateway. b. Run the command
ssh <user@incontrolserver> c. In the <incontrolserver> terminal, run the command
iperf -s d. Open a shell prompt on the remote gateway computer e. Run the command
iperf -c <incontrolserver> f. Record the throughput
4. Test latency to the InControl server a. Open a shell prompt on the remote gateway computer b. Run the command
ping -c 10 <incontrolserver> c. Record the average latency in milliseconds
2012 COSGC Space Research Symposium Page 11
8.3 Test InControl functionality 1. Run the FLITE client on the the remote gateway 2. Log in to the SCC domain 3. Request the control token. 4. Connect and Select the uhf_vhf_AFRL gateway 5. Wait for a beacon frame from the satellite. Verify that “Received beacon frame from DANDE” is displayed in the
AWE.
8.4 Test InControl commanding 1. Open a shell prompt on the InControl server
a. Run the command i. rm /home/incuser/zModemDownloads/15000.txt
2. Return to the InControl FLITE client on the Remote Gateway computer. a. Log into the satellite. Record the number of attempts required. b. Send the command “Measure the time offset from DANDE.” c. Send the command “Type command to execute on DANDE” with the argument:
i. rm /data/uplink/15000.txt d. Send the command “Upload 15000 byte file.” Record the final (average) throughput in bytes/sec.
3. Open a display frame (menu: Window →New Frame) a. From the Displays menu, click Jade Display. b. Click on Beacon but do not click OK. c. Use a stopwatch to record the time from when you click OK to when the jade display opens.
