P20151: Satellite Localization
/public/

Preliminary Detailed Design

Table of Contents

Your website should document your journey through MSD, so include work-in-progress as well as latest results. Use pdf's for display whenever possible so that information is easily viewable without the need to download files and open applications. (Your EDGE file repository should still contain original editable files).

Content related to this node should go in the Detailed Design Documents directory unless you have made other arrangements with your guide ahead of time.

All template text must be removed prior to your Preliminary Detailed Design Review

Team Vision for Preliminary Detailed Design Phase

Our Plan

Prototype our antenna and create algorithms for TDoA and Orbit Determination. In order to accomplish this, we planned on:

Once all of this is complete, we will have to refine our Bill of Materials and begin our Network Architecture.

Our Accomplishments

The following describes what we actually accomplished during the Preliminary Detailed Design Phase:

Feasibility: Prototyping, Engineering Analysis, Simulation, Flow Charts, and Schematics

Signal Acquisition

Issues

Solutions

The list of satellites we are planning on testing with can be found Here

Antenna Prototyping

QFH

 QFH Antenna Prototype

QFH Antenna Prototype

Mark 1
Mark 2

The 2nd version of the QFH antenna was tested for reflection (S11) on a network analyzer. The antenna exhibited less than ideal reflection at the target frequency, with the best reflection being slightly higher (about 440MHz) at -20dB.

 Network Analyzer Test for Reflection S11 QFH Antenna

Network Analyzer Test for Reflection S11 QFH Antenna

Double Turnstile

 Turnstile Antenna Prototype

Turnstile Antenna Prototype

Below are 3D model images of the double turnstile:

 Isometric Top View of Turnstile Antenna

Isometric Top View of Turnstile Antenna

 Isometric Bottom View of Turnstile Antenna

Isometric Bottom View of Turnstile Antenna

Mark 1
Mark 2

The 2nd version was modeled in GNEC and tested for reflection (S11) on a network analyzer. The reflection characteristics where not favorable because of connector losses (impedance discontinuities). The GNEC simulation yeilded a favorable radiation pattern (approximated the expected results).

 Network Analyzer Test for Reflection S11 Turnstile Antenna

Network Analyzer Test for Reflection S11 Turnstile Antenna

 GNEC Render of Turnstile Antenna

GNEC Render of Turnstile Antenna

 GNEC Radiation Pattern Plot of Turnstile Antenna

GNEC Radiation Pattern Plot of Turnstile Antenna

Antenna Power Ratio Analysis

To determine which antenna type we should use, preliminary analysis was performed to find the received power of each antenna vs. the elevation angle of the satellite. Ideally, the chosen satellite will have a high power ratio at all elevations, ensuring a strong received signal from horizon to horizon. Right now, we are comparing the QFH, Turnstile, and Parasitic Lindenblad antennas. Radiation patterns of each are shown below:

 Gain Radiation Patterns for QFH, Turnstile, and Parasitic Lindenblad Antennas

Gain Radiation Patterns for QFH, Turnstile, and Parasitic Lindenblad Antennas

The sources for these patterns are:

We cannot figure out the "best" antenna solely from the antennas radiation patterns since this does not take into account the satellite's distance away from the antenna. For every flyby, the satellite will be much closer to the antennas at 90 degree elevation than at the horizon. To do this, we use Friis Transmission Equation:

 Friis Transmission Equation

Friis Transmission Equation

which assumes no reflection, no polarization loss, and lossless antennas.

Using the Friis equation, a crude approximation was done, plugging in discrete gain values from each antenna's radiation pattern and linearly interpolating satellite distances from a simulated satellite flyby. The power plots for the QFH, Turnstile, and Parasitic Lindenblad is shown below:

 Power Ratio Plot

Power Ratio Plot

From this, we can see that because of the great distance away from the satellite, all antennas have poor received power near the horizon from about 0 to 40 degrees. The next step for us is to determine how crucial this 0 to 40 degree range- or how often satellites that flyby in Rochester have a maximum elevation in this range. If the majority of satellites have a max elevation in this range, we will have to seriously consider this. This will be performed in the next phase by simulating different satellites in Orekit and propagating their orbits over a year.

Extracting Time Differences from the Signals

We are researching how to take signals from the ground stations and calculate time differences. Cross Correlation

Symbol Detection

Engineering Scenario Study

Setup:

Crosscorrelation Method

Symbol Searching Method

Next Steps:

  1. Look into ASK (amplitude shift key) modulation and develop ASK algorithm
  2. Test ASK modulation on test data
  3. Create and test the unique symbol search algorithm
  4. Check frequency of unique symbols in test data
  5. Possibly adjust symbol size and modulation
  6. Time the unique symbol search algorithm
  7. Test algorithm on two data sets from different locations looking for the same symbol
  8. Cross correlation - run cross correlation on two data sets from two different locations
  9. Compare the results of the two methods
  10. Increasing the SDR sample rate will give us a smaller time resolution

Network Architecture

Each of the 3 stations will use a Raspberry Pi 4.0 Model B.

The connection method is dependent on where the stations are placed.

Close Stations

  1. Ethernet
  2. TCP socket connection
  3. Raspberry Pi max transmit is 50 MBps
  4. ~0.5 Mbps signal data per station
  5. Use cross correlation or symbol detection to detect time differences

Far Stations

  1. Likely paying for 4G
    1. High transmit rate is expensive
  2. Need to use symbol detection to detect time differences, since this required less bandwidth

Messages

The format of the messages to be sent between the main server and the ground stations is shown in the figure below.
 Message Format

Message Format

The command messages, sent from the main server to the grounds stations were defined as follows:

 Command Messages

Command Messages

The response messages, sent from the ground stations to the main server were defined as follows:

 Response Messages

Response Messages

Time Difference Of Arrival Algorithm

In this phase, we started building the Time Difference of Arrival (TDoA) algorithm from the ground up. We chose to create our own software for the following reasons:
  1. Learn and better visualize the geometry.
  2. Our unique problem condition: stations in a plane finding something far out-of-plane.
  3. We are finding a direction in 3D instead of a point; most TDoA softwares in 3D require 4-5 stations, we are using 3.

The program is written in Matlab. See our github page for the code. Below is a high level flowchart of the TDoA algorithm.

 High level flowchart of the TDoA algorithm

High level flowchart of the TDoA algorithm

It takes an input of receiver locations, the distance differences (calculated from the time differences), and the planes to solve the problem on.

The algorithm takes the receiver locations and distance differences to create 3 hyperboloids. It then takes a slice of these hyperbolas at the specified planes ands finds the geometric center of the smallest area enclosed; this is the likeliest area of the emitter on that plane.

After solving multiple planes, the algorithm estimates the direction. Two hyperboloids intersect on a hyperbola. Far from the foci of the hyperbola, it can be approximated by a line. It is this line that we find and call the "direction". This is an approximation; error increases if the zPlanes are near the foci of the hyperbola. The figure shows the resulting hyperbola from intersecting 2 hyperboloids.

 The Intersection of 2 hyperboloids is a hyperbola. We approximate the intersection as a direction, or line. This is a good approximation for a satellite, which is far from the hyperbola foci.

The Intersection of 2 hyperboloids is a hyperbola. We approximate the intersection as a direction, or line. This is a good approximation for a satellite, which is far from the hyperbola foci.

 Measuring the hyperboloids from an Earth Fixed frame, the algorithm outputs the red direction. The purple direction is correct. The green dot is the satellite.

Measuring the hyperboloids from an Earth Fixed frame, the algorithm outputs the red direction. The purple direction is correct. The green dot is the satellite.

The TDoA algorithm can solve for the direction in both an Earth Fixed Frame and a Topocentric Frame. See Furgale et al. [1] for an introduction on the various frames.

 Frame definitions in Astrodynamics. Image taken from Furgale et al.

Frame definitions in Astrodynamics. Image taken from Furgale et al.

Using the TDoA Algorithm on Ground Tracks

The TDoA test code can turn a simulated ground track into time differences at discrete points. These can then be fed into the TDoA program to evaluate the accuracy and sensitivity of the algorithm for realistic satellite inputs.

Currently, the program can solve for the satellite direction within 0.3 degrees. The error distributed across a crude ground track is outlined below:

 The green dots are the crude satellite ground track. The red line is the predicted direction of the satellite. It has an error of 0.00175 deg error in azimuth and 0.7 degree error in elevation. There are no input errors in receiver location or time differences.

The green dots are the crude satellite ground track. The red line is the predicted direction of the satellite. It has an error of 0.00175 deg error in azimuth and 0.7 degree error in elevation. There are no input errors in receiver location or time differences.

 Over the crude ground track of 0, 30, 60, 90 degrees of elevation, the TDoA program can predict the direction within 0.002 degrees error in azimuth and 0.7 degrees in elevation.

Over the crude ground track of 0, 30, 60, 90 degrees of elevation, the TDoA program can predict the direction within 0.002 degrees error in azimuth and 0.7 degrees in elevation.

Please see the TDoA Presentation, progress reports below and the algorithm documentation/comments on github for more specifics on how the code works.

[1] Furgale, Paul & Enright, John & Barfoot, Timothy. (2011). Sun Sensor Navigation for Planetary Rovers: Theory and Field Testing. Aerospace and Electronic Systems, IEEE Transactions on. 47. 1631 - 1647. 10.1109/TAES.2011.5937255.

TDoA Progress Reports

These slides include detailed information on the algorithm as well as paint a story of the development of the TDoA algorithm throughout this design phase. TDoA Progress Reports: 10/22, 10/29, 11/12

Simulated Ground Tracks Using Orekit

During this phase, we started to learn how to use Orekit to simulate ground tracks. Orekit is a Java library developed by the CS Group that contains many functions to both simulate satellite orbits and perform orbit determination.

To support the TDoA algorithm validation, Orekit was used to create a simulated ground track of a satellite flying over Rochester. In the program, three ground stations were defined and the latitude and longitude of a satellite when it was in view of all three stations was obtained. This data is sent to a text file which can be read into MATLAB. The image below shows a simple flowchart of the simulated ground track process.

 High level flowchart of the Orekit Ground Track Simulation

High level flowchart of the Orekit Ground Track Simulation

From this information, expected time differences can be solved backwards for, and these time differences can be plugged back into the TDoA algorithm to see if the expected latitude and longitude values are recovered.

Orekit has proven to be a useful tool in the validation process, and next we will need to learn how to use it to perform orbit determination. It is a well known tool for space dynamics professionals and has a high likelihood to be used for our orbit determination once we have TDoA data.

Bill of Material (BOM)

Since we need a backup ground station, the budget was increased to account for 4 ground stations instead of 3. Since the design is still in progress, speciic items were not selected during this phase.

 Bill of Materials

Bill of Materials

Test Plans

Surviving Extreme Heat/Cold

GPS Location and Time Calibration

Wind Proof

Testing Orbit Determination

Water Proof

Network Connection

Antenna Testing

Requirements Verifications and Compliance Matrix

The RVCM is a way of defining which engineering requirements are related to each customer requirement. In this respect, it is similar to the House of Quality. However, it also describes how these customer requirements will be met, and how they will be tested. There is also a section determining what makes the test successful.
 Requirements Verification and Compliance Matrix

Requirements Verification and Compliance Matrix

Requirements Verification and Compliance Matrix

Risk Assessment

Risk Management Part 1

Risk Management Part 1

Risk Management Part 2

Risk Management Part 2

Link to Risk Assessment Working Document (Excel Sheet)

Our three highest risks are the error of TDoA, interfering signals at the 437 MHz range, and the budget. The uncertainty in our TDoA calculations needs to be estimated as soon as possible, because this uncertainty will affect the accuracy of the orbit determination. If the TDoA uncertainty is too high, then the OD accuracy may fall out of our engineering requirements. In the next phase, we will have to figure out the uncertainties of TDoA and OD because it will decide the required distances between ground station and SDR sampling resolution required.

Next, we need to make a proof of concept antenna at 437 MHz to see if we can actually receive a satellite signal with an omnidirectional antenna. It is possible that other signals could drown out satellite signals and make them unrecognizable.

Lastly, our budget will affect the quality the SDRs and other related equipment that we can buy. This will affect how accurate of an OD calculation we can get. Our most common risks are technical and resource related. Although technical risks have a low likelihood the severity of the risk is very high. The most concerning resource related risks are in reference to our current budget, this will require thorough planning to avoid unnecessary spending. live document.

L3Harris Sponsor Proposal

Design Review Materials

Before the Preliminary Detailed Design Review, the pre-read and presentation were sent out.

The feedback we received after the review are documented in our Feedback document.

Plans for next phase

At the end of the phase, each team member reflected on the phase and created a plan for the Detailed Design.

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

https://creativecommons.org/licenses/by-nc-sa/4.0/


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