RTKRCV replay mode have some problem on GLONASS

[ChunboLiu777]

Dear Developer, I recently encountered some issues while using RTKRCV to save and replay data in RTCM format. When replaying raw data saved for one day, the ephemeris data of the GLONASS system exhibits a time jump to the previous day after 12:00 noon. For example, when I replay data from July 13, 2024, the ephemeris time jumps to July 12, 2024, after 12:00 noon. This is quite confusing, and I haven't been able to find a solution for this issue.

[ChunboLiu777]

[ourairquality]

The RTCM file streams appear to need an approximate start time. For convbin this is supplied by the '-tr y/m/d h:m:s' command line argument but there is no such argument for rtkrcv.

There is some logic in the coded for file time tags, and can that help.

Or would it be useful to add support to rtksvr.c to support an initial approx time for rtcm and perhaps raw file streams, and a -tr argument to the rtkrcv command and support in the gui apps?

[ChunboLiu777]

Hello dear @ourairquality , I did indeed utilize the time tag feature in the software, for example: "strpath[5] =./Rov_%Y%m%d%h%M.log::T::S=24". However, this setting seems to only work for GPS, GALILEO, and BDS systems, while errors occur with the GLONASS system (as I mentioned in the issue). Additionally, the GUI app (RTKNAVI) also experiences this issue.

[ourairquality]

The function rtcm3.c:adjday_glot() might be related to this issue.

[ChunboLiu777]

Hello dear @ourairquality , I have noted the function you mentioned, especially its role in adjusting daily rollover of GLONASS time, which seems closely related to the issue I encountered. I will investigate further to confirm its relevance and get back to you soon. Thank you very much for bringing this to my attention!

[ChunboLiu777]

Hello dear @ourairquality ,My issue has been resolved, but extensive testing is still needed to ensure my modifications are correct. The problem wasn't with the adjday_glot function, but it provided me with great insight, and I want to thank you again. The GLONASS ephemeris message (RTCM 1020) didn't use the adjday_glot function; instead, the functionality of that function was implemented again in the decoding function. After careful inspection, I can confirm that this is not an issue. However, in the rtkrcv program, there are three instances of svr->rtcm, which are defined in the program as coming from rov (rover), bas (base station), and cor (SSR correction message). During debugging, I found that svr->rtcm[bas].time always remained as the start time of the playback file, while svr->rtcm[rov].time and svr->rtcm[cor].time were correct. The fact that svr->rtcm[bas].time always remained as the start time of the playback file caused some time variables in the 1020 decoding function to be incorrect, directly leading to the final ephemeris toe parsing error. Therefore, I set svr->rtcm[bas].time to be equal to svr->rtcm[rov].time, which resolved the issue. Since it hasn't been fully tested, I haven't provided this change to the author yet, and there might be a better way to make this modification... My change is as follows(in rtksvr.c): `/ decode receiver raw/rtcm data ---------------------------------------------/ static int decoderaw(rtksvr_t svr, int index) { obs_t obs; nav_t nav; sbsmsg_t sbsmsg=NULL; int i,ret,ephsat,ephset,fobs=0;

// add for replay mode eph time (rtcm->time)
svr->rtcm[index].time = svr->rtcm->time;

tracet(4,"decoderaw: index=%d\n",index);

... } ` I will continue testing, and if I find any issues, I will provide feedback here. Thank you again for your help!

[ourairquality]

Good progress, thank you. Can you spot where the rtcm[rov].time and rtcm[cor].time are being updated?

The function rtcm3.c:decode_rtcm3() sets the time on each call when the "-RT_INP" option is enabled, and this uses timeget() and this time appears to be updated when reading files with a time tag, see the call to settime() in stream.c:readfile(). So perhaps just using this option would also solve this problem. But if so then should the rtksvr being be updating the rtcm times in the same manner.

[ChunboLiu777]

Hello dear @ourairquality ,Regarding the updates to rtcm[rov].time and rtcm[cor].time, I will look into it as soon as possible and provide feedback here. Your description about the "-RT_INP" option is correct. The settime function successfully sets the time offset, so the time obtained by timeget is the required playback time. Therefore, adding the "-RT_INP" option can indeed solve this problem! However, please remember to add this option to each rtcm structure (rov, bas, cor).

[ourairquality]

Took a look at this again and failed to spot how the svr->rtcm[bas].time can be fixed. The functions decode_head1009() and decode_ssr_epoch() appear to call adjday_glot() which should be updating the rtcm time, and this is time should also be updated for other system observations by adjweek() and adjbdtweek(). So would be curious what the other base rtcm messages are and if there are updating the time. There might be an issue here not yet identified.