LEOGPS - Satellite Navigation with GPS on Python!

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.

Previous usage of '\' character conflicts with UNIX file format. Used os.sep to delineate file path for both Linux and windows ( likely MacOS as well) .

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.

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.

Hi! I recently created a carefully packaged and wrapped version of the RNXCMP tools in Python as the Hatanaka library. It simplifies the installation and usage of the tools and also makes sure any errors are raised as proper exceptions and warnings as Python warnings. In addition to the Hatanaka decompression it can also take care of the .gz/.Z compression usually applied on top of Hatanaka compression.

I thought you might find the library useful as well. It should make sharing using of this library quite a bit simpler, I hope, as it gets rid of the need to bundle the crx2rnx and gzip executable. One caveat, though, is that it sets the minimum Python version to 3.6+, but I doubt it's an issue since Python 2 has been EOL-ed for a while now.

Hello again, This PR is a small follow-up to #2, which replaces the unlzw3 LZW (.Z file) decompression with the new ncompress library. It's about 40x faster than unlzw3, which is quite noticeable when some of the 10 MB RINEX files take multiple seconds to decompress with unlzw3, and it's already installed transitively with hatanaka anyway.

Issue: Saving to 1 input and 1 output clutters the folder environment

Proposed solution: With 1 campaign name, save input and outputs like so input output | | | | campaign name campaign name

Note: I'm not sure if this is most efficient. Maybe making the "campaign name" the parent folder instead of child folder would be easier. Following the Bernese campaign file hierarchy? In that case changes are only repositioning the directory names in gpsxtr.py, leorun.py, leogui.py, pubplt.py and rnpath.py

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

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

🧠 🧠 🧠 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

⚠️⚠️⚠️ 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.