Re: Report GPS/sync time difference

[Gary E. Miller]

Yo Roger!

On Wed, 26 Oct 2022 07:13:47 +0000
Roger Oberholtzer <Roger.Oberholtzer@ramboll.se> wrote:

> >> As they are high-end (OxTS) designed to be used in a moving
> >> vehicle,  
> 
> > One mans "high-end" is anothers trash.  Care to be more specific?  
> 
> Very high precision vehicle location and orientation. Among other
> uses, we use it to help us locate LiDAR and high-resolution image
> data with such high precision that we can take a pixel from an image
> and use it to colorize a point in the LiDAR data. And have those
> colorized points be in space within a couple CM of where it is
> expected to be. Collected at up to 90 km/k and done at a high volume
> (35000 KM per year) and, for the most part, an automated process.

A couple of cm?  Without post processing the GPS signal?  Not possible.
Close, maybe, if you are really good.

> 
> >> this means you have to drive a bit. This is also because of the IMU
> >> and how it is integrated in positions and orientation.  
> 
> > Which makes no sense.  Time is from the GPS, not the IMU.  
> 
> Obviously. But when the goal is that ALL data should be consistent
> (time, location, orientation), crapping out bits just because you can
> does not help anyone. It's all about one's use case.

Sorry, lost me...

> >> Oct 18 13:17:32 rstraptor1 chronyd[2772]: System clock wrong by
> >> -67.652005 seconds Oct 18 13:16:24 rstraptor1 chronyd[2772]: System
> >> clock was stepped by -67.652005 seconds  
> 
> > So?  Looks normal.  
> 
> You have missed the point. Measurements were done where this sync did
> not happen.

So your example is not of the problem case?  WHy show that data if it is
not the data in question?

> Assuming that a PC clock these days is rather stable over
> a couple months (I know...),

Terrible assumption.  Especially since chronyd servos the PC clock, the
drift yesterday is not the drift today.  The RTC clock is yeat again
different.

> perhaps knowing how much it should
> change the clock today gives a hint how much it might have been moved
> back when it did not happen.

My tests with Raspberry Pis showed the system clock iss a great
thermometer.  That's why time-nuts graph the host temperatures as
well as the other parameters.
 
> >> There is the time difference I was after.  
> 
> > Sadly, by the time you know, it is gone.  So not really a useful
> > answer to your question.  
> 
> In fact it was exactly the answer to my question.

Only part of the full answer.  You also need time since th last sync,
the termperature graph sonce then, any transfers between PC clock and
RTC, etc.

> >> If it is the most accurate
> >> time difference one can get reported is not clear to me.  
> 
> > Unless you have a more accurate clock available, that is as good as
> > it gets.  
> 
> I meant that I have to trust that chrony is reporting what I think it
> is reporting.

No need to trust, it is well documented.  But it does take chrony awhile
to settle down, so I would not expect great precision on the first
time jam.

> >> But it
> >> serves my purpose.  
> 
> > Which is?  
> 
> All described in my first message in this thread.  And summarized
> occationally in subsequent messages. Including this one.

I asked again because the 1st message was unclear to me.  As you your
self point out above, I'm misssing your points.  Thus my requests for
further info.

> Classification: Confidential

Sigh...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgp1cS01yoq6F.pgp
Description: OpenPGP digital signature