Re: gpsrinex epoch timestamps look wrong

[Poul-Henning Kamp]

--------
In message <address@hidden>, "Poul-Henning Kamp" writes:

(The usual apologies for replying to the wrong message in the thread.)

Gary wrote:

> Except, you have no fix:

Correct, the antenna normally belongs to the NovaTel Oem2 which
feeds into rtk2go.com

(If I know how to get a RINEX file out of the NovaTel I would use
that instead)

> I don't know any setting that would put the RAW data back at the top of the 
> second.

I looked at the old RINEX I managed to get throug NRCAN last year and
that seems to have the same issue, and yet they processed it using the
fractional timestamps.

If we assume for a moment that they do not require the timestamps
to be perfeclty on top of the second, but they need them to be close
to 30 seconds apart, then maybe the code in gpsrinex.c which selects
which observations to save should take the fraction into account
so that instead of:

        gpsrinex2020025225827.obs:> 2020 01 26 01 31 30.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 32 00.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 32 30.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 33 00.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 33 30.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 34 00.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 34 30.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 35 00.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 35 30.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 36 00.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 36 30.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 37 00.0000000  0 13

it would have picked:

        gpsrinex2020025225827.obs:> 2020 01 26 01 31 30.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 32 00.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 32 30.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 33 00.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 33 30.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 34 00.9989999  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 34 31.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 35 01.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 35 31.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 36 01.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 36 31.0000000  0 13
        gpsrinex2020025225827.obs:> 2020 01 26 01 37 01.0000000  0 13

Thus avoiding the 29 second interval ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
address@hidden         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.