search

tomojitakasu / RTKLIB

2.58k stars 1.63k forks source link

Possible bug in restoring Galileo week number from ephemerides #219

Closed Fr0sT-Brutal closed 7 years ago

Fr0sT-Brutal commented 8 years ago

Seems to me like a bug. rtcm3.c, function decode_type1045, line eph.week=adjgpsweek(week%1024); But Galileo week occupies 12 bits and so rolls-over after 4096. Currently it works because GPS weeks are forced to be greater than 1560 so they're less than their roll-over interval as well as Galileo's. But in the next year GPS weeks will roll-over and Galileo won't.

tomojitakasu commented 8 years ago

Thanks. It will be fixed in next 2.4.3 beta.

MichaelEFlip commented 8 years ago

The fix which should fix this issue (1cec90a9ffa424908ad1a4ca3d52f33f9b94d1f7 / 2.4.3 b24) in rtcm3.c and rtcm3e.c destroys the ephemeris message rtcm3/1045. No more ephermeris data for GALILEO is visible in RTKNAVI. Reverting rtcm3e.c and rtcm3.c to the previous version enables ephermeris data again.

Tested with UBLOX M8T (ubx) -> strsvr (RTCM3) -> RTKNAVI

tomojitakasu commented 7 years ago

Thanks. It is fixed in 2.4.3 b27.

liujinwhu commented 2 years ago

version: rtklib_2.4.2 HI: I'm test RtkNavi use the rtksample data, LINK, my question is the time one top-left of RtkNavi, show as the image i posted, why it show the year is [2028], and i use the data debug into int linux with eclipse CDT (2021-12), and found the time is processed in novatel.c, when the file is readed, the function is decode_oem4.

I tried to comment the function invoke of adjgpsweek, at line 1170, the time is right parsed to 20090515, same as the file name shows.

i'm confused for this problerm, can you give me some suggestions?

Image RtkNavi

version: RTKLIB-2.4.3-b34 I tried the newer version, but it not work when i used the sample data, 2.4.3

the difference is , input options not support OEM6 any more, is this the reason? input

need your help! THANKS