Re: [chrony-users] Issue with RTC and PPS

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


Note also that rtc clock can only be read to the latest second. If all you
care about is time to the nearest second, that is fine, but if you want better
accuracy, it is not there.


William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Mon, 14 Nov 2022, Bill Unruh wrote:

[CAUTION: Non-UBC Email]

Well, it depends. On most systems I have looked at RTC is worse than the
system clock at keeping time. Yours might be different. If it is worse then
just leaving the system to go ahead on its own time would be the better thing
to do. RTC is then reserved for shutdown and restart. I would certainly not
have RTC as a clock time. rtcsync is a terrible procedure at any time. It keeps the rtc at the system
time while the system time is running, but if the system time stops for some
reason rtc will go wandering off on its merry way and as I said, will
generally be worse than the system time left alone. Otherwise chrony will try
to measure the drift rate of the rtc and correct its reading of the rtc taking
the rtc drift into account. That is not necessarily great since if the
computer is switched off it is colder than if it is running, and the usual rtc is quite temperature seneistive. Ie, its rate is different cold than warm, and the drift rate calculated when warm is not the drift rate when cold ( but when
of course you cannot calibrate it since the computer is not running.

Of course if you have purchased a temperature controlled rtc for the RPI, then
it may well be better than computer clock, and your procedure might work.

Remember even if the gps is no longer supplying the signal, chrony has spent a
lot of time figuring out what the drift rate is of the clock and can keep
pretty good time.

( and why would your gps signal go down for a significant time? Are you using
your rpi underground somewhere?


William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Mon, 14 Nov 2022, Gabriele Coppi wrote:

[CAUTION: Non-UBC Email]I know that RTC is not ideal and it is not GPS, but it is necessary. I know for sure that it will take some time to lock the GPS signal since the booting of the RPi (few minutes). Not only this, I know that I can lose GPS connection for a long period of time, and that is why the rtcsync directive. In my
mind the RTC should be used by chrony during this blackout periods
Also the RTC that I am using is 3.5 ppm, so it should be 1s over few days 


----------------------------------------------------------------------------------
Dr. Gabriele CoppiMarie Curie Skłodowska Fellow, 
Department of Physics, Università degli Studi Milano-Bicocca
https://gabrielecoppi.github.io/
Phone Number: +39 0264482356



On Mon, Nov 14, 2022 at 5:27 PM Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
I am confused. RTC is NOT GPS. RTC is an onboard (or for the RPI I guess a supplimentary board) which chrony uses ONLY at startup to set the intial system clock to approximately the correct time. It tends to drift badly --
      1000PPM might be good (That is about a second per hour).

PPSis pulse per second. It carries zero time information except that when the pulse is sent, it is exactly (towithin nanoseconds) on the second.It needs some other clock to tel it what the second is. That other clock is either the from your GPS receiver or some other clock. Otherwise it assumes that the time from the system clock is correct for the labeling of which second the pulse is assocated with. (This may well be fine if the GPS went down for a while, obviously not so good if the computer switched off. ) Many people use gpsd to get the seconds label from the GPS sattelite. (that may be what your GPS
      source is delivering).

You will have to find out if your pps is actually delivering pulses. Look at /sys/devices/virtual/pps/pps0/assert to see if it is increasing its pulse count (you will also have to determine whether your second pulse occurs on
      assert or clear-- probably assert)






      William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
      Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
      UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

      On Mon, 14 Nov 2022, Gabriele Coppi wrote:

      > [CAUTION: Non-UBC Email]Hello, 
> I am currently using chrony (v4.0.8) on a RPi4. Due to my application, I need to use only GPS,
      PPS and RTC
> for time keeping. The RTC is necessary to preserve the time when GPS coverage drops or at boot
      when the GPS
      > lock is not immediate.
      >
> I have this current chrony.conf directives (other that standard ones) 
      >
      > refclock PPS /dev/pps0 refid PPS trust lock GPS
> refclock SHM 0 refid GPS precision 1e-1 offset 0.3 delay 0.2 noselect
      > rtcsync
      > rtconutc
      >
> where  the first two are defining my sources and the second should take care of the RTC. I
      would like to use
> the rtcfile directive to have chrony to take care of everything but it seems that Rasbian
      Kernel is built
      > without support for RTC_UEI_ON.
      >
      > Now I have the following problems, when I shutdown/reboot the RPi:
      >
>  1. it seems that chrony never selects the PPS source, and given that GPS is marked as
      noselect, I don't have
      >     any GPS timing
>  2. any RTC support is outside chrony, but as said I would like to track it with chrony 
      > I specify that chrony is run as daemon at startup with the -s flag
      >
      > Any ideas? 
      >
      >




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/