For anyone who runs across this in the future, I was able to solve this. It required quite a few fixes, primarily verifying that all received sentences were reporting good fixes.
this is obvious in retrospect, but will not be specifically indicated in any error message.
First off, thanks to @Gary E. Miller for answering all my questions! You've been a great help. Couldn't have tracked down the issue without you!
@List
For anyone else who's struggling to get PPS time synchronization working, here are the lessons I learned:
- Lesson 1: Having a "valid" PPS, as reported by 'ppscheck' is not sufficient for GPSD to report the pps signal.
- Lesson 2: All NMEA sentences received need to be valid, and you probably need some minimum set, consisting of:
- 1. "valid" PPS
- 2. valid NMEA GPGSA: Field 2/Mode = 3. Especially if field 1 reports "Manual" Mode, this may not be sufficient.
- 3. GPRMC: Field 2/Warning Field == "A" ("A" == OK, "V" == warning)
- 4. GPGGA: Fields 2-5 are valid latitude, longitude values.
- 5. GPGGA: Field 6: Fix Quality = 4 (real time kinematic)
(Presumably there is a subset of this, which would also enable time sync output.)
- GPSD will not *Tell* you that these fixes are bad, NOR that it's why PPS won't output. not even in debug level 6
- Lesson 3: GPSD can report a PPS signal to "gpsmon" without being in root.
- Lesson 4: gpsd will fail back to ioctl mechanism even if it's run as root and has access to KPPS. Even if your KPPS setup is faulty.
- Lesson 5: The PPS errors "missing last_fixtime" do not prevent a pps fix. (visible at debug level 5 and above)
gpsd:PROG: PPS:/dev/ttyS6 Clear ignored missing last_fixtime
...
gpsd:PROG: PPS:/dev/ttyS6 Assert ignored missing last_fixtime
Other Context, for the curious:
====
The gps receiver and computer I'm trying to set up are mounted on a vehicle, and I was debugging while parked.
Unfortunately for me, the GPS receiver (and IMU) only output valid sentences while it's calibrated, which effectively means: "while it's driving".
For instance, our receiver can see 6 satellites, report 1m DOP, and still not have a "valid" fix -- because it's waiting until the IMU & accelerometers are valid before reporting a valid fix.
Cheers,
-DMW
On Fri, Jun 5, 2020 at 1:27 PM Gary E. Miller <gem@rellim.com> wrote:
Yo Dan!
On Fri, 5 Jun 2020 09:34:19 -0400
Dan Williams <dwilliams@nextdroid.com> wrote:
> I think I've diagnosed what the problems are, but not the fix.
When you understand the problem, the fix is easy.
> - User-space (plain) pps is not working, (reasons not clear)
They are clear: permissions. Unsupported mode. And user error, see
below.
> - root-space (kernel) ppps is not working, due to something on our
> side. Details follow.
They are clear: permissions. Unsupported mode. And user error, see
below.
> I'll just note that if we find shortcomings in the OxTS
> implementation, our company is a paying customer, and we could apply
> pressure behind relevant bug reports.
They need to start over. The documented part of the binary protocol
is junk. The undocumented parts are many.
> GPSD is also well-known, and could similarly apply pressure, if
> desired.
Oh, I wish.
> > Your gpspipe.log was not long enough to show any GSA.
> Besides this one?
3 sats in view? Ugh. No alarm bells yet?
> I've also attached a longer, 3-second one, if you prefer.
Not very useful when it tells you it is invalid:
$GPRMC,212009.00,V,4220.138940,N,07107.659525,W,0.225,191.959,040620,,,D*55
^^^
V there means "Invalid". Navigating with no fix is ungood. Time
keeping with no fix is also ungood.
> > That's just what it's _*configured*_ to. It has a whole lot of
> > sentences,
> but I just configured it to what I guessed was a minumum set.
> If we need more sentences, then just me know, and I'll configure it.
The good stuff is in the binary. The binary ip very primitive and error
prone. Something that escaped from the '90s. The control messages
undocumented.
About all to do better with is to add $PTCF, if that data is useful.
I'd need to add a decoder for it.
> Right well "IFF you system supports it" is the whole trick, isn't it?
Yup, KPPS is not supported:
$ ./gpsd -bnN -D6 /dev/ttyS6 |& fgrep PPS
gpsd:PROG: PPS:/dev/ttyS6 chrony socket /tmp/chrony.ttyS6.sock doesn't exist
gpsd:PROG: KPPS:/dev/ttyS6 checking /sys/devices/virtual/pps/pps0/path,
gpsd:PROG: KPPS:/dev/ttyS6 checking /sys/devices/virtual/pps/pps1/path, /dev/ttyS6
gpsd:INFO: KPPS:/dev/ttyS6 running as 1001/1001, cannot open /dev/pps1: unknown error
gpsd:WARN: KPPS:/dev/ttyS6 kernel PPS unavailable, PPS accuracy will suffer
What perms are on your /dev/ppsX? Usually root only, and you are not
running root, which is unsupported mode.
> As far as checking it -- the howto mentions "ppscheck" (see second
> paragraph of
> https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_enabling_pps)
> My system passes this, and shows "TIOCM_CD" signals.
And gpsd is seeing that:
gpsd:PROG: TPPS:/dev/ttyS6 ioctl(TIOCMIWAIT) succeeded, time: 1591307909.371366779, state: 0
gpsd:PROG: TPPS:/dev/ttyS6 Clear, cycle: 1591307909371366, duration: 1591307909371366 @ 1591307909.371366779
But since the NMEA says the fix is invalid, gpsd will not use it:
gpsd:PROG: PPS:/dev/ttyS6 Assert ignored missing last_fixtime
Which is correct behavior, because you started gpsd wrong.
> According to the comments at
> https://gitlab.com/gpsd/gpsd/-/blob/master/ppsthread.c#L9, user-space
> PPS and KPPS are the two methods. ppscheck / TIOCM_CD uses the
> first method, "user-space PPS". This is mentioned in the build
> output, but not in the -d5 output, below.
Look again in the debug log. Or above where I pasted the relevant part.
> So This looks like where the problem is -- running gpsd in user-space
> with -D6 shows this block every second:
Ugh, did you miss the aprt about not running gpsd in user space?
> Question 2: Does gpsd still support user space PPS, like the
> documentation seems to say?
You misunderstand what "user spaee" means. It measn running as root, but
not in the kernel. Not in kernel == user space.
> Question 3: Should I send a patch/PR to add more detail to the doc
> about ppscheck and ppstest. I can supply one if desired.
Patches and/or MRs always welcome. Way down on my TODO list is to
improve the code.
> > That is the intended behavior?
> > Some parts of gpsd seem to defy expections, so intention hard to
> > prove.
>
> I'm not asking to read anyone's mind, I was just trying to distinguish
> between "working as intended" or "bug"
How about not working as documented? gpsd needs root for timekeeping,
except in special cases that do not apply to you.
> > Whoops! You forgot to run as root. This is documented and
> > required to do PPS and SHM things. Big show stopping mistake.
> >
>
> The documentation I'm reading (that same how-to) implies that gpsd
> may be run as a normal user. (as discussed above)
Yes, did you read it? That pretty much says what is happening to you.
> > "1. Devices passed on the command line will be unable to use KPPS
See?
> > and
> will fall back to the same plain PPS that all hotplug devices must
> use, increasing the associated error from ~1 uSec to about ~5 uSec."
Which it did, properly. Except you had no fix. So gpsd properly
rejected the PPS time. Did you read the part about verifying you have a
good fix before proceeding to look at PPS?
> +/- 5 usec would be acceptable, if it worked.
It does, when you follow the directions. Note there are more pitfalls
to non-root that you will eventually discover. So run as root.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin