You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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.
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
The text was updated successfully, but these errors were encountered: