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

[Gary E. Miller]

Yo Chris!

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

> Here's the manufacturer page for my module:
> http://www.unicorecomm.com/en/product/content_965.html

Interesting part.  Why did you pick it?

> Here's the PDF specs sheet:
> 
> http://www.unicorecomm.com/en/files/PDF/UM220-III%20NL_En-mail.pdf

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:
> 
> https://download.atlantis-press.com/article/25841961/pdf

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:
> 
> https://www.exar.com/ds/sp3222e_sp3232e.pdf

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.

> https://www.electronics-notes.com/articles/connectivity/seri
> 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
workstation?

> 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 fsck.repair=yes 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:

dtoverlay=pi3-miniuart-bt

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 Seen@                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

Good.

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

Correct.

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

Correct.

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

RGDS
GARY
---------------------------------------------------------------------------
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

pgplvjNfl6wbo.pgp
Description: OpenPGP digital signature