On 2014-12-09, Sander Smeenk <ssme...@freshdot.net> 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 10000 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
