On 12/07/2014 12:26 PM, David Taylor wrote: > On 07/12/2014 09:44, juergen perlinger wrote: > [] >>> david-tay...@blueyonder.co.uk.invalid> wrote: >>> >>>> ln -s /dev/ttyAMA0 /dev/gps0 >>> Sure that can work. I haven't looked at Refclock 46 in any detail >>> though. >> That's indeed the way it is intended to work. The GPSD-JSON driver uses >> the same naming scheme as the NMEA driver -- It makes switching between >> NMEA and GPSD a bit more easy while experimenting. >> >> NOTE: You must also start GPSD on the same link (like 'gpsd -n >> /dev/gps0') or the driver will not find its device. >> >> If there is need for it, I'm willing to do the necessary stuff to let >> the driver do the link evaluation. Then the native device name would be >> used by the driver. This would still require the link for NTPDs sake, >> but GPSD could use ttySxy or whatever. >> >> Feel free to file a bug (well, a feature requirement) against the driver >> if you feel hampered by the current setup! > > Thanks for the TVP/TPV correction. You used to hear a lot about TVP > but it seems to have gone out of fashion today! > > I could not get this to work to start with, gpsd complaining that it > could not find a device, but reconfiguring it as you suggested to look > for /dev/gps0 rather than /dev/ttyAMA0 fixed that. So it's working, > but there is a significant problem... > > The timing variation on the serial data from the Adafruit/MTK3339 GPS > is quite large, and NTP won't sync to it alone, at least when there > are other LAN or Internet sources available. As NTP won't accept it > (marked as "-" in the tally code), the PPS which it should offer is > never accepted, so I have had to go back to using the type 22 ATOM > refclock as well as the type 46 and LAN-based servers as well. I > might just as well use type 28 (shared memory gpsd) in addition to the > ATOM driver as use type 46. Perhaps it should at least pass PPS when > it is available, or perhaps NTP should use its PPS irrespective of > whether it is a avlid time or not, but that's completely against what > appears to be good practice. I have a GPS18xLVC running with GPSD, and that puck is also known for its suboptimal (ahem) serial timing. There might be an issue with GPSD and the PPS signal, because GPSD needs still to be root when attaching the PPS line discipline. If the device is coupled via USB, there might be more issues -- AFAIK, Harlan is fiddling with an UBlox module that gives him troubles in that area.
Another thing that can go wrong: Once an ldattach daemon is running on the port, GPSD is not able to attach the PPS line discipline internally, resulting in the PPS data not being available to GPSD. I removed the 'ldattach' stancas from my UDEV/boot config that I had put there long ago. > > So it appears that type 46 does nothing for me. Perhaps I'm missing > something, though. I had been thinking that type 46 could replace > /both/ type 28 and type 22 drivers. That was the original idea... > > I've learnt a little more about Linux, though. > > Thanks for your help, and there's no need to do anything further on my > behalf. It might help others were your note about reconfiguring gpsd > after creating the symlink were on the type 46 Web page. > I think it's written there, but I have to check. It's nearly a year I wrote that up. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
