gnss_lib_py icon indicating copy to clipboard operation
gnss_lib_py copied to clipboard

gps milliseconds conversion seems off

Open calvinarraylabs opened this issue 3 months ago • 2 comments

Problem In testing, the GPS milliseconds conversion seems off, perhaps due to time conversion problems. RINEX Observation files specify the time system used for each observation epoch (for example, GPS, GLO, etc.). The current code takes datetimes of the parser observation epoch and automatically assigns them to UTC. Thus conversion will be off due to the assumption of UTC for the observation epoch instead of the true time system in GPS or various other time.

This problem is most noticeable when using the RINEX Obs and Nav file for state estimation. However, since this problem has not been discussed, I was wondering if this is an intended feature and I might be missing something, or if it is an actual error.

calvinarraylabs avatar Sep 03 '25 21:09 calvinarraylabs

Good question. Our research lab didn't do a ton with Rinex observation files, so I wouldn't be surprised if there's a bug.

For both Rinex Nav and Rinex Obs, we pass the rinex file to georinex which parses it for us and returns a time column. The question in my mind would be whether georinex does anything to adjust based on the time system in the file. I see that they parse the time system, but I don't immediately see them doing anything with it. You're welcome to investigate yourself. Here's their OBS3 file and they have a separate one for OBS2 https://github.com/geospace-code/georinex/blob/main/src/georinex/obs3.py

Once we get that time row from georinex it looks like we assume it's in UTC although the syntax is slightly different

  • in Rinex Nav we convert directly (but our conversion function assumes UTC): https://github.com/Stanford-NavLab/gnss_lib_py/blob/73a819879fe2c26b3eea7e95be9f2761b34802ad/gnss_lib_py/parsers/rinex_nav.py#L145-L148
  • in Rinex Obs we explicitly state it's UTC and then convert to gps milliseconds: https://github.com/Stanford-NavLab/gnss_lib_py/blob/73a819879fe2c26b3eea7e95be9f2761b34802ad/gnss_lib_py/parsers/rinex_obs.py#L60-L63

I don't think any of the maintaining team will have time to look in detail into this and fix, but please feel free to contribute the fix if it's wrong: https://gnss-lib-py.readthedocs.io/en/latest/contributing/contributing.html

betaBison avatar Sep 03 '25 22:09 betaBison

Yeah, from further research, it seems that the georinex parses the date as a naive datetime as seen here:

https://github.com/geospace-code/georinex/blob/main/src/georinex/obs3.py#L167-L183

def _timeobs(ln: str) -> datetime:
    """
    convert time from RINEX 3 OBS text to datetime
    """


    if not ln.startswith("> "):  # pg. A13
        raise ValueError('RINEX 3 line beginning "> " is not present')


    return datetime(
        int(ln[2:6]),
        int(ln[7:9]),
        int(ln[10:12]),
        hour=int(ln[13:15]),
        minute=int(ln[16:18]),
        second=int(ln[19:21]),
        microsecond=int(float(ln[19:29]) % 1 * 1000000),
    ) 

But they are not doing any conversion with it and return the naive datetime at each observation epoch, and the time system of the datetime as a string. It seems that it is up to us users to make sure that any conversion to different time systems will require us to be aware of what time systems those datetimes are in, and we cannot assume the datetime to be in UTC.

calvinarraylabs avatar Sep 03 '25 22:09 calvinarraylabs