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

Gary,

Getting a little confused...

I thought you said my issue was that my GPS wasn't getting good time? For reference, it has been powered up now for about 48 hours and has a fixed outdoor antenna attached with an unobstructed view of the sky.

I will agree that the issue is likely on my Pi, but given this is a new module we might have multiple issues combining together...

Moving on...

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

I looking here for a reference:

http://freenmea.net/docs/nmea0183 (http://aprs.gids.nl/nmea/ is good too)

eg3. $GPRMC,220516,A,5133.82,N,00042.24,W,173.8,231.8,130694,004.2,W*70
              1    2    3    4    5     6    7    8      9     10  11 12


      1   220516     Time Stamp
      2   A          validity - A-ok, V-invalid
      3   5133.82    current Latitude
      4   N          North/South
      5   00042.24   current Longitude
      6   W          East/West
      7   173.8      Speed in knots
      8   231.8      True course
      9   130694     Date Stamp
      10  004.2      Variation
      11  W          East/West
      12  *70        checksum

.      1         2 3       4  5       6 7   8   9   10  11 12
       |         | |       |  |       | |   |   |    |   | |
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a*hh
 1) Time (UTC)
 2) Status, V = Navigation receiver warning
 3) Latitude
 4) N or S
 5) Longitude
 6) E or W
 7) Speed over ground, knots
 8) Track made good, degrees true
 9) Date, ddmmyy
10) Magnetic Variation, degrees
11) E or W
12) Checksum

It appears that GNRMC should be sufficient to provide UTC date and time (taken from my GPS device during the time of the writing of this email).

(78) $GNRMC,222933.000,A,3016.500098,N,08151.368588,W,0.000,16.761,200718,,E,A*12\x0d\x0a

(77) $GNGGA,222933.000,3016.500098,N,08151.368588,W,1,09,1.072,10.641,M,0,M,,*4F\x0d\x0a

(55) $GNGLL,3016.500098,N,08151.368588,W,222933.000,A,A*5B\x0d\x0a

(58) $GNGSA,A,3,12,6,2,13,29,5,15,25,,,,,1.979,1.072,1.663*14\x0d\x0a

(48) $GNGSA,A,3,172,,,,,,,,,,,,1.979,1.072,1.663*18\x0d\x0a

(62) $GPGSV,3,1,9,2,47,74,42,5,58,22,44,6,6,98,33,12,13,204,27*7D\x0d\x0a

(68) $GPGSV,3,2,9,13,48,139,39,15,31,189,35,21,2,295,12,25,21,247,41*72\x0d\x0a

(30) $GPGSV,3,3,9,29,48,314,43*76\x0d\x0a

I notice something here...

Both specs show that the end of the GMRMC message should end "a*hh", a = direction and "*hh" = checksum.

$GNRMC,222933.000,A,3016.500098,N,08151.368588,W,0.000,16.761,200718,,E,A*12\x0d\x0a

Is the "A" in the checksum field normal?

E,A*12

Per the spec, I'd expect this to look like "E*12" not "E,A*12". I think this might be a culprit.

Also, I see that you've asked for cgps output twice regarding time...

lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqklqqqqqqqqqqqqqqqqqqqqqqqqqqSeen 10k

x Time: 2018-07-20T22:37:25.000Z xx PRN Elev Azim SNR Used 9x

x Latitude: 30.27500358 N xx 2 45 79 37 Y x

x Longitude: 81.85614241 W xx 5 55 25 42 Y x

x Altitude: 34.117 ft xx 6 4 101 27 Y x

x Speed: 0.00 mph xx 12 11 202 32 Y x

x Heading: 16.8 deg (true) xx 13 51 135 37 Y x

x Climb: 0.00 ft/min xx 15 34 189 31 Y x

x Status: 3D FIX (6 secs) xx 25 19 244 36 Y x

x Longitude Err: +/- 27 ft xx 29 51 312 46 Y x

x Latitude Err: +/- 30 ft xx 172 11 319 41 Y x

x Altitude Err: +/- 117 ft xx 21 4 297 27 N x

x ECEF X, VX: n/a n/a xx x

x ECEF Y, VY: n/a n/a xx x

x ECEF Z, VZ: n/a n/a xx x

x Course Err: n/a xx x

x Speed Err: +/- 41 mph xx x

x Time offset: -0.960 sec xx x

x Grid Square: EM90bg xx x

mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqjmqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

Everything looks good there, yes? (minus the almost -1 sec offset)

Regarding gpspipe output...

address@hidden:~/gpsd $ gpspipe -r -n 60

{"class":"VERSION","release":"3.18~dev","rev":"release-3.17-157-g5e95e79","proto_major":3,"proto_minor":12}

{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyAMA0","driver":"NMEA0183","activated":"2018-07-20T22:42:47.594Z","flags":1,"native":0,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00},{"class":"DEVICE","path":"/dev/pps0","driver":"PPS","activated":"2018-07-20T22:36:52.442Z"}]}

{"class":"WATCH","enable":true,"json":false,"nmea":true,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}

$GNGGA,224249.000,3016.500283,N,08151.368472,W,1,10,0.929,10.019,M,0,M,,*46

$GNGLL,3016.500283,N,08151.368472,W,224249.000,A,A*57

$GNGSA,A,3,12,6,21,2,13,29,5,15,25,,,,1.493,0.929,1.169*15

$GNGSA,A,3,172,,,,,,,,,,,,1.493,0.929,1.169*1A

$GPGSV,3,1,10,2,44,82,38,5,53,28,45,6,2,103,25,12,9,201,31*4B

$GPGSV,3,2,10,13,53,132,30,15,37,189,25,21,6,299,31,25,18,241,40*41

$GPGSV,3,3,10,29,54,309,48,30,1,75,14*71

$BDGSV,1,1,1,172,13,320,37*5A

$GNRMC,224250.000,A,3016.500284,N,08151.368472,W,0.000,16.761,200718,,E,A*11

$GNGGA,224250.000,3016.500284,N,08151.368472,W,1,10,0.929,10.015,M,0,M,,*45

$GNGLL,3016.500284,N,08151.368472,W,224250.000,A,A*58

$GNGSA,A,3,12,6,21,2,13,29,5,15,25,,,,1.493,0.929,1.169*15

$GNGSA,A,3,172,,,,,,,,,,,,1.493,0.929,1.169*1A

$GPGSV,3,1,10,2,44,82,38,5,53,28,44,6,2,103,25,12,9,201,30*4B

$GPGSV,3,2,10,13,53,132,30,15,37,189,27,21,6,299,31,25,18,241,40*43

$GPGSV,3,3,10,29,54,309,48,30,1,75,13*76

$BDGSV,1,1,1,172,13,320,37*5A

$GNRMC,224251.000,A,3016.500285,N,08151.368471,W,0.000,16.761,200718,,E,A*12

$GNGGA,224251.000,3016.500285,N,08151.368471,W,1,10,0.929,10.011,M,0,M,,*42

$GNGLL,3016.500285,N,08151.368471,W,224251.000,A,A*5B

$GNGSA,A,3,12,6,21,2,13,29,5,15,25,,,,1.493,0.929,1.169*15

$GNGSA,A,3,172,,,,,,,,,,,,1.493,0.929,1.169*1A

$GPGSV,3,1,10,2,44,82,38,5,53,28,44,6,2,103,25,12,9,201,30*4B

$GPGSV,3,2,10,13,53,132,30,15,37,189,28,21,6,299,31,25,18,241,40*4C

$GPGSV,3,3,10,29,54,309,48,30,1,75,13*76

$BDGSV,1,1,1,172,13,320,37*5A

$GNRMC,224252.000,A,3016.500285,N,08151.368471,W,0.000,16.761,200718,,E,A*11

$GNGGA,224252.000,3016.500285,N,08151.368471,W,1,10,0.873,10.010,M,0,M,,*4E

$GNGLL,3016.500285,N,08151.368471,W,224252.000,A,A*58

$GNGSA,A,3,12,6,21,2,13,29,5,15,25,,,,1.458,0.873,1.167*12

$GNGSA,A,3,172,,,,,,,,,,,,1.458,0.873,1.167*1D

$GPGSV,3,1,10,2,44,82,38,5,53,28,43,6,2,103,24,12,9,201,30*4D

$GPGSV,3,2,10,13,53,132,29,15,37,189,29,21,6,299,32,25,18,241,40*46

$GPGSV,3,3,10,29,54,309,48,30,1,75,13*76

$BDGSV,1,1,1,172,13,320,37*5A

$GNRMC,224253.000,A,3016.500286,N,08151.368470,W,0.000,16.761,200718,,E,A*12

$GNGGA,224253.000,3016.500286,N,08151.368470,W,1,10,0.873,10.008,M,0,M,,*44

$GNGLL,3016.500286,N,08151.368470,W,224253.000,A,A*5B

$GNGSA,A,3,12,6,21,2,13,29,5,15,25,,,,1.458,0.873,1.167*12

$GNGSA,A,3,172,,,,,,,,,,,,1.458,0.873,1.167*1D

$GPGSV,3,1,10,2,44,82,38,5,53,28,43,6,2,103,23,12,9,201,31*4B

$GPGSV,3,2,10,13,53,132,28,15,37,189,31,21,6,299,32,25,18,241,40*4E

$GPGSV,3,3,10,29,54,309,48,30,1,75,12*77

$BDGSV,1,1,1,172,13,320,38*55

$GNRMC,224254.000,A,3016.500286,N,08151.368470,W,0.000,16.761,200718,,E,A*15

$GNGGA,224254.000,3016.500286,N,08151.368470,W,1,10,0.873,10.006,M,0,M,,*4D

$GNGLL,3016.500286,N,08151.368470,W,224254.000,A,A*5C

$GNGSA,A,3,12,6,21,2,13,29,5,15,25,,,,1.458,0.873,1.167*12

$GNGSA,A,3,172,,,,,,,,,,,,1.458,0.873,1.167*1D

$GPGSV,3,1,10,2,44,82,38,5,53,28,43,6,2,103,21,12,9,201,31*49

$GPGSV,3,2,10,13,53,132,27,15,37,189,32,21,6,299,32,25,18,241,40*42

$GPGSV,3,3,10,29,54,309,48,30,1,75,12*77

$BDGSV,1,1,1,172,13,320,38*55

$GNRMC,224255.000,A,3016.500287,N,08151.368470,W,0.000,16.761,200718,,E,A*15

$GNGGA,224255.000,3016.500287,N,08151.368470,W,1,10,0.873,10.004,M,0,M,,*4F

$GNGLL,3016.500287,N,08151.368470,W,224255.000,A,A*5C

$GNGSA,A,3,12,6,21,2,13,29,5,15,25,,,,1.458,0.873,1.167*12

Regarding the RS232 spec, control lines do not require -12VDC to assert. This is per the spec. I'm using the DCD pin on a DB9 connector that is soldered directly to a Dell Precision workstation motherboard. No funny USB UART stuff going on there. +3.3V is juuust above the minimum required voltage, but it's working well.

Here's the Wikipedia page...

https://en.wikipedia.org/wiki/RS-232#Voltage_levels

RS-232 logic and voltage levels
Data circuits	Control circuits	Voltage
0 (space)	Asserted	+3 to +15 V
1 (mark)	Deasserted	−15 to −3 V

Regarding this message:

gpsd:PROG: PPS:/dev/pps0 *Assert ignored missing last_fixtime

Interestingly, I'm actually seeing two of these (instead of the previous one) now that I've downgraded to the latest Jessie (instead of the latest Stretch) and recompiled.

address@hidden:~/gpsd $ uname -a

Linux raspberrypi 4.4.21-v7+ #911 SMP Thu Sep 15 14:22:38 BST 2016 armv7l GNU/Linux

address@hidden:~/gpsd $ ./gpsd -V

./gpsd: 3.18~dev (revision release-3.17-157-g5e95e79)

gpsd:PROG: KPPS:/dev/pps0 assert 1532128592.433176443, sequence: 30508, clear 0.000000000, sequence: 0 - using: assert

gpsd:PROG: KPPS:/dev/pps0 Assert cycle: 1000005, duration: 0 @ 1532128592.433176443

gpsd:PROG: PPS:/dev/pps0 Assert cycle: 1000005, duration: 0 @ 1532128592.433176443

gpsd:PROG: PPS:/dev/pps0 Assert ignored missing last_fixtime

gpsd:PROG: KPPS:/dev/pps0 assert 1532128592.433176443, sequence: 30508, clear 0.000000000, sequence: 0 - using: assert

gpsd:PROG: KPPS:/dev/pps0 Assert cycle: 1000005, duration: 0 @ 1532128592.433176443

gpsd:PROG: PPS:/dev/pps0 Assert cycle: 1000005, duration: 0 @ 1532128592.433176443

gpsd:PROG: PPS:/dev/pps0 Assert ignored missing last_fixtime

gpsd:PROG: GNRMC sentence timestamped 231634.00.

gpsd:PROG: GNRMC starts a reporting cycle.

gpsd:PROG: GNGGA sentence timestamped 231634.00.

gpsd:PROG: GNGLL sentence timestamped 231634.00.

gpsd:PROG: GNGLL ends a reporting cycle.

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= 2 az=100 el=35 (0.806707, -0.142244, 0.573576)

gpsd:INFO: PRN= 5 az= 40 el=41 (0.485118, 0.578141, 0.656059)

gpsd:INFO: PRN= 13 az=102 el=62 (0.459212, -0.097609, 0.882948)

gpsd:INFO: PRN= 15 az=188 el=54 (-0.081804, -0.582065, 0.809017)

gpsd:INFO: PRN= 20 az=259 el= 7 (-0.974310, -0.189387, 0.121869)

gpsd:INFO: PRN= 21 az=308 el=16 (-0.757485, 0.591812, 0.275637)

gpsd:INFO: PRN= 25 az=229 el= 9 (-0.745418, -0.647982, 0.156434)

gpsd:INFO: PRN= 29 az=283 el=64 (-0.427136, 0.098612, 0.898794)

gpsd:INFO: PRN=172 az=319 el=25 (-0.594591, 0.683999, 0.422618)

gpsd:INFO: Sats used (9):

How is the GPRMC/GNRMC message getting parsed?

Thanks,

Chris

On Fri, Jul 20, 2018 at 5:35 PM, Gary E. Miller <address@hidden> wrote:

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
> https://lists.gnu.org/archive/html/gpsd-users/2016-04/msg00085.html:

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

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

> 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?*

BIG RED FLAG. NO VALID TIME. GAME OVER.

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

http://aprs.gids.nl/nmea/

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

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

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