Re: [ntp:questions] false ticker after GPS coldreset
valizade...@gmail.com wrote: > i have a ntp server based on Raspberry Pi3 with PPS (from u-blox6 ). i have > also added a hardware clock to this system. > > > SOME times there is a large offset(3-18 sec) on the SHM (ntp driver 28). > i did some experiments and figured out it is related to "leap seconds". > when i COLD-RESET the ublox(via USB through u-center) this offset appears on > the ntp and both PPS and SHM become false-tickers. GPS internal system time is off UTC by an integral number of seconds corresponding to the number of leap seconds that have been observed since 1980. As Jakob has already pointed out, the satellites send this information once every ~12 minutes. The GPS receiver needs this information to convert the raw GPS time received from the satellites to UTC, so it usually store this information in its non-volatile memory to have it available right after power-up. However, if you force the GPS receiver into cold boot mode then this information gets lost, so the receiver outputs GPS time instead of UTC. I'm not sure if the output contains some status that indicates that the time sent by the receiver is not UTC. Anyway, gpsd seems to accept the raw GPS time as UTC time, feeds it to ntpd, and ntpd sets the Linux system time off by a number of seconds. Up to 12 minutes later, after the GPS receiver has seen the UTC correction parameters from the satellites, the GPS receiver starts to convert GPS time to true UTC, and the time output jumps by a number of seconds. ntpd observes the sudden time step by a number of seconds, but accepts it only after it has persisted by a certain interval, by default ~15 minutes. So your system time should be stepped to the correct time, but only after up to 12 + 15 minutes after power-up. I think the best solution would be to provide your GPS receiver with a backup battery, if the device supports this, to make sure the UTC correction parameters don't get lost while the system is powered off. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP postings end up in mailing list moderation
Jakob Bohmwrote: > Posting to comp.protocols.time.ntp is automatically gatewayed (two-way) > to questions@lists.ntp.org or questi...@ntp.org [good]. > > questions-ow...@lists.ntp.org sends out a moderation warning e-mail when > this happens [bad]. > > Not sure where to report this, as it is neither an NTP nor a website > issue. I've forwarded this to the NTP tech ops, so I hope one of them cares about it. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] false ticker after GPS coldreset
On 31/10/2017 18:17, William Unruh wrote: On 2017-10-31, valizade...@gmail.com wrote: i have a ntp server based on Raspberry Pi3 with PPS (from u-blox6 ). i have also added a hardware clock to this system. SOME times there is a large offset(3-18 sec) on the SHM (ntp driver 28). What program is delivering the time to the SHM? gpsd? i did some experiments and figured out it is related to "leap seconds". No idea how it could be related to leap seconds. Leap seconds are only one second and that almost never happens. Is your gps broken? He is obviously talking about the total accumulated leap seconds since either IAT start (37) or GPS start (28). Because the GPS satellites broadcast TAI+19s every 1.5 seconds, but UTC-(TAI+19) every 12.5 minutes, many GPS receivers provide TAI+19 or TAI between power up and reception of the offset. Theoretically, something on the computer could detect this and get the proper offset from the leap-seconds file, but few implementations have that particular ability. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] false ticker after GPS coldreset
On 01/11/17 11:46, valizadeh...@gmail.com wrote: local lcok is there because my system is not connected to internet and i need to have the hwclock to keep the time during power-offs,i have disabled the pre installed fakeclock and used an I2c connected battery backed up RTC chip. Local clock has nothing to do with the RTC chip. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] false ticker after GPS coldreset
On 01/11/2017 11:46, valizadeh...@gmail.com wrote: []> local lcok is there because my system is not connected to internet and i need to have the hwclock to keep the time during power-offs,i have disabled the pre installed fakeclock and used an I2c connected battery backed up RTC chip. the local clock is been updated at start up from the hwclock and hwclock itself is synchronized via ntp itself. so the server 127.127.1.1 is my hwclock :) am i right ? or shall i used another trick to utilize hwclock ;) [] There are issues with different versions of Linux behaving in different ways and using different scheduling programs which may require patient investigation to resolve. poor me then :( I've not added an RTC to my Raspberry Pi cards, so I can't help there. There's no RTC in the RPi itself. The RPi needs NTP to set its time at start-up. I don't know how the OS would set your particular RTC to I can't help there, but presumably there is a driver provided? I recall that action may have to be taken to make Linux keep the RTC updated regularly, but that's outside the scope of my knowledge. I've just downloaded the latest Linux for the RPi, but the particular hardware I'll have connected (MMDVM_HS HAT) takes control of the serial port lines, so I won't be able to add my usual GPS device (Uputronics) for precise timekeeping, and it will have to be NTP over Wi-Fi. I might see whether you can simply add the PPS signal without using GPSD. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] false ticker after GPS coldreset
On 31/10/2017 08:50, valizade...@gmail.com wrote: server 127.127.1.1 minpoll 3 maxpoll 4 #hwcloak fudge 127.127.1.1 stratum 3 As Bill says, get rid of the local clock, and add some Internet sources. That way you can check whether your GPS is grossly wrong. The reach value seem wrong as well. Place your GPS antenna where you are sure of a good signal - you can check this with an Android mobile phone (Apple doesn't allow programs to access this information, sigh!). Note that I have been able to get such a stand-alone configuration working (for when you are in the field without Internet access). See: http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html#stand-alone There are issues with different versions of Linux behaving in different ways and using different scheduling programs which may require patient investigation to resolve. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] false ticker after GPS coldreset
On 2017-10-31, valizade...@gmail.com wrote: > i have a ntp server based on Raspberry Pi3 with PPS (from u-blox6 ). i have > also added a hardware clock to this system. > > > SOME times there is a large offset(3-18 sec) on the SHM (ntp driver 28). What program is delivering the time to the SHM? gpsd? > i did some experiments and figured out it is related to "leap seconds". No idea how it could be related to leap seconds. Leap seconds are only one second and that almost never happens. Is your gps broken? > when i COLD-RESET the ublox(via USB through u-center) this offset appears on > the ntp and both PPS and SHM become false-tickers. > > > i wait for over 12.5 minutes so that the UTC time become accurate (Almanac > data reception period) some times it works and SHM/PPS become truechimers and > some times even after 24 hrs they still are falsetickers with "3 seconds" > offset! It really sounds like a broken gps to me. > > here is what i think: > 1- system is tured on > 2- utc time is not accurate(leap seconds) but ntp dosent care and do iburst > 3- system time become updated > 4- 12.5 min is passed > 5- GPS time is changed (3-18 sec) > 6- ntp is not able to handle this > > > > i also used leap-second list file but there was no change > http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14. > > > *system power on:*** > Every 1.0s: ntpq -p PI3: Tue Oct 31 07:18:25 2017 > remote refid st t when poll reach delay offset jitter >== > oPPS(0) .kPPS. 0 l18 170.000 -5.553 2.806 > *SHM(0) .GPSD. 1 l18 370.0004.468 5.104 > LOCAL(1).LOCL. 3 l 398 200.0000.000 0.002 a) why do you have LOCAL as one of your clocks. That should basically never be used. It is useless except in very particular situations where it is a server which has to keep serving time even if its time is completely useless, because all clocks in an organisation have to on the same time, even if that is wrong. b) Do you have some other source of time? > > *after ~20 min:* > Every 1.0s: ntpq -p PI3: Tue Oct 31 07:39:28 2017 > remote refid st t when poll reach delay offset jitter >== > oPPS(0) .kPPS. 0 l- 16 3770.000 -4.023 0.355 > *SHM(0) .GPSD. 1 l-8 3770.0001.894 1.650 > LOCAL(1).LOCL. 3 l 1302800.0000.000 0.000 > > * COLDSTART * > Every 1.0s: ntpq -pPI3: Tue Oct 31 07:44:09 2017 > remote refid st t when poll reach delay offset jitter >== > oPPS(0) .kPPS. 0 l 178 3740.000 -2.423 0.661 > *SHM(0) .GPSD. 1 l 178 3740.000 -0.057 0.652 > LOCAL(1).LOCL. 3 l 1583800.0000.000 0.000 > > *after COLDSTART * > Every 1.0s: ntpq -pPI3: Tue Oct 31 07:44:17 2017 > remote refid st t when poll reach delay offset jitter >== > +PPS(0) .kPPS. 0 l 258 3700.000 -2.423 0.661 > *SHM(0) .GPSD. 1 l18 3710.000 3044.83 3045.01 > LOCAL(1).LOCL. 3 l 1591800.0000.000 0.000 > > *after COLDSTART * > Every 1.0s: ntpq -p PI3: Tue Oct 31 > 07:44:37 2017 > remote refid st t when poll reach delay offset jitter >== > xPPS(0) .kPPS. 0 l 458 3400.000 -2.423 0.590 > xSHM(0) .GPSD. 1 l58 3470.000 3044.73 2573.41 > LOCAL(1).LOCL. 3 l3810.0000.000 0.002 > > > > > ntp.conf: > > tos maxdist 16 > tos mindist 0.400 > > > server 127.127.22.0 minpoll 3 maxpoll 4 > fudge 127.127.22.0 refid kPPS flag3 1 flag2 0 > > server 127.127.28.0 minpoll 3 maxpoll 4 iburst prefer > fudge 127.127.28.0 time1 +0.145 flag1 1 refid GPSD stratum 1 > > server 127.127.1.1 minpoll 3 maxpoll 4 #hwcloak > fudge 127.127.1.1 stratum 3 That is not the hardware clock. It is the system clock. It is completely useless. At present there is no evidence of anything. You do not have any independent source of time, so you have no idea what the time actually is. Put in some netw
