GLONASS frequencies from RINEX observation file

[ourairquality]

Describe the bug

Finding that GLONASS is excluded with the reason failPrange or obs.failurePrange. prange() is failing due to a lacking of lambda entries which appear to be set by updateLamMap() and which uses geph.frq and which appears to be filled from RINEX nav data.

The RINEX input also fills in the nav.glo_fcn[] but this does not appear to be used by updateLamMap() and it would appear that this could be usefully used to supply the lambda values, and might that allow GLONASS to be used in ppp solutions without also supplying broadcast nav files.

Supplying RINEX broadcast nav files did get past this issue.

To Reproduce

Steps to reproduce the behavior:

1. Using ppp_example which now has glo enabled, but with the satellite_data nav_files commented out and not enabled, and using an observation RINEX file that defines the "GLONASS SLOT / FRQ".
2. Note the lack of GLONASS satellites used in the solution.
3. With tracing enabled, note the reason being failPrange.

Expected behavior

It would appear that the RINEX "GLONASS SLOT / FRQ" information could be used to determine the lambda values and then broadcast nav data would not be needed.

Configuration files

ppp_example

Operating environment (please complete the following information):

• Version of Ginan: 2024-10-25

[ourairquality]

Related issue with RTCM3 as a source is that MSM5 and MSM7 have the GLONASS frequency shifts in the extra info, and this does appear to be be used in the decoder, but that use appears to be local to the decoder and might that not work as expected for GLONASS MSM4 and MSM6. For MSM5 and MSM7 could the frequency shifts be usefully used outside of the RTCM decoder. Also geph.frq is set from M1020 but do prominent receivers send this info in 1020.