Re: [gpsd-users] 1PPS not working with RPi 3 B+ and Stretch

[Alan Scott]

If I may add my 2 cents in here......could something be amiss with the TTY0 / AMA0 / S0 (in other words what the PPS signal is labeled)?

I know for me that was very confusing.........also are you using Stretch DESKTOP or Stretch LITE...?

Alan

On 07/19/2018 10:36 AM, Chris Smith wrote:

Hello,

I've followed the ntpsec.org how-to for creating a stratum 1 NTPsec timeserver, but am having an issue with 1PPS.

https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/

Here's what I can provide:

I am using the latest Raspbian Stretch image with simply SSH enabled at boot and configured to connect to my WPA2-Personal wireless network. 

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.

In addition to GPS $GNGGA messages, it also outputs Beidou and GLONASS messages:

(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. 

----

Note: Using "clockmaker", I observe that after the first reboot which was initiated by "sudo ./clockmaker --config", I see that CPU governor is not set to "performance", but rather "ondemand".

I manually set 'GOVERNOR="performance"' in /etc/default/cpufrequtils and this was resolved the issue once "systemctl restart cpufrequtils" was issued.

----

Moving on, I can verify that by issuing a cat of /dev/gpsd0, I can see the GPS messages.

Additionally, here is a screen cap of my gpsmon session on my Pi:

sudo ./gpsd/gpsmon /dev/gpsd0

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

 us.pool.ntp.org                         .POOL.          16 p    -  256    0   0.0000   0.0000   0.0010

+freemont.nerdboy.net.au                 216.218.192.202  2 u    4   64    7 100.1850   7.3325  15.4553

+horp-bsd01.horp.io                      146.186.222.14   2 u    2   64    7  41.7758  -5.0000  19.6781

*frigg.fancube.com                       152.2.253.126    2 u    1   64    7  29.2760  -0.1713  15.8200

+ntp3.junkemailfilter.com                216.218.254.202  2 u    2   64    7  89.8598  -3.8349  18.0334

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.

Thanks!

Chris Smith