It may be interesting to let the user provide the NAV file together with the OBS file, e.g. to verify time to first fix in a constrained environment leading to difficulty to demodulate the Navigation Messages.

PRX currently download the NAV files from IGS servers, and therefore has always access to well-formatted files. Letting users provide their own files may break a few assumptions that we are making by using IGS files.

If we let other NAV files possible, careful check should be performed, for example by running additional options with gfzrnx.

I have difficulties to use functions from the submodule georinex.

The file directory of my PyCharm project is

prx
|_ lib
    |_ georinex
|_ minimumLovablePrototype
    |_ processing_ephemerides.py

In processing_ephemerides.py, I imported the georinex module using import lib/georinex as gr
But when i call gr.load(path_to_rnx3), I get an error :

AttributeError: module 'lib.georinex' has no attribute 'load'

I was able to call gr.load() outside my PyCharm project, in a simple python3 session, by calling in Terminal

pip3 install georinex
python3
>>> import georinex as gr
>>> nav = gr.load('/home/paul/PycharmProjects/prx/datasets/TLSE_2022001/BRDC00IGS_R_20220010000_01D_MN.rnx')

I assume I don't do a correct import of the submodule. This is maybe because it is present in a parent folder, however, PyCharm seems to validate my call, and does not like when I tried from ..lib import georinex (as read from stackoverflow)

The code is in 82b42a5. Any suggestion @jtec?

See #70 (comment)

Also do #70 (comment)

See https://github.com/jtec/prx/actions/runs/8395568833/job/22995108828

The unit tests we have today test specific sets of inputs such as "Compute position of G02 at time t and compare to sp3 precise position".

Property-based testing takes this approach a step further. It allows us to formulate tests of the type "For a test within the set of existing satellites, and for a time within t0 and t1, the error between broadcast and sp3 position is always lower than 10 meters".

The testing framework then tries to find test inputs within the set of admissible inputs that break the code.

See e.g. https://semaphoreci.com/blog/property-based-testing-python-hypothesis-pytest

The name of the parameters computed by PRX should be

• explicit (to be recognized by someone working on GNSS)
• model-agnostic
• contain the unit

For example, the parameter

• x_m is not explicit enough
• iono_delay_klobuchar_m is not model-agnostic

See commit history on https://github.com/jtec/prx/commits/jtec-patch-1/ for various attempts to fix this.

Once fixed, https://github.com/jtec/prx#modulenotfounderror can be removed.

There is no executable of GFZRNX for Windows and the call to other binaries does not create an error (returncode = 0).

There is also the issue of the annoying pop-up when executing a command like gfzrnx_2.0-8219_lx64 in the Windows terminal.

One consequence is that parsing some NAV files result in some errors due to missing trailing spaces for some ephemerids (e.g. NAVIC)

Running a benchmark on orbit and clock computations seems like a good start, as that is where prx spends most of its time right now.

We can use https://github.com/marketplace/actions/continuous-benchmark

Some corrections are computed assuming a receiver position. This information should be provided in prx.

I think the default position that we consider is the rx position from the header.

NAV files older than 2023-01-01 from the BKG http repo do not contain the iono correction in their header. We may want to find other repositories with such information, or be tolerant to missing header information.

Side note: the name for files older than 2023-01-01 change from BRDC00IGS_[...] to BRDC00WRD_[...].

We need movement to unit-test the Doppler observation (by estimating antenna velocity) and carrier phase outputs (by estimating displacement between epochs with carrier phase time differences) of prx. Without antenna displacement, sign errors are not observable.

NAVIC ephemerides, being Kepler orbits and second-order clock models, might work out-of-the box, but we need a test for them. That includes testing

• Position
• Velocity
• Clock offset
• Clock offset rate
• Group Delays, if any

Let's add a unit test that

• runs a RINEX observation file through prx
• parses the generated CSV file
• computes the LSQ PVT solution
• compares to the expected solution
  • what would we compare the T to? Clock-steering receiver, so small?

Fancy version: use a station where >= 4 satellites of all constellations are visible (e.g. Japan), parameterize the test with a set of constellations to use and run for

• all constellations
• each constellation separately

This data is already present in the RINEX OBS file and just has to be written by prx.

It was done in #31, but the large refactoring lost the feature.

There is a health flag that is transmitted in the broadcast navigation message.

We could add it as an additional column, or just discard the observations of the satellites with do not use status.

Sytem Time Offset (RINEX 4) or Time System Corr (RINEX 3) are specified in RNX NAV files.

We could add this as an additional parameter, to ease the PVT computation by having to estimate only a single clock offset (usually RX time to GPST).

The ephemeris file discovery only consider a single ephemeris file, while sometimes the observations span several days.

Notably, this happens when dealing with an observation received at midnight (time of reception), which would have a corresponding time of emission on the day before.

This bug was addressed in #32, but the large refactoring effort lost this modification.

prx will only support Kepler orbits after this PR is merged.

Processed 15' 1Hz IGS station obs file today, with RINEX parsing covered by disk cache, in 02'37s (on Mac M2)

A processing speed of around 60 - 1 hour of data in 1 minute - would be nice.

Measuring code coverage will allow us to spot untested parts of the code, and in the long run improve it's correctness, which is what prx is all about.

Many projects put in place a coverage threshold, I think this turns it from a useful tool into something "we need to do" though, and lowers the likelihood of people contributing. I see no problem with merging PRs that have low coverage and enhancing coverage, possibly across the whole code base, in later PRs.

e.g.

[packages]
numpy = "*"
pandas = "2.0.3"
pytest = "*"
georinex = "1.16.1"
gnss-lib-py = "0.1.8"

in Pipfile

and running pipenv install

leads to

 "gnss-lib-py": {
            "hashes": [
                "sha256:5fcd7681e44a2ea15a9697e7cc31c377f03b266186a499e8774311e394d377cd",
                "sha256:ad665fb083cefc777c94c354dcb5b254c68d2940b718fe556ab60ba8f9293e9a"
            ],
            "index": "pypi",
            "version": "==0.1.11"

in Pipfile.lock

I think it'd be great if prx can directly parse Android Raw measurements for pr/doppler/cp/cn0 logs, and Android navigation messages for ephemeris on supported phones.
Many new mobile phones now support nav messages too, which can be logged using GnssLogger App. Parsing this data directly from GnssLogger App .txt log is important, as GnssLogger miss some info when it logs rinex obs file - for example logging only dual band on triple band phones. Also, I found no lib until now that parses android navigation message from logs.

I would be opening similar issue in https://github.com/geospace-code/georinex too, but I think it's more related to prx than georinex

What if we copy the observation file in a new folder and add everything associated to the processing job: nav files, intermediate files, generated prx file, log files. For the folder name (job id) hash the file provided by the user.

When time-differencing observations, and removing terms due to satellite motion and clock offset change it is important to know the IODE and IODC, since consecutive broadcast ephemerides are not continuous.