ephemeris selection (seleph)

[plutonheaven]

I am trying to compare my own satellite position computation to the one performed by rtklib. I see a difference for a single satellite (G15), which is due to a different ephemeris selection.

I paste here the content of my RINEX NAV file:

G15 2024 06 24 07 59 44 1.736045815051e-04 4.206412995700e-12 0.000000000000e+00
     4.000000000000e+00-9.028125000000e+01 4.785199322759e-09-6.493624923029e-01
    -4.604458808899e-06 1.573454437312e-02 9.842216968536e-06 5.153677450180e+03
     1.151840000000e+05-1.396983861923e-07-2.820946273747e+00 1.899898052216e-07
     9.359883245393e-01 1.812500000000e+02 1.319706711607e+00-8.354633718315e-09
     3.239420649158e-10 1.000000000000e+00 2.320000000000e+03 0.000000000000e+00
     2.000000000000e+00 0.000000000000e+00-1.024454832077e-08 4.000000000000e+00
     1.146660000000e+05 4.000000000000e+00                                      
G15 2024 06 24 08 00 00 1.736055128276e-04 4.206412995700e-12 0.000000000000e+00
     1.120000000000e+02-9.028125000000e+01 4.785556480493e-09-6.470286903135e-01
    -4.604458808899e-06 1.573454204481e-02 9.842216968536e-06 5.153677459717e+03
     1.152000000000e+05-1.396983861923e-07-2.820946398095e+00 1.899898052216e-07
     9.359883245393e-01 1.812500000000e+02 1.319706609203e+00-8.354633718315e-09
     3.239420649158e-10 1.000000000000e+00 2.320000000000e+03 0.000000000000e+00
     2.000000000000e+00 0.000000000000e+00-1.024454832077e-08 1.120000000000e+02
     1.080180000000e+05 4.000000000000e+00

There are two close Clock, Ephemeris, Integrity (CEI) data sets. The observation for which I need to get the satellite position is at 08:20:00.

I would expect to select the second CEI data set, but rtklib selects the first one.
To my understanding, rtklib use the difference between the transmission time and the ephemeris toe (1st param on 3rd line of the NAV block), and find the one with the smallest absolute value. However, this should not result in the selection of the first CEI data set.

Do you have any clue of why this is happening?

[plutonheaven]

I did some additional investigations. For the RINEX NAV parsing and ephemeris selection, the following parameters of a CEI data set are relevant: issue of data ephemeris (iode), time of ephemeris (toe) and time of transmission (ttr). They are located as follows:

 G15 2024 06 24 -- -- -- ------------------ ------------------ ------------------
      iode               ------------------ ------------------ ------------------
      ------------------ ------------------ ------------------ ------------------
      toe                ------------------ ------------------ ------------------
      ------------------ ------------------ ------------------ ------------------
      ------------------ ------------------ ------------------ ------------------
      ttr                ------------------

So for eph1, we have iode = 4, toe = 115184 and ttr = 114666.
For eph2, we have iode = 112, toe = 115200 and ttr = 108018.

So actually, eph2 was broadcasted way earlier than eph1 (eph2.ttr < eph1.ttr), and the logic would be that eph1 is an updated version of it.

I looked at the code in rtklib, and could not find the location which would remove eph2. There is uniqeph() , but since both iode are different, they would not be considered as duplicate.

Then seleph would just compute the difference between the observation time (in my case 116400) and the toe of every eph_t and chose the closest one, which should yield the second one (eph2).

So, there may be another process to prefer the newest ephemeris (eph1) over the older (eph2), but I have not found it. Any help is welcome.

[taroz]

I have encountered the same problem. Sometimes, the GPS ephemeris is updated by another iode before two hours have passed. In that case, toe becomes a little earlier, so rtklib incorrectly uses the old ephemeris.

In my case, I noticed that although the health flag had been cleared in the newly updated ephemeris, it was not being used for positioning in rtklib.

To avoid this problem, you need to modify the program yourself to select ephemeris where the toc and toe times have passed and the ttr is the latest.

[tomojitakasu]

I wrote a short test code using RTKLIB 2.4.3 b34.

// test seleph()
#include <stdio.h>
#include "rtklib.h"
int main(void) {
    nav_t nav = {0};
    double ep[] = {2024, 6, 24, 8, 20, 0}, rs[6], dts[2], var;
    int svh;
    gtime_t time = epoch2time(ep);
    readrnx("./test_ephem.nav", 0, "", NULL, &nav, NULL);
    satpos(time, time, satid2no("G15"), EPHOPT_BRDC, &nav, rs, dts, &var, &svh);
    printf("rs=%.1f %.1f %.1f dts=%.1f svh=%d\n", rs[0], rs[1], rs[2], dts[0] * 1e9, svh);
    return 0;
}

The input RINEX file "test_ephem.nav" is as follows. The SV health flags (Line 7, field 2) were modified to 1 and 2 to distinguish which ephemeris was selected.

     3.05           N: GNSS NAV DATA    M: Mixed            RINEX VERSION / TYPE
TEST                                    20210203 040835 UTC PGM / RUN BY / DATE 
                                                            END OF HEADER    
G15 2024 06 24 07 59 44 1.736045815051e-04 4.206412995700e-12 0.000000000000e+00
     4.000000000000e+00-9.028125000000e+01 4.785199322759e-09-6.493624923029e-01
    -4.604458808899e-06 1.573454437312e-02 9.842216968536e-06 5.153677450180e+03
     1.151840000000e+05-1.396983861923e-07-2.820946273747e+00 1.899898052216e-07
     9.359883245393e-01 1.812500000000e+02 1.319706711607e+00-8.354633718315e-09
     3.239420649158e-10 1.000000000000e+00 2.320000000000e+03 0.000000000000e+00
     2.000000000000e+00 1.000000000000e+00-1.024454832077e-08 4.000000000000e+00
     1.146660000000e+05 4.000000000000e+00                                      
G15 2024 06 24 08 00 00 1.736055128276e-04 4.206412995700e-12 0.000000000000e+00
     1.120000000000e+02-9.028125000000e+01 4.785556480493e-09-6.470286903135e-01
    -4.604458808899e-06 1.573454204481e-02 9.842216968536e-06 5.153677459717e+03
     1.152000000000e+05-1.396983861923e-07-2.820946398095e+00 1.899898052216e-07
     9.359883245393e-01 1.812500000000e+02 1.319706609203e+00-8.354633718315e-09
     3.239420649158e-10 1.000000000000e+00 2.320000000000e+03 0.000000000000e+00
     2.000000000000e+00 2.000000000000e+00-1.024454832077e-08 1.120000000000e+02
     1.080180000000e+05 4.000000000000e+00

Here is the result, where the second ephemeris (TOE = 115200) is selected. The behavior is as expected.

$ ./test_ephem.exe
rs=-5503681.5 20299103.6 15605872.2 dts=173627.2 svh=2

How did you confirm "rtklib selects the first one" ? (It seems hard without adding debug prints).

[plutonheaven]

@tomojitakasu Thanks for your answer and for the test. I used @taroz's MatRTKLIB to output the satellite position and compare with my script.

@taroz Thanks for the comment. Your suggestion to add some test on the time of transmission (ttr) to select the ephemeris would describe a realistic behaviour of a receiver. However, I tried to find a difference between RTKLIB and MatRTKLIB concerning the ephemeris selection or filtering, but did not find one. I will further investigate in MatRTKLIB's source code.

[plutonheaven]

I think I found the process in MatRTKLIB to remove duplicate ephemeris.

Everything is explained. Thanks for your time, and many thanks to both @tomojitakasu and @taroz for your marvelous contribution to the GNSS domain.