Description of problem: On F7 I am unable to get gpsd + ntp working 1PPS on Motorola Encore GPS in nmea mode. It worked perfectly on FC6. Hardware is identical, infact the machine has been updated from FC6 to F7. I have filed bugs against: kernel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242211 ntp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242891 On the ntp 242891 bug we even tried the old FC6 ntp package, it still refuses to accept the 1PPS. Version-Release number of selected component (if applicable): How reproducible: 1PPS does not work Steps to Reproduce: 1. 2. 3. Actual results: [root@primary ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *SHM(0) .GPS. 0 l 8 16 377 0.000 9.148 2.778 SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 0.001 +x1.tonyurban.co 134.84.84.84 3 u 9 64 377 234.465 -165.88 0.859 +ns37256.ovh.net 130.159.196.118 3 u 50 64 377 314.344 -167.54 0.427 -silk.lonewander 33.72.247.181 2 u 6 64 377 176.105 -347.38 14.854 192.168.0.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 10.255.255.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 NTP.MCAST.NET .MCST. 16 u - 64 0 0.000 0.000 0.001 LOCAL(0) .LOCL. 10 l 40 64 377 0.000 0.000 0.001 [root@primary ~]# Expected results: [root@primary ~]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +SHM(0) .GPS. 0 l 8 16 377 0.000 9.148 2.778 *SHM(1) .GPS1. 0 l - 16 0 0.000 0.000 0.001 +x1.tonyurban.co 134.84.84.84 3 u 9 64 377 234.465 -165.88 0.859 +ns37256.ovh.net 130.159.196.118 3 u 50 64 377 314.344 -167.54 0.427 -silk.lonewander 33.72.247.181 2 u 6 64 377 176.105 -347.38 14.854 192.168.0.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 10.255.255.255 .BCST. 16 u - 64 0 0.000 0.000 0.001 NTP.MCAST.NET .MCST. 16 u - 64 0 0.000 0.000 0.001 LOCAL(0) .LOCL. 10 l 40 64 377 0.000 0.000 0.001 [root@primary ~]# Additional info:
Created attachment 156400 [details] ntp config file
Created attachment 156401 [details] /etc/rc.d/init.d/gpsd startup for the server You will see, that I modified the gspd startup script so its running as: /usr/sbin/gpsd ${GPSD_OPTS} -n -N /dev/ttyS0 & This way its running as root, so it has full permissions to do anything. [root@primary ~]# ps aux | grep gpsd root 2635 0.0 0.1 14132 1712 ? S<l Jun05 0:00 /usr/sbin/gpsd -n -N /dev/ttyS0 root 10100 0.0 0.0 4004 692 pts/2 R+ 08:29 0:00 grep gpsd [root@primary ~]#
Created attachment 156455 [details] gpsd full diag log startup to 1 minute gpsd has a bug in F7. You can see at the start while its trying to sync: gpsd: packet sniff finds type -1 gpsd: pps-detect (DCD) on /dev/ttyS0 changed to 1 gpsd: PPS pulse rejected. No fix. By the time its in 4800 baud nmea I see no more pps messages, but there are many as its starting, it does see the PPS.
Since gpsd code has not changed, this is weird. As I have no experience with PPS and gpsd (I don't have a gps that does PPS), I was going to refer upstream to this bug, however I see you already have. Please respond to their request for more info.
Where do we go from here? The bug is filed against gpsd on F7, but I see only (matt) is listed no one from Redhat. I have a bug filed against ntp, but its not ntp that is faulty its gpsd is ignoring the DCD 1PPS but does not at the start when its starting and trying to ID the GPS, we have proved NTP works and diag dump shows gpsd is at fault. Matt, can you refer this to someone so it gets fixed. I did email the gpsd list, but no replies. I really want it fixed, for critical timing no PPS is too erratic. Thanks!
(In reply to comment #5) > Where do we go from here? The bug is filed against gpsd on F7, but I see only > (matt) is listed no one from Redhat. I am the maintainer of gpsd in Fedora. Pre Fedora 7, there was Fedora Core and Fedora Extras. Fedora Extras was a community based extension to Fedora sanctioned by Red Hat, and I added gpsd to it so I could use my gps for positioning information with my laptop. Between 6 and 7, Fedora Core and Extras merged, so some packages have volunteer packagers like myself. > I have a bug filed against ntp, but its not ntp that is faulty its gpsd is > ignoring the DCD 1PPS but does not at the start when its starting and trying to > ID the GPS, we have proved NTP works and diag dump shows gpsd is at fault. > Matt, can you refer this to someone so it gets fixed. I did email the gpsd > list, but no replies. > I really want it fixed, for critical timing no PPS is too erratic. > Thanks! I agree that it is an important fix. I'm not fully convinced yet that gpsd is ignoring the PPS after the initial startup. The line "gpsd: PPS pulse rejected. No fix." does not neccesarily indicate that gpsd is ignoring PPS pulses forever, just that it is ignoring that current one (for that second). You say that gpsd log is for one minute; if so that line should appear about 60 times, but it doesn't making me think that gpsd is accepting many of the PPS pulses. It is unfortuate that the gpsd list doesn't yet have a solution, but I wouldn't discount them yet; many of them are also volunteers and they may still yet respond. They are the experts on gpsd and our best resource. Unrelated to this bug: Out of curiosity, what do you need the PPS timing for?
Thanks for the reply! As long as it gets fixed that is fine, I am not concerned with a instant result, just as long as someone is going to look at the issue and its proceeding. I was only concerned that I only got one reply to the email I posted to the list. Thankfully a lot of diagnostic tips given to try, proved in the log that something in gpsd is wrong (on F7). But from there its stopped again. I dropped another message and still waiting. Well we can both agree and see the DCD is detected and its trying 1PPS, but naturally as its 'starting up' there is no lock as it has not identified the GPS message type. But if you look at the attached log, its simply 'given up' as by the time its in nmea mode, there is no DCD / 1PPS detetcted any more. It seemed to give up at even 9600 nmea, and by the time its in 4800 nmea its already 'too late'. Perhaps there is some error in nmea mode (any baud) on F7 its simply not trying to detect DCD line, and hence no 1PPS. The DCD /PPS messages hae stopped BEFORE its locked up. It worked fine on FC6, I never had an issue. Clearly as the DCD is detected, we know even the serial port driver is detecting and relaying the DCD line to gpsd. Why is PPS so critical? GPS timing is useless without it. As in nmea mode the messages can be delayed and erratic. That is why only expensive and developed GPS units provide a proper PPS pulse, as its designed for use in critical timing applications. Dumps of the ntp server show varying jitter against the gps device. However I had stability almost down to 0.0001 on my PPS stabilized source in FC6. How can you run a proper class 1 reference ntp server without an accurate time source? I require precise timing for my use in my application. A diagnostic of most servers you publically find in the fedora ntp pool, reflect a 1PPS reference. Also my system becomes totally internal and self reliant without the use of any external time servers. Thanks! David
Thanks to some amazing help from Mick we proved it was gpsd at fault and compiled a working gpsd with PPS support for F7
*** Bug 242891 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Thanks to some amazing help from Mick we proved it was gpsd at fault and > compiled a working gpsd with PPS support for F7 Awesome. What are the changes required in compilation so this can be fixed in the real package? I'd like to include this in the F7-updates package asap.
Matt, I know its all supposed to be introduced fully in gpsd 2.35. 2.36 will include support for motorola gps (binary mode). There are serial port changes and timing issues. Do you want a copy of the changes needed right now? I currently have a svn installed running not only pps, but it also have the motorola binary and mnea mode in it. I have got all the data necessary to build a 2.35, so you coulod package up a 2.35 for Fedora all working properly.
Matt, I will get Mick to also get on this bug and can supply you everything.
Can gpsd be at least updated to the current build 2.37 the repositories still have 2.34-8 its so old....
I am closing this bug as no one seems to be maintaining gpsd on fedora :( gpsd is now up to 2.37 and still only 2.34 exists on fedora.
Not technically true. I no longer have the time to, so I relinquished ownership of the package, and now Douglas Warner owns it. Give him a little time before you give up completely.
*** Bug 433403 has been marked as a duplicate of this bug. ***
gpsd-2.37-2.fc7 has been submitted as an update for Fedora 7
gpsd-2.37-2.fc8 has been submitted as an update for Fedora 8
gpsd-2.37-2.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gpsd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-2607
marble-0.5.1-2.fc8, gpsd-2.37-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
gpsd-2.37-2.fc7, marble-0.5.1-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.