Add satellite health flag

[plutonheaven]

Check if the flags contained in the RINEX NAV message corresponds to the NANU.

For example, NANU 2024007 mentions that satellite G27 was unusable between 2023-12-30 11:07 and 2024-02-02 18:52.
This satellite has indeed large code observation residuals (several hundreds of meters...)

[jtec]

The way to go here might be

• write nav message health flags to prx CSV
• find or code a NANU parser (the more recent ones have a first section with start/end times etc. that looks pretty easy to parse (https://celestrak.org/GPS/NANU/description.php)
• plot nav message unhealthy vs NANU unhealthy stats

It's actually another example of the usefulness of prx as it simplifies access to the nav message health flag.

[jtec]

We might want to double-check how prx decides which nav message it uses here.

@plutonheaven Would it be a good criterion to start using a nav message starting at message transmission time? We could add a duration to account for message length + time of flight + decoding etc. but do we have the information we need to quantify that?

What is the time we want here? I'd say it's the earliest possible time the receiver that is the source of the obs data would be able to use the new message, correct?

[plutonheaven]

* write nav message health flags to prx CSV
* find or code a NANU parser (the more recent ones have a first section with start/end times etc. that looks pretty easy to parse (https://celestrak.org/GPS/NANU/description.php)
* plot nav message unhealthy vs NANU unhealthy stats

I think it is a good idea to validate it. However, it may happen that the health flag is set to 'do not use' without a NANU (or with a delayed NANU), so we may have to chose which NANU to use as reference for test.

We could also look at the observation residuals of a unhealthy satellite and check that they are above a threshold. But again, it may happen that the GNSS control segment is not able to react fast enough to set the health flag to 'do not use' as soon as the anomaly appears.

[plutonheaven]

We could add a duration to account for message length + time of flight + decoding etc. but do we have the information we need to quantify that?

This is quite tricky because the delay due to decoding depends on the reception condition of the signal. E.g., if there is an interruption of visibility, the receiver may loose a whole portion of the message, and would need to wait for the next repetition of that portion, which is several seconds and which depends on the nature of the data and on the navigation message type (LNAV, CNAV...).

In reality, in a real data collect, we could use the RINEX NAV file as recorded by the receiver, and therefore, we would have the real availability of the NAV message.

But currently, we "cheat" with prx by downloading the BRDC file, which is computed by post-processing data from several IGS stations. We therefore have the ideal NAV message.

All this is further complicated if we assume that the NAV data can be downloaded on internet (eg in a smartphone GNSS chip).

I would say to keep it simple, and just consider the latest NAV data with a transmission time before the observation epoch.

[jtec]

We could add a duration to account for message length + time of flight + decoding etc. but do we have the information we need to quantify that?

This is quite tricky because the delay due to decoding depends on the reception condition of the signal. E.g., if there is an interruption of visibility, the receiver may loose a whole portion of the message, and would need to wait for the next repetition of that portion, which is several seconds and which depends on the nature of the data and on the navigation message type (LNAV, CNAV...).

In reality, in a real data collect, we could use the RINEX NAV file as recorded by the receiver, and therefore, we would have the real availability of the NAV message.

But currently, we "cheat" with prx by downloading the BRDC file, which is computed by post-processing data from several IGS stations. We therefore have the ideal NAV message.

All this is further complicated if we assume that the NAV data can be downloaded on internet (eg in a smartphone GNSS chip).

I would say to keep it simple, and just consider the latest NAV data with a transmission time before the observation epoch.

I agree with that last statement!