Re: Issue with RTC and PPS
Gabriele Coppi <[email protected]>
| Newsgroups | gmane.comp.time.chrony.user |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 |____ [email protected] > 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 |____ [email protected] >> 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 <[email protected]> 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 |____ [email protected] >>> 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-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "unsubscribe" in the subject. For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "help" in the subject. Trouble? Email [email protected]