[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chris Smith
Subject: Re: [gpsd-users] 1PPS not working with RPi 3 B+ and Stretch
Date: Fri, 20 Jul 2018 16:21:30 -0400

Ok, I'll try to clear a few things up...

"Interesting part.  Why did you pick it?"

I chose this dev board that uses the UM220-III NL chip because it speaks the mostly universal NMEA-0183 protocol (I've provided examples of it's output in previous messages), feeds that over RS232 (and I later found +3.3VDC TTL/CMOS or whatever) and provides 1PPS (500ms wide) timed on the GPS radio signal. It was also a good price online and came with a GPS antenna for about USD$20. I bought two module/antenna pairs, and with shipping it came to about $60 with a two week wait from China.

The single module is connected to two devices at the same time

One device (CentOS workstation) uses RS232 w/ 1PPS on DCD. 

The other device is the RPi 3 B+ which uses the hardware UART on the GPIO pins and 1PPS on GPIO_04 (at the moment, I've been trying different pins.)

I see nothing wrong from an electrical standpoint with this configuration.

"What are those asterisks doing there?  That looks very wrong."

As far as the mystery " * " in my commands, not sure where those came from. They are not the original commands I ran and were not part of the output I provided in my e-mails.

Regarding this...

"That is just plain wrong.  Take a look at the RS-232 spec... "

My understanding of RS232 is sound enough to know that the webpage I referenced is technically correct and sufficient for describing what I am trying to discuss. I will say that perhaps I shouldn't have mentioned RS232 just yet since we are talking about an RPi 3 B+?

"console is wrong: "

Every write-up I am finding is saying that we must detach the console process from the serial port in order for this GPSD->NTPD thing to work correctly. What you are providing me appears to re-enable the console process on /dev/ttyAMA0? Additionally, I believe one needs to remove " kgdboc=ttyAMA0,9600" from their cmdlines.txt as well.

Please see

Per ESR -
"Only two specific changes need to be made to make the HAT work. First in the file /boot/cmdline.txt, remove this part "console=ttyAMA0,115200 kgdboc=ttyAMA0,115200". That frees the serial port from console use so  the GPS can use it."

"Looks good.  But still no evidence the serial is working."

I think I've provided examples of the serial data driven output of gpsd in my previous e-mails. Everything is working. I can cat the port, load up gpsmon and get 1PPS pulses in addtion to NMEA sentences, and all the other etc...

"OK, but I also have this:
Are you sure your ttyAMA0 is working without it?"

Whoops, yes I have that in there too.

For notes, here's an interesting thread about that function.

"Neither have the correct time.  Which points, again, to your GPS."

Gary, you're saying that my GPS device doesn't have a time fix? I find that unusual. Here's why.

I've described two ways to interface with the serial data coming out of the GPS module. I am using both, at the same time.

One way is via RS232 to a serial port. This is what I am using on my CentOS 7 box. 

Hang in there with me while I explain why I'm mentioning this machine.

The other way is via the TTL out on the GPS module itself. Because of the way the pin headers are wired, I can drive the Pi 3 B+ AND a RS232 serial port at the same time from this one module using different voltages.

I use the +3.3VDC for the Pi and RS232 for my workstation. What this demonstrates is that both devices should be receiving the exact same serial data AND 1PPS signals (RS232 DCD on CentOS box and GPIO_04 on RPi 3 B+).

With me so far?

What this configuration allows me to do is compare how different versions of GPSD on different distros, kernels, and architectures work. Super useful, yes?

So going back to the GPS bad time thing, here's a copy/paste from my CentOS 7 box that is using the exact same serial and 1PPS data as the RPi 3 B+...

address@hidden ~]$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
*    .PPS.            0 l    5    8  377    0.000   -0.069   0.008
+     .NIST.           1 u   10   16  377   46.968    0.587   2.687
+    .NIST.           1 u   10   16  377   59.459    2.123   2.336

Since I've been monkeying with it during the course of this RPi testing, I've seen the offset vary more wildly, probably from rebooting and un/plugging things, but I've had this thing rocksolid to +/- 5uS when I thermally isolate it from the room it is in.

I believe this shows that ntpd is preferring my 1PPS clock to NIST's servers. Pretty cool. I don't believe this would work using this configuration if my GPS module didn't have valid, accurate, and precise time.

Futher, please see the following (sent earlier) from the RPi 3 B+:

gpsd:PROG: KPPS:/dev/pps0 assert  1532034832.977119719, sequence: 2151, clear   0.000000000, sequence: 0 - using: assert
gpsd:PROG: KPPS:/dev/pps0 Assert cycle: 1000028, duration:       0 @  1532034832.977119719
gpsd:PROG: PPS:/dev/pps0 Assert cycle: 1000028, duration:       0 @  1532034832.977119719
gpsd:PROG: PPS:/dev/pps0 Assert ignored missing last_fixtime <- where does this value "last_fixtime" come from?
gpsd:PROG: GNRMC sentence timestamped 211353.00.
gpsd:PROG: GNRMC starts a reporting cycle.
gpsd:PROG: GNGGA sentence timestamped 211353.00.
gpsd:PROG: GNGLL sentence timestamped 211353.00.
gpsd:PROG: GNGLL ends a reporting cycle.
gpsd:PROG: xxGSA sets mode 3 (*notice in the below example that these lines are different?)
gpsd:PROG: xxGSA sets mode 3
gpsd:PROG: Partial satellite data (1 of 3).
gpsd:PROG: Partial satellite data (2 of 3).
gpsd:INFO: PRN=  5 az=254 el=79 (-0.183417, -0.052594, 0.981627)
gpsd:INFO: PRN=  6 az= 67 el=25 (0.834261, 0.354123, 0.422618)
gpsd:INFO: PRN=  9 az= 43 el= 9 (0.673602, 0.722350, 0.156434)
gpsd:INFO: PRN= 12 az=232 el=42 (-0.585606, -0.457526, 0.669131)
gpsd:INFO: PRN= 13 az=163 el=16 (0.281046, -0.919259, 0.275637)
gpsd:INFO: PRN= 17 az=131 el= 6 (0.750575, -0.652465, 0.104528)
gpsd:INFO: PRN= 19 az=125 el=27 (0.729870, -0.511060, 0.453990)
gpsd:INFO: PRN= 25 az=287 el=31 (-0.819713, 0.250611, 0.515038)
gpsd:INFO: PRN= 29 az=318 el=15 (-0.646331, 0.717823, 0.258819)
gpsd:INFO: PRN=172 az=322 el=36 (-0.498081, 0.637514, 0.587785)
gpsd:INFO: Sats used (10):

If we convert everything, we can see that the epoch time of 1532034832.977119719 converts to Thursday, July 19, 2018 9:13:52.977 PM.
The GNRMC, GNGGA, GNGLL messages all agree that UTC local time is 21:13:53 (9:13:53 PM EST).

The GPS and PPS assert times match and are correct for my location.

Something that is really interesting in all of this is that I can "apt -y install" the "official" gpsd from the Raspbian repo and I get PPS assert accepted messages and can use that info in the "official" Raspbian NTPd, just everything isn't ticking as accurately as I'd like.

Thanks for your time, let me know if you have any questions.

Chris S

On Fri, Jul 20, 2018 at 2:11 PM, Gary E. Miller <address@hidden> wrote:
Yo Chris!

On Fri, 20 Jul 2018 07:58:37 -0400
Chris Smith <address@hidden> wrote:

> Here's the manufacturer page for my module:

Interesting part.  Why did you pick it?

> Here's the PDF specs sheet:

That is just a data sheet.  What are the technical specs?  Specifically
what does it speak?  NMEA?  Custom binary?  Or?

> Here's a great write up that has detailed chip pinouts:

Except nothing on what dialect it speaks...

You realize the time server howto is ONLY for the u-blox?  It
specifically turns off ALL other drivers.  So that is why I am so
interested in your GPS dialect.

> Here's my mapping of the 1PPS out from the chip to the pin header on
> the board (orange circles):

OK, but how did you hook it up to the Pi?

> The board uses a SP3232EEN TTL-to-RS232 level converter.  Here's that
> datasheet:

Now I'm really confused.  The Pi does not use RS-232.  Where are yuo
using RS-232?  You put RS-232 on the Pi GPIO and you will blow it up.

> After some deep research, I have determined that only the DATA (TX/RX)
> lines need to be converted to RS232 voltages (-3VDC to -25VDC for a
> "1" bit).

That depends a lot on what you are connecting the RS-232 to.  That is
still unsaid.

> al-data-communications/rs232-signal-voltage-levels.php

That is just plain wrong.  Take a look at the RS-232 spec, not some
hack's misunderstanding of it.

> This shows that DCD PPS assert can be driven by +3.3VDC directly from
> the UM220 - III NL chip.

What DCD where?  The Pi has no DCD.

> After the soldering was done, I connected a DB9 "non-null-modem"
> extension cable from the GPS module to the serial port on my
> workstation.

Workstation?  I thought we were talking about a Pi?  What sort of

> I have everything working on my CentOS 7 machine with 1PPS with this
> exact device. It keeps time to +/- 5uS.

Good.  Why tell us what works?  It is supposed to work.  Except the DCD
may be flakey depending on the type of your "RS-232" port.

None of the above applies to your Pi problem.

> Additionally, for the Raspberry Pi, I have electrically connected,
> from *before* the 3.3VDC-to-RS232 level conversion, jumper wires that
> feed TTL (+3.3VDC, not +5VDC) serial to the RPi. The 1PPS is provided
> over GPIO18.

OK, so we can ignore evwerything before this last paragraph as noise.

> Ok, that should cover the 1PPS (and GPIO serial) info.

Not really.  Can you see the serial data with 'cat' or 'miniterm'?  What
is the port speed?  Does the PPS work?

> Moving on to /boot/config.txt and /boot/cmdline.txt...
> address@hidden:~ $ cat */boot/cmdline.txt*

What are those asterisks doing there?  That looks very wrong.

> dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=bff404cd-02
> rootfstype=ext4 elevator=deadline rootwait quiet
> splash plymouth.ignore-serial-consoles nohz=off

console is wrong:

dwc_otg.lpm_enable=0 console=ttyAMA0,9600 kgdboc=ttyAMA0,9600 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
/boot/cmdline.txt lines 1-1/1 (END)

> address@hidden:~ $ tail */boot/config.txt*

What are those asterisks doing there?  That looks very wrong.

> #Timeserver customizations begin here
> dtoverlay=pi3-disable-bt
> enable_uart=1
> gpu_mem=0
> dtoverlay=pps-gpio,gpiopin=18

OK, but I also have this:


Are you sure your ttyAMA0 is working without it?

> address@hidden:~ $ sudo ppstest /dev/pps0
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1532031771.961960159, sequence: 1315 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1532031772.961926789, sequence: 1316 - clear
> 0.000000000, sequence: 0

Looks good.  But still no evidence the serial is working.

> address@hidden:/home/pi# ./gpsd/gpsd -n -N -D4 /dev/gpsd0

That works for debugging, but do not run it that way normally.

And since you are running it with debugging, what did the debugging say?

> Changing fonts here and I'm too lazy to try to fix it, sorry :)

Sorry?  I'm just seeing plain ascii?

> I then start a new PuTTY session and then try to run "ntpshmmon" as
> downloaded/built by the clockwork script...
> address@hidden:/home/pi# ./gpsd/ntpshmmon
> ntpshmmon version 1
> #      Name address@hidden               Clock                Real
>     L Prec

As you previsoulsy descsribed.  And as I previsously said: your debug
output showed your GPS did not have the correct time yet.  I asked you
to wait 30 minutes and verify that your GPS had a time lock.

> address@hidden:/home/pi# pstree -paul | fgrep gpsd
>   |   |                       `-gpsd,1035,nobody /dev/gpsd0 -n -N -D4
>   |   |                           `-{gpsd},1036


> gpsd:PROG: PPS:/dev/pps0 Assert cycle: 1000028, duration:       0 @
> 1532034832.977119719
> gpsd:PROG: PPS:/dev/pps0 *Assert ignored missing last_fixtime <-
> where does this value "last_fixtime" come from?*

gpsd reads only from your GPS.  So you GPS is not providing valid time.

> gpsd:PROG: GNRMC sentence timestamped 211353.00.

See, not a valid time.  I'l ask again, did you allow your GPS to
run for 30 minutes before seeing if cgps was reporting a good time?
Doid you cgps ever report a good time?

> *Additional observations from my CentOS 7 box (using traditional DCD
> 1PPS, not a Raspberry Pi device)*

Ah, lost me?  Let's just stick to your problem, the Pi.

> What I find interesting is that on the CentOS 7 box, /dev/pps0 only
> gets created when gpsd is running.


> On the RPi, /dev/pps0 is created
> by, I am assuming, the "pps-gpio" module, yes?


> The only other thing I can think of is that I've run into gpsd issues
> before with this module when using a really old version of Fedora 18.

Let's stick to Raspbian.  One problem at a time.

> I *think* I remember that gpsd couldn't get either a 3D fix or a valid
> time value because of my additional Beidou and GLONASS messages

Extremely unlikely.

> Again, I don't know how to disable these on this GPS module,

Which is why I keep asking for your doc on your GPS dialect.

> Just for comparison purposes, here is the output from the two
> different gpsd instances for the same second interval per the GNRMC
> message:

Neither have the correct time.  Which points, again, to your GPS.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]