P20151: Satellite Localization

Subsystem Build & Test

Table of Contents

Team Vision for Subsystem Level Build & Test Phase


For the Build and Test Phase, we planned on having all of the following accomplished prior to our Review during week 6.


Orekit Access Time and Doppler Shift Calculator and Integration into Data Flow

This phase, we finished the technical aspects of predicting satellite access times using Orekit and adapted the Java program to interface with the Qt GUI for inputs and then the C++ "main program" to accept the outputs.

The Orekit program takes in five inputs to determine the satellite's access times and doppler shifted frequencies:

The doppler frequency is calculated by finding the satellite's velocity relative to the station's velocity:

 Doppler Frequency

Doppler Frequency

where v_s is the velocity of the satellite with respect to the receiver, v_r is the velocity of the receiver with respect to the satellite=0, c= speed of light.

The following is a flowchart of the Orekit program to get a better sense of the process:

 Orekit Access Time Flowchart

Orekit Access Time Flowchart

After the program finishes, output in the following form is given to the main program, which reads it in and sends commands to the HackRF for recording.

 Orekit Access Time Output

Orekit Access Time Output


The user input diagram was a preliminary diagram used to define inputs and outputs of the GUI.
 User I/O

User I/O

This was used as a basis for GUI inputs and outputs before making the view.

The GUI (named Cowboy) was created in Qt and has Basic settings tab as well as Advanced settings. An RIT server was provided with 2 GB of RAM and 1 TB of storage space.

This is the view alone, with no functionality. The basic tab is where the typical user will operate. The user can input satellite data, track it, and record its signal.

 Basic View

Basic View

The advanced tab will be used to debug and fine-tune default settings. Each station's settings can be controlled individually.

 Advanced View

Advanced View

Hardware and Software Diagrams

A diagram was created to show the power, clock, and data connections among the hardware at each station. At this point, the UPS powers the Raspberry Pi. The power system is currently being reworked and is subject to change.



A dataflow was created to show how information with flow through the software programs to produce a ground track.



GPS Communication/Data Collection

We are currently debugging setting the Raspberry Pi time to the GPS time. This is recorded in the problem tracking excel sheet.

We read the data from the GPS antenna using a custom Python script, available on our GPS repository

The live data stream looks like this: <<Image>>

Data Collection with HackRF and QFH Antenna through GNU Radio

GNU Radio was used for both data collection and data processing. The hackRF works nicely with GNU Radio programs to allow for ease of operation. Two different tests were carried out using an unsynchronized two station system. The first test was based on the weather radio reference signal at 162.4 MHz, and the second test was conducted using a HC-12 transmitter at 433.4 MHz. Both of these tests are documented in the following presentations:

Reference Signal.

Transmitter Signal.

Electrical System Schematic and Wiring Diagram

connor and zach

TDoA as Executable

The Matlab program, TDoA, must communicate with the C++ "main program". We do this using a TCP connection. Matlab script, TDoAwithTCPin.m, reads data from a hosting server, the C++ main program in our case. The stream of data must be in the following order:
  1. Solver - Integer. Set to 0 for symbolic solver, 1 for Hyperboloid minimum distance, 2 for minimum time difference difference. Default 1.
  2. Number of stations - Integer.
  3. Number of time difference sets - Integer. This is the number of discrete data sets or points in a given ground track.
  4. Reference - 3 Doubles, a 1x3 matrix denoting the reference location [Latitude,Longitude,altitude] in units of decimal degrees and meters.
  5. Reference Error - a 1x3 matrix denoting the reference location error, [dLat,dLong,daltitude], same units as Reference. Error is assumed Gaussian and explains 95% of all measured reference values.
  6. Receiver Locations - a nx3 matrix denoting station location with respect to a reference, [Lat,Long,altitude].
    1. Given 4 stations: a, b, c, d, the order is:
      1. [Lata,Longa,Altitudea; Latb,Longb,Alttudeb; ...]
  7. Receiver Location Error - a nx3 matrix denoting station location error in the form [dLat,dLong,daltitude].
  8. Time Difference - kxm matrix denoting all time differences in the form: [Ta with b-z; Tb with c-z; etc].
    1. Given 3 stations, a, b, c. The time differences are:
      1. [Tab; Tac; Tbc;] in units of microseconds
  9. Time Difference Error - a kxm matrix denoting every time difference error between each station in the network.
  10. Absolute Times - Continuous string with , delimintor between each time value. Times are of form YY:MM:DDTHH:MM:SS.XXX:+YY:ZZ where YY:ZZ represent offset from Greenwhich mean time.

n represents the number of stations. M the number of points in the ground track. K the number of unique time differences, calculated from the number of stations.

The number of bytes sent is:

  1. 4 bytes for each of 3 integers

$8 bytes for 6 + 3*n + 4*n + 2*k*m

For our setup, n=3.

TDoAwithTCPin.m is an executable and can be found under FeasibilityStudies git repository in the TdoaSim branch.

We currently run TDoAwithTCPin.m in a Matlab instance on the RIT server instead of using the executable. We have not figured out how to get Linux to use the executable. It works in Windows.

Test Results Summary

Summarize [[[Problem Definition Documents/Requirements and Testing.xlsx | test results]]] and assess effectiveness of test plans to unambiguously demonstrate satisfaction of the engineering requirements

Test 11 - Extreme Heat and Cold

Room Temperature Data Collection

A preliminary test was performed to simulate our electrical housing in order to get a sense of how much heat our system will produce. This preliminary test gives information about whether or not we will need to provide cooling to the system. The end result of this test is to find the change in temperature, from ambient, of our system. We used Lightbulbs of differing wattage and a small steel toolbox to simulate our system. By using a thermometer, we are able to collect the room temperature and the temperature inside the box. Once the thermometer reach a steady state, we recorded the data. We covered a wide range of wattage, from 4W all the way to 90W. These data points will allow us to create a trend line, which we can then use to predict our actual enclosure temperature, based on the power output of our system.


 Collected Temperature Data.

Collected Temperature Data.

To calculate the power draw, we used the product of voltage and current, rather than trust the wattage on the lightbulb. These power numbers then became the x data points for the curve.

 Data and Trend Line used to predict the temperature of our enclosure when hooked up to our electronics.

Data and Trend Line used to predict the temperature of our enclosure when hooked up to our electronics.


After wiring all the electronics (Low Noise Amplifier, Raspberry Pi, Hack RF, and Uninterrupted Power Supply), we measure the power output with a wattage meter. We found this value to be 21.762W. Using this value, along with our trend line, we are able to linearly interpolate to find the the change in enclosure temperature due to our system. This turned out to be about 16 degrees Fahrenheit, which gives a final enclosure temperature of 86 degrees Fahrenheit for this test.

Test 10 GPS Accuracy

Our current iteration of this test uses a GPS attached to a Raspberry Pi indoors. We recorded GPS data for 13 hours with the GPS located in the EE Senior Design Lab.



The GPS data roughly follows a Gaussian for Latitude, Longitude, and Altitude. The highest error was in Altitude, which is expected for a GPS. All errors should decrease when we place the GPS outdoors.
 GPS histogram data for 300,000 points. Y axis represents a normalized frequency.

GPS histogram data for 300,000 points. Y axis represents a normalized frequency.

This video shows the results of the test.

Test 40 and 41 - TDoA Software

These are integration tests to verify the TDoA program suite is working correctly. The test is not completed in its fullest.

What we have so far:

  1. Unit tests included in the TdoaSim/TestScripts folder in the Feasibility Studies branch of our git repository.
  2. Integration tests for basic functionality.
  3. Integration test proving TCP communication.

For TCP communication, we use a Java class as a proxy server that sends its data to Matlab. It sends 4 access times and the associated simulated TDoA data for those access times. The simulated data is entirely made up right now.

This video shows the results of the test.


  1. Open 2 terminals
  2. In 1st terminal
    1. In the MSD Feasibility Studies, TdoaSim branch...
    2. Run: git status.
    3. Run: git pull, if necessary
    4. cd into ./TdoaSim/TestScripts
    5. Run: javac Server.java
    6. Run: java Server
  3. In the 2nd terminal
    1. In the MSD Feasibility Studies, TdoaSim branch...
    2. cd into ./TdoaSim
    3. Type: module load matlab
    4. Run the following command:

matlab -nodisplay -nojvm -r 'TDoAwithTCPin(char("filename")); exit;'

Note: you may need to retype each ‘ and “ in the command window.

-nodisplay, -nojvm will prevent Matlab from trying to open a GUI. The exit returns control back to the command line at the end of execution. Char(“filename”) was the only way Anthony could figure out how to input a char array into Matlab via the command line...there might be a better way.

filename does not need any kind of file extension on it.

Additional Note: The socket closed exception thrown in the java program is of no concern. The Java server was originally written to receive TCP data as well. The Matlab program is not sending any data back to Java.


We successfully had Java send data to Matlab over a TCP connection. Matlab read that data correctly, ran TDoA, and outputted a text file of the proper output. The output can be seen here

Lessons Learned

Programming languages and operating systems read bytes differently. Java reads bytes in the opposite order that Matlab does. We were originally getting the double 5.4343 read as 1e-293 in Matlab. We fixed this problem by flipping the 8 bytes that represented this double before reading in Matlab.

We know the first integer to the TDoA program is an integer. We try reading in both the forward and reverse direction. We throw an error if we fail to read a 0,1,2 on either direction. Otherwise, we continue reading in that direction. This should allow the program to be run regardless of the program / operating system used.

Strings sometimes come with a '\n' at the end, which can be unexepected or undesired. The last time we read had a \n messing up the spacing in the text file. We manually remove this.

Next Steps

We must verify we can call the matlab program from the C++ "main program". We should change the data to represent realistic ground track data. We should consider playing with getting the executable to work so the user does not need to install matlab.

Risk and Problem Tracking

 Updated Risk Management

Updated Risk Management

 Updated Problem Tracking

Updated Problem Tracking

Functional Demo Materials

Plans for next phase

Three Week Plans

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation