[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: Gary E. Miller
Subject: Re: [gpsd-users] 1PPS not working with RPi 3 B+ and Stretch
Date: Fri, 20 Jul 2018 14:35:33 -0700

Yo Chris!

On Fri, 20 Jul 2018 16:21:30 -0400
Chris Smith <address@hidden> wrote:

> 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

Yeah, universally borked.  No two alike, and, without knowing the
NMEA version, very open to mis interpretation.

So, did you ever find out what flavor(s) of NMEA it speaks?

> (I've provided examples of it's output in previous messages)

Can you start gpsd, wait 30 minutes, then resend the output of:
  # gpspipe -n 60

> It was also a good price
> online and came with a GPS antenna for about USD$20.

We differ on what a good price is, but you're stuck now.

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

Does not matter what GPIO pin, as long as it is otherwise unused
and setup in the boot files.

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

RS-232 has a deadband from =3V to +3v.  And most RS-232 adapters
have a deadband from -5V to +5V.  So your feeding the PPS at 0 to 3.3V
into the DCD on the workstation is in violation of the spec.

Also, your doc confuses the spec for what voltage RS-232 is supposed to
send, and what voltage is valid to receive.  Remember RS-232 is for
use over long cables.

Luckily, some RS-232 ports will still work that way.

But, not the problem at hand, just one to byte you later.

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

Well, they are i nthe emails I got...

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

See above.  But off topic.

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

Can't speak to what else you are reading.  Since you are getting
NMEA into gpsd that is a red-herring.  Sub-optimal, but functional,
like using the wrong voltage for RS-232.

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

Works for me.  Ain't broke, not gonna fix it.

> Please see

Yeah, and I'm still trying to get Eric to fix that...

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

And you also did so later on in that email.  My objection was at that
point in your email you assumed facts not yet in evidence, while changing
other test condistions.

> *"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'm just saying what your debug output says.  Without a copy of the NMEA,
as specified from the gpspipe above, I have to go with the gpsd debug

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

Off topic, again.

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

Which proves nothing.  The Pi is your problem.  Not what I asked you to

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

Yup. and it still shows the same problem as every other time you sent it.

> gpsd:PROG: PPS:/dev/pps0 *Assert ignored missing last_fixtime <-
> where does this value "last_fixtime" come from?*


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

"What you mean we white man"?

All that matters is that gpsd does not know what time it is.  Not
any "we".  gpsd ONLY gets it's time from the GPS.  It does NOT
use the local system clock.

> The GNRMC, GNGGA, GNGLL messages all agree that UTC local time is
> *21:13:53* (*9:13:53* PM EST).

Not possible.  None of GNRMC, GNGGA or GNGLL ever provide a month,
day or year.  If you only have GNRMC, GNGGA and GNGLL is is impossible
to know the month, day and year.

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

Yes, I already said your PPS is fine.  No need to keep looking at the
stuff we know is good.

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

Yes.  The timespec howto does things differently from plain git head.
And the Raspbian package is different than both.  That is intentional.

So pick one.

> just everything isn't ticking as accurately as I'd like.

What exactly are your expectations?

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

Attachment: pgpZitGLVIWKk.pgp
Description: OpenPGP digital signature

reply via email to

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