I am using a UM220-III N GPS receiver. It has 1PPS out at 3.3v, as well as 3.3v logic levels for serial (the specs sheet says TTL). It uses a 500ms wide pulse.
(79) $GNRMC,120543.000,A,3016.502582,N,08151.367995,W,0.000,351.890,180718,,E,A*21
(77) $GNGGA,120543.000,3016.502582,N,08151.367995,W,1,11,0.779,10.964,M,0,M,,*4A
(55) $GNGLL,3016.502582,N,08151.367995,W,120543.000,A,A*52
(63) $GNGSA,A,3,27,16,23,7,9,11,8,18,28,1,30,,1.316,0.779,1.060*23
(45) $GNGSA,A,3,,,,,,,,,,,,,1.316,0.779,1.060*27
(65) $GPGSV,3,1,11,1,3,170,25,7,38,320,50,8,79,127,41,9,55,254,38*46
(69) $GPGSV,3,2,11,11,26,171,30,16,20,52,41,18,16,150,20,23,46,199,35*43
(55) $GPGSV,3,3,11,27,49,48,43,28,8,258,26,30,12,308,45*49
(18) $BDGSV,1,1,00*68
With this exact GPS module, I have 1PPS working on CentOS 7 with DCD as 1PPS on an RS232 connection. I can get to +/- 5uS accuracy.
During "clockmaker --config", I chose the "Uputronics" board as it uses the same GPIO pin for 1PPS that I've been using for previous testing.
Moving on, I can verify that by issuing a cat of /dev/gpsd0, I can see the GPS messages.
Everything looks good, yes? (aside from how PuTTY is handling the ncurses characters...)
I then started gpsd. I took a look at "ipcs -m"...
address@hidden:~ $ sudo ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 163840 pi 600 393216 2 dest
0x00000000 229377 pi 600 524288 2 dest
0x4e545030 262146 root 600 80 1
0x4e545031 294915 root 600 80 1
0x4e545032 327684 root 666 80 1
0x4e545033 360453 root 666 80 1
0x4e545034 393222 root 666 80 1
0x4e545035 425991 root 666 80 1
0x4e545036 458760 root 666 80 1
0x4e545037 491529 root 666 80 1
I then started up ntpd and again inspected "ipcs -m"...
address@hidden:~ $ sudo ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 163840 pi 600 393216 2 dest
0x00000000 229377 pi 600 524288 2 dest
0x4e545030 262146 root 600 80 2
0x4e545031 294915 root 600 80 2
0x4e545032 327684 root 666 80 1
0x4e545033 360453 root 666 80 1
0x4e545034 393222 root 666 80 1
0x4e545035 425991 root 666 80 1
0x4e545036 458760 root 666 80 1
0x4e545037 491529 root 666 80 1
So it looks like 0x4e545030 and 0x4e545031 are working correctly?
I then issue "sudo ./gpsd/ntpshmmon" and am presented with the following:
address@hidden:~ $ ./gpsd/ntpshmmon
ntpshmmon version 1
# Name address@hidden Clock Real L Prec
No data scrolls by.
However, if I issue "sudo ./gpsd/ntpshmmon -v", I see the following:
unit 0 status 1
unit 1 status 1
unit 2 status 1
unit 3 status 1
unit 4 status 1
unit 5 status 1
unit 6 status 1
unit 7 status 1
unit 8 status 1
unit 9 status 1
unit 10 status 1
...
unit 255 status 1
and the series repeats very quickly until Ctrl+C.
I then inspected "ntpq -p"...
address@hidden:~ $ sudo ./ntpsec/build/main/ntpclients/ntpq -p
remote refid st t when poll reach delay offset jitter
=======================================================================================================
SHM(1) .PPS. 0 l - 64 0 0.0000 0.0000 0.0010
SHM(0) .GPS. 0 l - 64 0 0.0000 0.0000 0.0010
Sorry for the formatting... Essentially I see a reach of "0" for both SHM(0) and SHM(1).
So it appears that the SHM drivers for GPS and 1PPS are working, but ntpsec can't interpret the data?
I was referred to this list by Eric S. Raymond.