Re: [ntp:questions] NTP, GPSD & PPS
On Tue, Dec 9, 2014 at 9:29 AM, Sander Smeenk wrote: > 1) Can i get a 'true PPS sync' with this setup? > Yes. > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? > What do you mean by "Eliminating"? > 2) What could i possibly do to get NTP to sync/accept the NMEA data, > other than set it as a truechimer in the configuration? > Get a source of NMEA data that's presented at a consistent offset from the PPS pulse. Unless someone needs to share position and velocity data I don't understand why gpsd is used to proxy NMEA data. The NMEA (or ATOM) driver is sufficient. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 09/12/2014 16:49, Paul wrote: [] Unless someone needs to share position and velocity data I don't understand why gpsd is used to proxy NMEA data. The NMEA (or ATOM) driver is sufficient. Paul, does the NMEA (or ATOM) driver solve the problem of having perhaps a couple of hundred milliseconds peak-to-peak jitter in the GPS serial data, thereby preventing NTP using the PPS source? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 2014-12-09, Sander Smeenk wrote: > Hi, > > I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0. > The GPS provides a PPS signal via serial and i use gpsd to provide the > NMEA sentences and pulse data in shared memory to NTP. > > This partly works. NTP syncs against the PPS signal but the NMEA signal > is always marked as falseticker even though i managed to bring down the > offset to -1.5??sec average by fudging the time a bit. The NMEA signal > offset fluctuates a lot. From ~ -65??sec to ~ +75??sec. Who cares? If the system is locking on to the PPS that is far far greater accuracy than you will ever get from nmea. Over 1 times better. Not sure what your preceived problem is. The nmea is only good for getting the seconds time. Not more accurate time. You do not want it involved in time setting if the PPS is working. > > The GPS provides 9600bps serial comms. Would it help to speed this up to > 19200bps? I've already disabled all NMEA sentence output for sentences that > "aren't useful for timekeeping" but at this moment i have to use external > clocks to sync against. I presume that the unreadable (to me) symbol was milli not micro seconds. I do not believe that one could get the nmea down to microseconds. As I understand it the gps device sends out the nmea when it has time. Ie, much of the fluctuation is internal rather then transmission, although of course transmission is variable as well (consiidering that the length of the sentences fluctuate). > > Few questions: > > 1) Can i get a 'true PPS sync' with this setup? > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? What is untrue about the gpsd pps? > > 2) What could i possibly do to get NTP to sync/accept the NMEA data, > other than set it as a truechimer in the configuration? nmea will always have very bad fluctuations. You want to use the PPS. > > 3) Why does last_event show clock_alarm for the PPS SHM signal in assoc? > > > At this moment my 'ntpq -p' looks like: > >| # ntpq -np >| remote refid st t when poll reach delay offset jitter >| >== >| 127.127.28.0.NMEA. 0 l 10 16 3770.000 -52.910 12.585 >| *127.127.28.1.PPS.0 l9 16 3770.000 -0.002 0.002 >| -193.67.79.202 .PPS.1 u 50 64 3773.6900.331 0.073 >| +193.79.237.14 .PPS.1 u 48 64 3772.7530.128 0.725 >| +80.94.65.10 .PPS.1 u 63 64 3773.2260.005 0.498 >| -130.89.0.19 103.52.146.131 2 u 30 64 3775.417 -0.100 0.041 > >| # ntpq -c rv >| associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, >| version="ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1)", >| processor="x86_64", system="Linux/3.13.0-39-generic", leap=00, stratum=1, >| precision=-23, rootdelay=0.000, rootdisp=0.386, refid=PPS, >| reftime=d8318503.7827c0d3 Tue, Dec 9 2014 15:26:11.469, >| clock=d831850e.45ff40f3 Tue, Dec 9 2014 15:26:22.273, peer=53550, tc=4, >| mintc=3, offset=0.001, frequency=-19.125, sys_jitter=0.003, >| clk_jitter=0.001, clk_wander=0.000 > >| # ntpq -c as >| ind assid status conf reach auth condition last_event cnt >| === >| 1 53549 9024 yes yes nonereject reachable 2 >| 2 53550 964b yes yes none sys.peer clock_alarm 4 >| 3 53551 931d yes yes none outlyer 1 >| 4 53552 9424 yes yes none candidate reachable 2 >| 5 53553 9424 yes yes none candidate reachable 2 >| 6 53554 931d yes yes none outlyer 1 > > > Thanks for any input! > > -Sander. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 2014-12-09, David Taylor wrote: > On 09/12/2014 16:49, Paul wrote: > [] >> Unless someone needs to share position and velocity data >> I don't understand why gpsd is used to proxy NMEA data. The NMEA (or ATOM) >> driver is sufficient. > > Paul, does the NMEA (or ATOM) driver solve the problem of having perhaps > a couple of hundred milliseconds peak-to-peak jitter in the GPS serial > data, thereby preventing NTP using the PPS source? ??? It does use the pps source. nmea data will always have huge (on ntp scale) jitter. And what evidence is there of preventing using the PPS source? > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 12/09/2014 03:29 PM, Sander Smeenk wrote: > Hi, > > I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0. > The GPS provides a PPS signal via serial and i use gpsd to provide the > NMEA sentences and pulse data in shared memory to NTP. > > This partly works. NTP syncs against the PPS signal but the NMEA signal > is always marked as falseticker even though i managed to bring down the > offset to -1.5ųsec average by fudging the time a bit. The NMEA signal > offset fluctuates a lot. From ~ -65ųsec to ~ +75ųsec. This is a known weakness of the GPS18x series. The puck tries to center the serial output between the PPS pulses, and that's a pain in the back, pardon my French. But to be fair, some SIRF based modules do it even worse. > The GPS provides 9600bps serial comms. Would it help to speed this up to > 19200bps? I've already disabled all NMEA sentence output for sentences that > "aren't useful for timekeeping" but at this moment i have to use external > clocks to sync against. Changing the baud rate does not really help with that device. I have one of my own, and I tried several speeds. Even reducing to a single sentence (GPRMC, or PGRMF) does not provide stable timing. A stable relation between PPS and serial data was obviously no design goal... > Few questions: > > 1) Can i get a 'true PPS sync' with this setup? > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? > > 2) What could i possibly do to get NTP to sync/accept the NMEA data, > other than set it as a truechimer in the configuration? Since you run ntp4.2.6 under Linux, I know only one solution from my own experience: Use the NMEA driver with its builtin PPS support instead of GPSD and the two SHM clocks. Splitting the data into a PPS track and a NMEA track does not work well: The two clock drivers do not know how to correlate their data. Neither does the core of NTPD... If the full handling is done by the NMEA driver, the serial data jitter can be ignored and you get a good precision. You need the PPS line discipline attached to your serial device (see 'ldattach PPS /dev/ttyS0'), and you need a symbolic link from /dev/gpsppsX to /dev/gpsX. (Note: with ntp4.2.7(!) and GPSD running, you could start GPSD on /dev/gps0 and use the GPSD-NG (json) protocol driver (type 46). With a recent version of GPSD you can let GPSD deal with the raw PPS and serial data; NTPD uses the cooked results with nanosec resolution. Then the driver can correlate serial and PPS data to compensate for the phase jitter of the GPS18x.) pearly ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
Quoting William Unruh (un...@invalid.ca): > > This partly works. NTP syncs against the PPS signal but the NMEA signal > > is always marked as falseticker even though i managed to bring down the > > offset to -1.5??sec average by fudging the time a bit. The NMEA signal > > offset fluctuates a lot. From ~ -65??sec to ~ +75??sec. > Who cares? If the system is locking on to the PPS that is far far > greater accuracy than you will ever get from nmea. Over 1 times > better. Not sure what your preceived problem is. I don't want to rely on only external timesources to get a correct time sync. That's why i care (a little). I would be happier if i had a couple of NTP-sources *and* the NMEA signal, i've seen it done with serial attached GPS devices and i'm looking for tips to get it done myself. > > 1) Can i get a 'true PPS sync' with this setup? > > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? > What is untrue about the gpsd pps? It is 'untrue' because it is proxied by a piece of code while the kernel has PPS support itself. That can only introduce more 'noise' in the signal. This is what i've learnt on the internet, at least. -Sndr. -- | The sixth sick sheikh's sixth sheep's sick. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
Quoting juergen perlinger (juergen.perlin...@t-online.de): > This is a known weakness of the GPS18x series. The puck tries to center > the serial output between the PPS pulses, and that's a pain in the back, > pardon my French. But to be fair, some SIRF based modules do it even worse. It appeared to me the sentences were well off the PPS signal itself when viewing gpsmon output. Thanks for this, will dig into that a little... > > The GPS provides 9600bps serial comms. Would it help to speed this up to > > 19200bps? I've already disabled all NMEA sentence output for sentences that > > "aren't useful for timekeeping" but at this moment i have to use external > > clocks to sync against. > Changing the baud rate does not really help with that device. I've talked to some other 18x owners that reported lower speeds to be more stable (4800bps) but in my experience 9600bps was more accurate. (This was 'measured' with munin graphs over at least 24h periods). > > Few questions: > Since you run ntp4.2.6 under Linux, I know only one solution from my own > experience: Thanks for this information. Very helpful. I can work with this. -Sndr. -- | Girls are like internet domain names, the ones I like are already taken. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
Sander Smeenk wrote: Hi, I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0. The GPS provides a PPS signal via serial and i use gpsd to provide the NMEA sentences and pulse data in shared memory to NTP. This partly works. NTP syncs against the PPS signal but the NMEA signal is always marked as falseticker even though i managed to bring down the offset to -1.5ųsec average by fudging the time a bit. The NMEA signal offset fluctuates a lot. From ~ -65ųsec to ~ +75ųsec. The GPS provides 9600bps serial comms. Would it help to speed this up to 19200bps? I've already disabled all NMEA sentence output for sentences that "aren't useful for timekeeping" but at this moment i have to use external clocks to sync against. Few questions: 1) Can i get a 'true PPS sync' with this setup? Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? Hi Jun 21, 2009: My Garmin 18x LVC gave just acceptable performance with the NMEA driver due to having to tune the fudge offset at almost the limit that avoided the wrong second. For PPS I used the ATOM driver and was getting an offset of < 6us. Shortly afterwards Garmin released a firmware fix which fortunately I avoided as the nmea output could over-run into the following second. I'd need to search my backups for the exact server and fudge config lines. Currently I'm running NetBSD-6/i386 and ntpd 4.2.7p476 and my ntp.conf for a Sure GPS has: tos minsane 3 tos orphan 10 tos mindist 0.4 server 127.127.20.2 mode 18 prefer fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb server 127.127.22.2 minpoll 4 maxpoll 4 fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb plus one local peer and four local servers NB. the mode and fudge time2 are specific for the Sure GPS. David 2) What could i possibly do to get NTP to sync/accept the NMEA data, other than set it as a truechimer in the configuration? 3) Why does last_event show clock_alarm for the PPS SHM signal in assoc? At this moment my 'ntpq -p' looks like: | # ntpq -np | remote refid st t when poll reach delay offset jitter | == | 127.127.28.0.NMEA. 0 l 10 16 3770.000 -52.910 12.585 | *127.127.28.1.PPS.0 l9 16 3770.000 -0.002 0.002 | -193.67.79.202 .PPS.1 u 50 64 3773.6900.331 0.073 | +193.79.237.14 .PPS.1 u 48 64 3772.7530.128 0.725 | +80.94.65.10 .PPS.1 u 63 64 3773.2260.005 0.498 | -130.89.0.19 103.52.146.131 2 u 30 64 3775.417 -0.100 0.041 | # ntpq -c rv | associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, | version="ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1)", | processor="x86_64", system="Linux/3.13.0-39-generic", leap=00, stratum=1, | precision=-23, rootdelay=0.000, rootdisp=0.386, refid=PPS, | reftime=d8318503.7827c0d3 Tue, Dec 9 2014 15:26:11.469, | clock=d831850e.45ff40f3 Tue, Dec 9 2014 15:26:22.273, peer=53550, tc=4, | mintc=3, offset=0.001, frequency=-19.125, sys_jitter=0.003, | clk_jitter=0.001, clk_wander=0.000 | # ntpq -c as | ind assid status conf reach auth condition last_event cnt | === | 1 53549 9024 yes yes nonereject reachable 2 | 2 53550 964b yes yes none sys.peer clock_alarm 4 | 3 53551 931d yes yes none outlyer 1 | 4 53552 9424 yes yes none candidate reachable 2 | 5 53553 9424 yes yes none candidate reachable 2 | 6 53554 931d yes yes none outlyer 1 Thanks for any input! -Sander. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 09/12/2014 17:48, William Unruh wrote: On 2014-12-09, David Taylor wrote: On 09/12/2014 16:49, Paul wrote: [] Unless someone needs to share position and velocity data I don't understand why gpsd is used to proxy NMEA data. The NMEA (or ATOM) driver is sufficient. Paul, does the NMEA (or ATOM) driver solve the problem of having perhaps a couple of hundred milliseconds peak-to-peak jitter in the GPS serial data, thereby preventing NTP using the PPS source? ??? It does use the pps source. nmea data will always have huge (on ntp scale) jitter. And what evidence is there of preventing using the PPS source? I tried with the type 46 driver, and the PPS was rejected because the NMEA part was rejected. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
William Unruh wrote: > On 2014-12-09, Sander Smeenk wrote: > > Hi, > > > > I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0. > > The GPS provides a PPS signal via serial and i use gpsd to provide the > > NMEA sentences and pulse data in shared memory to NTP. > > > > This partly works. NTP syncs against the PPS signal but the NMEA signal > > is always marked as falseticker even though i managed to bring down the > > offset to -1.5??sec average by fudging the time a bit. The NMEA signal > > offset fluctuates a lot. From ~ -65??sec to ~ +75??sec. > > Who cares? If the system is locking on to the PPS that is far far > greater accuracy than you will ever get from nmea. Over 1 times > better. Not sure what your preceived problem is. The nmea is only good > for getting the seconds time. Not more accurate time. You do not want it > involved in time setting if the PPS is working. Idiot. The PPS pulses and NMEA sentences need to be "close enough" before ntpd will accept them. Usually that means the the NMEA sentence needs to arrive during the bounds of the second it is naming. It is not uncommon to have to adjust the offset to fix this problem. > > The GPS provides 9600bps serial comms. Would it help to speed this up to > > 19200bps? I've already disabled all NMEA sentence output for sentences that > > "aren't useful for timekeeping" but at this moment i have to use external > > clocks to sync against. > > I presume that the unreadable (to me) symbol was milli not micro > seconds. I do not believe that one could get the nmea down to > microseconds. As I understand it the gps device sends out the nmea when > it has time. Ie, much of the fluctuation is internal rather then > transmission, although of course transmission is variable as well > (consiidering that the length of the sentences fluctuate). > > > > > Few questions: > > > > 1) Can i get a 'true PPS sync' with this setup? > > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? > > What is untrue about the gpsd pps? > > > > > 2) What could i possibly do to get NTP to sync/accept the NMEA data, > > other than set it as a truechimer in the configuration? > > nmea will always have very bad fluctuations. You want to use the PPS. That is what he is trying to do. You can't use the PPS without something to name the seconds. This can either be the NMEA sentences provided by the ATOM driver. Or it can be some other time server. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On Tue, Dec 9, 2014 at 12:24 PM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: > Paul, does the NMEA (or ATOM) driver solve the problem of having perhaps a > couple of hundred milliseconds peak-to-peak jitter in the GPS serial data, > thereby preventing NTP using the PPS source? As I mentioned previously it's still possible to use refclock 1 (LOCAL). The driver is claimed to be deprecated but it's still present in 4.2.7 so presumably will be in 4.2.8. server 127.127.22.0 minpoll 3 maxpoll 3 fudge 127.127.22.0 stratum 0 server 127.127.20.0 minpoll 3 mode 16 prefer fudge 127.127.20.0 time2 0.5 flag4 0 server 127.127.1.0 minpoll 3 prefer fudge 127.127.1.0 stratum 12 Note that in this configuration the LOCAL clock isn't *undisciplined*. You're good until you restart. If you(sometimes) have internet access you can "prefer" another server to number the seconds. If you never have internet access you'll have to wait until NTP accepts timestamps from the GPS. This will eventually happen with an 18x given a descent sky view. My NTP appliances manage to number seconds via NMEA or the equivalent so while folks are fixing things they could fix this too. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On Tue, Dec 9, 2014 at 3:17 PM, Nomen Nescio wrote: > The PPS pulses and NMEA sentences need to be "close enough" before > ntpd will accept them. Usually that means the the NMEA sentence needs to > arrive during the bounds of the second it is naming. > If that's not happening your GPS is buggy and should be fixed or replaced. However it's not enough for NTP. The timestamps need to be consistently in the same acceptable window. Some units are quite bad at this so ... > It is not uncommon to have to adjust the offset to fix this problem. > you can't get a reliable lock with a static offset. > You can't use the PPS without something to name the seconds. This can > either be the NMEA sentences provided by the ATOM driver > Refclock 22 (ATOM) doesn't provide NMEA. People that want to use NMEA really should buy a GPS that can deliver stable sentences. This: *127.127.20.0.FURY. 0 l18 3770.0000.008 0.010 not this: x127.127.20.0.AMTK. 0 l48 3770.000 28.560 33.520 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 2014-12-09, Sander Smeenk wrote: > Quoting William Unruh (un...@invalid.ca): > >> > This partly works. NTP syncs against the PPS signal but the NMEA signal >> > is always marked as falseticker even though i managed to bring down the >> > offset to -1.5??sec average by fudging the time a bit. The NMEA signal >> > offset fluctuates a lot. From ~ -65??sec to ~ +75??sec. >> Who cares? If the system is locking on to the PPS that is far far >> greater accuracy than you will ever get from nmea. Over 1 times >> better. Not sure what your preceived problem is. > > I don't want to rely on only external timesources to get a correct time > sync. That's why i care (a little). I would be happier if i had a couple > of NTP-sources *and* the NMEA signal, i've seen it done with serial > attached GPS devices and i'm looking for tips to get it done myself. No, I was asking about the nmea signal. Its only purpose is to give the seconds to the pps signal, and it (uaully) has no trouble doing that. It only needs an accuracy of 500ms to do that. It is the pps that gives the micro-sec accuracy (well even nsec accuracy, but the computer interrupt handling makes that worse to about 1 micro sec accuracy). > > >> > 1) Can i get a 'true PPS sync' with this setup? >> > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? >> What is untrue about the gpsd pps? > > It is 'untrue' because it is proxied by a piece of code while the kernel > has PPS support itself. That can only introduce more 'noise' in the signal. > This is what i've learnt on the internet, at least. No. It captures the interrupt trigged by the serial port. The serial port times the arrival of the pps signal. That is all any piece of code can do. No additional noise. > > > -Sndr. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 09/12/2014 20:51, Paul wrote: [] As I mentioned previously it's still possible to use refclock 1 (LOCAL). The driver is claimed to be deprecated but it's still present in 4.2.7 so presumably will be in 4.2.8. server 127.127.22.0 minpoll 3 maxpoll 3 fudge 127.127.22.0 stratum 0 server 127.127.20.0 minpoll 3 mode 16 prefer fudge 127.127.20.0 time2 0.5 flag4 0 server 127.127.1.0 minpoll 3 prefer fudge 127.127.1.0 stratum 12 Note that in this configuration the LOCAL clock isn't *undisciplined*. You're good until you restart. If you(sometimes) have internet access you can "prefer" another server to number the seconds. If you never have internet access you'll have to wait until NTP accepts timestamps from the GPS. This will eventually happen with an 18x given a descent sky view. My NTP appliances manage to number seconds via NMEA or the equivalent so while folks are fixing things they could fix this too. There's actually an elegant (I think) piece of code in the Windows port of NTP which uses the PPS time (measured via interrupt) as the timestamp of the first NMEA sentence received, thus removing all the offset, and the offset variation, from the NMEA sentence timing. Perhaps something like this could be a more generally available option for GPS/PPS systems? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On Tue, Dec 09, 2014 at 03:29:45PM +0100, Sander Smeenk wrote: > I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0. > The GPS provides a PPS signal via serial and i use gpsd to provide the > NMEA sentences and pulse data in shared memory to NTP. > > This partly works. NTP syncs against the PPS signal but the NMEA signal > is always marked as falseticker even though i managed to bring down the > offset to -1.5ųsec average by fudging the time a bit. The NMEA signal > offset fluctuates a lot. From ~ -65ųsec to ~ +75ųsec. > 1) Can i get a 'true PPS sync' with this setup? > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? If it's a recent version of gpsd which uses kernel timestamps (check for KPPS messages in "gpsd -D 4" output), you may already have a "true PPS sync". The PPS and NMEA timestamps are paired in gpsd, so it's not necessary to add the NMEA source to ntpd. To avoid problems with the falseticker, you can remove the source from ntpd configuration or use the noselect option to never use it and only monitor it. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 10/12/2014 10:24, Miroslav Lichvar wrote: [] If it's a recent version of gpsd which uses kernel timestamps (check for KPPS messages in "gpsd -D 4" output), you may already have a "true PPS sync". The PPS and NMEA timestamps are paired in gpsd, so it's not necessary to add the NMEA source to ntpd. To avoid problems with the falseticker, you can remove the source from ntpd configuration or use the noselect option to never use it and only monitor it. That sound helpful! With -D 4 I get a list of devices ending with "PPS", but presumably that is not the same as "KPPS"? I did try an apt-get first to update gpsd but it seems I have the most recent available. It seems I have 3.6. Do I need a development version or...? -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On Wed, Dec 10, 2014 at 11:50:22AM +, David Taylor wrote: > With -D 4 I get a list of devices ending with "PPS", but presumably that is > not the same as "KPPS"? In gpsd the PPS without K is the userspace timestamping. With kernel timestamping the log looks like this: gpsd:PROG: PPS edge: 1, cycle: 100 uSec, duration: 78 uSec @ 1418214654.07216 gpsd:INFO: PPS hooks called with accepted 1418214653.99223 offset 0.00777 gpsd:PROG: PPS edge accepted 1418214653.99223 offset 0.00777 gpsd:PROG: KPPS assert 1418214653.99223, sequence: 73 - clear 1418214654.20573, sequence: 73 gpsd:PROG: KPPS data: using clear gpsd:PROG: KPPS cycle: 99 uSec, duration: 21 uSec @ 1418214654.20573 > I did try an apt-get first to update gpsd but it > seems I have the most recent available. It seems I have 3.6. Do I need a > development version or...? The kernel PPS support was added in 3.0 or so, but gpsd needs to be compiled with the timepps.h header, similarly to ntpd for the ATOM and other drivers. Also, some gpsd versions had bugs in the PPS/KPPS support and I'm not sure if 3.6 was a good or bad. The latest version - 3.11 is working well for me, 3.10 was not. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On 10/12/2014 12:39, Miroslav Lichvar wrote: On Wed, Dec 10, 2014 at 11:50:22AM +, David Taylor wrote: With -D 4 I get a list of devices ending with "PPS", but presumably that is not the same as "KPPS"? In gpsd the PPS without K is the userspace timestamping. With kernel timestamping the log looks like this: gpsd:PROG: PPS edge: 1, cycle: 100 uSec, duration: 78 uSec @ 1418214654.07216 gpsd:INFO: PPS hooks called with accepted 1418214653.99223 offset 0.00777 gpsd:PROG: PPS edge accepted 1418214653.99223 offset 0.00777 gpsd:PROG: KPPS assert 1418214653.99223, sequence: 73 - clear 1418214654.20573, sequence: 73 gpsd:PROG: KPPS data: using clear gpsd:PROG: KPPS cycle: 99 uSec, duration: 21 uSec @ 1418214654.20573 I did try an apt-get first to update gpsd but it seems I have the most recent available. It seems I have 3.6. Do I need a development version or...? The kernel PPS support was added in 3.0 or so, but gpsd needs to be compiled with the timepps.h header, similarly to ntpd for the ATOM and other drivers. Also, some gpsd versions had bugs in the PPS/KPPS support and I'm not sure if 3.6 was a good or bad. The latest version - 3.11 is working well for me, 3.10 was not. Many thanks, Miroslav. For some reason, gpsd seems to be stuck at a lower release for the Raspberry Pi version of Debian, so I will have a go at recompiling it once I can find the right instructions! That's if there's no development version I can get with apt-get, and I haven't found out how to do that yet. Still learning! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
On Sat, Dec 13, 2014 at 2:52 AM, David Taylor < david-tay...@blueyonder.co.uk.invalid> wrote: > For some reason, gpsd seems to be stuck at a lower release for the > Raspberry Pi version of Debian, so I will have a go at recompiling it once > I can find the right instructions! That's if there's no development > version I can get with apt-get, and I haven't found out how to do that > yet. Still learning! If you don't want to cross-compile you need gcc, libncurses5-dev and scons. It's slow but simple. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
Sander Smeenk wrote: > 2) What could i possibly do to get NTP to sync/accept the NMEA data, > other than set it as a truechimer in the configuration? Increase TOS MinDist ? -- E-Mail Sent to this address will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP, GPSD & PPS
Maybe you should read to the end of these threads before posting. On Mon, Dec 15, 2014 at 10:34 PM, E-Mail Sent to this address will be added to the BlackLists wrote: > Increase TOS MinDist ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
