sammmlow/leogps

:earth_asia: :satellite: :earth_asia: :satellite: LEOGPS - Satellite Navigation with GPS on Python!

leogps's Issues

To-Do: Single Satellite Precise Orbit Determination 🛰️ 🌠

🧠 🧠 🧠 Future work: to include single-satellite cases 🛰️ . The GUI should offer to the user the option of choosing single satellite processing (precise orbit determination) or dual satellite processing (relative navigation via double differencing).

To-Do:

• Statistical orbit determination module
• Options for inclusion of pseudorange or carrier phase or both

Functionality to adjust GUI

Is there a way to adjust the GUI or to enable scrolling? Currently the GUI is cutoff at 40% height ("Set window length for cycle slip detection filter") on my machine. Resizing the GUI also does not resolve the issue.

🌏 ❤️ LEOGPS v1.2 Pre-release Goals (Spoiler Alert)

Goal 🎯 : Build a feature that enables relative orbit plotting.

Feature 👁️ : Allow the plot to be displayed directly on the LEOGPS GUI, in Hill Frame coordinates after RSN.

Requires 🧠 : More formation flying RINEX v2 files for validation of RSN and plotting accuracy.

To-Do: Processing Statistics 📊

🧠 🧠 🧠 Future Work: Inclusion of the processing statistics, such as pseudo range residuals, carrier to noise ratios, number of satellites in view, time series plot of which frequency signals were received.

To-Do: Ground Track and Orbit Visualization 🌍 🌎 🌏

🧠 🧠 🧠 Future Work: With the implementation of the coordinate frame transformation, tools are now available to perform both an orbit (ICRF) visualisation as well as a ground track (ITRF) visualisation.

• Optional add-ons: zoom-able maps will be nice.

Large Oscillatory Position Errors After Receiver Clock Sync

Current solutions tested on GRACE A/B formation flying satellites, exhibit positioning errors from pseudo-range solutions on the order of ~100m, and relative navigation inaccuracies in double digit centimeters. This is two orders of magnitude worse off than expected from typical precise orbit determination results used as a comparison. Ephemeris errors accruing from the orbit interpolation of the GPS satellites seem to be responsible. Current orbit interpolation uses an 11th Order Lagrange Polynomial Interpolation. A review of current range measurement modelling, and the setup of the non-linear least squares, should be conducted.

To-Fix: GPS Antenna Offsets 📡📡 📡

⚠️⚠️⚠️ Caution: Do not apply GPS antenna offsets as of v1.3 (pre-release). ⚠️⚠️⚠️

GPS antenna offsets should be done in the spacecraft body frame. However, currently as LEOGPS has no feature to read in spacecraft attitude coordinates, it will not be able to tell the orientation of the spacecraft and thus applying GPS antenna offsets using XYZ coordinates in the orbit frame is erroneous. For now, this has been (conveniently) cast to future work, and users are advised not to set any non-zero offsets. The input box in the GUI has also been closed. Thus, all coordinates computed in LEOGPS of the spacecraft(s) are not of the spacecraft center of mass, but of the GPS antenna phase center.

Robustness against dropped data

Hi!

I have a situation where my GPS receivers log data at 1 Hz, but with infrequent data corruption (0.1% of the time or maybe 1 second of drop every few minutes out of collection of 4 hours), resulting in some dropping of PVT data.

Issue: Current LEOGPS cannot proceed with data with 0.1% droppage.

Solutions:

1. Either increase timestep parameter in GUI, which might affect accuracy
2. Preprocess RINEX observation file and interpolate before processing in LEOGPS. Currently testing this via Bernese RNXSMT. From the manual, RNXSMT corrects for cycle slips. I'm not sure if it is able to correct for missing time step data?

The function that is not robust against dropped data is phasep.ph2fil() in line 611 of phasesep.py. The hatch filter requires comparison to the data 1 second before, even if the selected timestep is greater than 1 second.

Any other suggestions on how to deal with this? Any suggestions also to preprocess RINEX observation file for input into LEOGPS?

🔢 Actually resolve integers

Current LEOGPS basically performs pseudorange double differencing. Should eventually move towards carrier double differencing with IAR.