Bug 243026 - gpsd is not syncing on F7 to 1PPS
gpsd is not syncing on F7 to 1PPS
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gpsd (Show other bugs)
8
All Linux
low Severity urgent
: ---
: ---
Assigned To: Douglas E. Warner
Fedora Extras Quality Assurance
: Reopened
: 242891 433403 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-06 18:25 EDT by David
Modified: 2008-04-01 17:38 EDT (History)
2 users (show)

See Also:
Fixed In Version: 0.5.1-2.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-01 17:35:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ntp config file (2.11 KB, application/octet-stream)
2007-06-06 18:25 EDT, David
no flags Details
/etc/rc.d/init.d/gpsd startup for the server (2.09 KB, application/octet-stream)
2007-06-06 18:29 EDT, David
no flags Details
gpsd full diag log startup to 1 minute (524.05 KB, application/octet-stream)
2007-06-07 08:23 EDT, David
no flags Details

  None (edit)
Description David 2007-06-06 18:25:25 EDT
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:
Comment 1 David 2007-06-06 18:25:25 EDT
Created attachment 156400 [details]
ntp config file
Comment 2 David 2007-06-06 18:29:33 EDT
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 ~]#
Comment 3 David 2007-06-07 08:23:59 EDT
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.
Comment 4 Matthew Truch 2007-06-07 19:07:26 EDT
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.  
Comment 5 David 2007-06-09 04:56:46 EDT
Where do we go from here?  The bug is filed against gpsd on F7, but I see only
(matt@truch.net) 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!
Comment 6 Matthew Truch 2007-06-09 11:20:39 EDT
(In reply to comment #5)
> Where do we go from here?  The bug is filed against gpsd on F7, but I see only
> (matt@truch.net) 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?  
Comment 7 David 2007-06-09 21:40:53 EDT
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
Comment 8 David 2007-08-01 03:14:34 EDT
Thanks to some amazing help from Mick we proved it was gpsd at fault and
compiled a working gpsd with PPS support for F7
Comment 9 Matthew Truch 2007-08-01 08:34:28 EDT
*** Bug 242891 has been marked as a duplicate of this bug. ***
Comment 10 Matthew Truch 2007-08-01 08:38:27 EDT
(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.  
Comment 11 David 2008-01-08 17:16:54 EST
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.
Comment 12 David 2008-01-08 17:21:12 EST
Matt,

I will get Mick to also get on this bug and can supply you everything.
Comment 13 David 2008-02-21 22:16:36 EST
Can gpsd be at least updated to the current build 2.37 the repositories still
have 2.34-8 its so old....
Comment 14 David 2008-02-24 18:28:41 EST
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.
Comment 15 Matthew Truch 2008-02-26 10:56:23 EST
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.  
Comment 16 Douglas E. Warner 2008-02-28 07:39:36 EST
*** Bug 433403 has been marked as a duplicate of this bug. ***
Comment 17 Fedora Update System 2008-03-20 09:20:06 EDT
gpsd-2.37-2.fc7 has been submitted as an update for Fedora 7
Comment 18 Fedora Update System 2008-03-20 09:20:44 EDT
gpsd-2.37-2.fc8 has been submitted as an update for Fedora 8
Comment 19 Fedora Update System 2008-03-21 18:13:20 EDT
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
Comment 20 Fedora Update System 2008-04-01 17:35:13 EDT
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.
Comment 21 Fedora Update System 2008-04-01 17:38:18 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.