[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gpsrinex - smaller than 1s epoch interval

From: Greg Troxel
Subject: Re: gpsrinex - smaller than 1s epoch interval
Date: Tue, 19 May 2020 15:16:49 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

>> as for float, I would avoid that to stay away from possible rounding
>> issues.
> Then you have to throw all of gpsd away.  :-)

Sure, I get it that most of the calculations are rounded and that's less
than errors so that's all totally fine.

What I meant is that if one sets

  interval = 0.1;

as a double, and then collects say 48h of data, and writes the values
into RINEX somehow, I'm not sure if this will or won't result in the
values differing noticeably from t_0 + k * 0.1s for integer values of k,
or if that matters.  I was suggesting that this issue be avoided by
representing in ms, so all the time interval arithmetic would be exact.

It may be that in RINEX given the 1 ms resolution, if that drifts from
0.000s to eventually 86400.001s, that no processing software will get
upset.  But it sems that things that consume RINEX have a general
reputation of being super fussy.

>>   capture raw ubx data w/o using gpsd
> Or with gpsd.  Live or captured, the raw data has to through gpsd to get
> to gpsrinex.

Good point - I should have said 'w/o the current gpsrinex that only does
1s or more'.

>>   process that at NRCAN PPP and see if it works
> Easier said than done.  But worth a shot.

It's easy to try.

I have uploaded RINEX files that I got from rtklib's convbin, from a ubx
raw at 1s intervals, and gotten back solution files at that same
interval that when plotted look basically sensible.  This is after
hiking on a trail to collect a trace to improve openstreetmap.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]