Possibly malformed RINEX 3.x .nav file trips up propNavMsg

[ammtc]

The following RINEX 3.03 .nav file comes from a real receiver and was gathered during a live drive test. For Galileo satellite E07, it appears to contain two pairs of nearly-identical duplicate entries—each pair has identical Toc, Toe, IODE, and IODC, with only TTOM different:

20200207_propNavMsg_testcase.nav.txt

Importing this with loadRinexNav and then passing the resulting ephemeris struct to propNavMsg results in the ECEF coordinates of E07 being all NaNs, at least at any timepoint I checked for which the ephemeris should be valid. (In fact, all fields in the output corresponding to Galileo SVs are full of NaNs.)

For debugging, the following RINEX .nav file, for the same day, comes from the IGS broadcast ephemeris archive. Using this file in place of the first one produces valid results for all Galileo SVs, so there does NOT appear to be any problem with the orbital math per se:

20200207_propNavMsg_testcase_full-IGS-R.nav.txt

[ammtc]

A bit more digging: the issue appears to be caused by the contents of one or two (possibly corrupted?) values in the first .nav file above, specifically the "Data sources" and "SV health" lines (in RINEX 3.03, see Table A8 / Broadcast Orbit - 5 and 6, respectively).

The first file above appears to have suspicious values in both fields, particularly since they are never identical within a single SV block in the second file, but always identical in the first.

I've sent a query to the source to figure out if this is a real glitch (e.g. due to a bug in the receiver firmware) or something introduced in the process of converting the receiver's raw output (proprietary binary) to RINEX. I'll post a followup comment here when I have an answer.