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

[Gabriele Coppi <gabriele.coppi@xxxxxxxxx>]

I am not really going underground, but it will be used below a surface that will cover the gps signal (I tested the conditions already). 

I don’t have a temperature controlled RTC and I won’t test it at different temps (I don’t have time). I would say that knowing the gps time at ms level is good enough and it seems that using the directives as suggested by Miroslav (so SHMs) works
> On 14 Nov 2022, at 22:34, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
> 
> 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? 
>>>      >
>>>      >

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.