gpspipe_log.txtDescription: Text document
|
| From: | Chris Smith |
| Subject: | Re: [gpsd-users] 1PPS not working with RPi 3 B+ and Stretch |
| Date: | Fri, 20 Jul 2018 21:32:29 -0400 |
Yo Chris!
On Fri, 20 Jul 2018 19:42:08 -0400
Chris Smith <address@hidden> wrote:
> I thought you said my issue was that my GPS wasn't getting good time?
Sort of. Your GPS is not sending good time to gpsd. The difference
is slight, but essential.
> 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.
Good. But just as important it that gpsd has been running, uninterrupted
for the same amount of time. It does not matter if the GPS has the
time if it has not sent it to gpsd yet.
> I will agree that the issue is likely on my Pi,
No. Your earlieer emails showed the identical issue on your CentOS.
> but given this is a
> new module we might have multiple issues combining together...
I doubt it.
> *" 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
> impossibleto know the month, day and year."*
> $GPRMC,220516,A,5133.82,N,00042.24,W,173.8,231.8,130694, 004.2,W*70
> 1 220516 Time Stamp
Time of day, not date.
> $--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a* hh
> 1) Time (UTC)
Time of day, not date.
> 9) Date, ddmmyy
But no century!
> 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).
Nope. You still have no century. This is why GPZDA is preferred.
> (78) $GNRMC,*222933.000*,A,3016.500098,N,08151.368588,W,0.000, 16.761,
> *200718*,,E,A*12\x0d\x0a
Note useful, corrupted by email. So I'll ask yet again for the
output of: "gpspipe -n 120".
> Both specs show that the end of the GMRMC message should end "a*hh",
> a = direction and "*hh" = checksum.
There are WAY more than two versions of NMEA. The "A" in the last
field is the "FAA mode indicator" from NMEA 2.3 and later.
If you look in driver_nmae0183.c you can see that feild 12 is optional
for gpsd.
> $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?
You misunderstand, the number of fields in NMEA is variable. The
checksum is the thing after the asterisk. If you have a checksum
problem then the gpsd debug logs would show you that.
> Per the spec,
I seriously doubt you have any version of the real spec. What you
have is various random interpretations of the spec, unattached to NMEA
version numbers.
? I'd expect this to look like "E*12" not "E,A*12". I
> think this might be a culprit.
Nope.
> Also, I see that you've asked for cgps output twice regarding time...
Yes. For good reasons.
> x Time: * 2018-07-20T22:37:25.000Z* xx PRN Elev Azim SNR Used 9x
That looks good. So what did "ntpshmmon" look like when you have that
good time? Notice I've also asked for ntpshmmon before.
> Everything looks good there, yes? (minus the almost -1 sec offset)
Yes, and the -1 is also normal.
> Regarding gpspipe output...
Corrupted in the email. To send it uncorrupted it needs to be an attachment.
> $GNRMC,224250.000,A,3016.500284,N,08151.368472,W,0.000, 16.761,200718,,E,A*11
^^^^^^
Good month, day and partial year. Add the GPZDA and you'll likely work.
> Regarding the RS232 spec, control lines do not require -12VDC to
> assert.
Correct. Nor have I asserted such.
> This is per the spec.
You actually have a copy of the real spec? Or somethingyou found
on the internet of someone's interpretation of the spec?
> No funny USB UART stuff going on there. +3.3V is juuust
> above the minimum required voltage, but it's working well.
Yes, some motherboards work. Some will not. And it is clearly not
providing the -3v for a zero required by the spec.
> Here's the Wikipedia page...
> https://en.wikipedia.org/wiki/RS-232#Voltage_levels
Yeah, they almost got it right. Remember Wikipedia is NOT
EVER controlling. You need to read the real spec.
> 1 (mark) Deasserted −15 to −3 V
Yup, -3V. I seriously doubt your GPS output -3V. have you measured it?
But, as previously agreed, off topic as your PPS is working. Not right,
but not your problem.
> 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.
The number you get will be somewhat random. Depends on the relative
phase of the sentences on startup. Once agani, different gpsd should not
matter, that code has not changed in a while.
> address@hidden:~/gpsd $ ./gpsd -V
> ./gpsd: 3.18~dev (revision release-3.17-157-g5e95e79)
No point repeating the same thing. Still broken. Still unchanged.
And still not long enough to be useful. Syncing to PPS takes a long time.
Unless you have let gpsd run for 30 minutes it proves only that your
startup is slow.
> How is the GPRMC/GNRMC message getting parsed?
driver_nmea0183.c
But, your problem still looks like lack of $GPZDA, or maybe letting
gpsd run long enough to settle.
So, start gpsd, wait 30 minutes, check cgps gives you good time, then
check "ntpshmmon". Not "ntpshmmon -v", just "ntpshmmon".
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
gpspipe_log.txt
Description: Text document
| [Prev in Thread] | Current Thread | [Next in Thread] |