Re: Timing via serial port

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

> On Wed, 30 Sep 2020 14:19:34 +0200
> Kai Harrekilde-Petersen <khp@harrekilde.dk> wrote:
>
>> Front edge of the UART frame is the most precise. Rear edge depends
>> too much on the length of the message. 
>
> "Precise" is not a word I would use.  And sadly the POSIX API gives
> no access to the leading edge time.  The only time that is available is
> when gpsd gets some bytes.

True, but the relationship of the first byte to the first read might be
stable.

>> As I recall, the latency from the PPS to the front edge increases(!)
>> with increasing update rate. I did not check for the variation
>> between the 1PPS and the start of the UART message.
>
> There are a large number of things that affect the latency to the serial
> message.  A big one is the nav solution.  The little CPU in the GNSS
> receiver uses and iterative method to solve the equations for ECEF X,
> ECEF Y, ECEF Z, and time.  Slight pertebations in the ephemeris,
> satellite positions, multipath, etc. cause wide variations in solution
> time.
>
> Only after the solution is determined can the fix sentence be built.
>
> These variations can exceed 100 ms and seem to be vaguely periodic
> on a slow time scale.

All true as a general caution.

Long ago, with an NMEA receiver, a Sparc Classic, and NTP, and no PPS
hookup, I found that the time from NMEA was pretty stable at the 5-10 ms
level.  That's not enough to make a time nut happy, but it is useful in
keeping time good enough to sync logs, vs relying solely on the
Internet.

So, I'd say that for any particular setup, if someone is inclined to
measure behavior, that's a reasonable thing to do.  Of course, if you
hook up PPS to measure, you might as well use it.  But you might have a
PPS source and a second one and then measure the second one.

signature.asc
Description: PGP signature