On Sat, 14 Aug 2021 15:49:14 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:
On Thu, 12 Aug 2021, Gary E. Miller wrote:
Another fix to gpxlogger. I hope the last. Please test.
The problem was the lack of a timeout when reading gpsd from DBus.
I just pushed a fix for platforms lacking clock_gettime(). Aside
from the needed include, the current fallback only implements
CLOCK_REALTIME, which is the only type that's been used so far, and
it's generally fine for timeouts. For really accurate intervals, one
should use CLOCK_MONOTONIC_RAW, not CLOCK_MONOTONIC, since the latter
only omits the step adjustments, and still includes the same
intentional rate errors for slewing as CLOCK_REALTIME, typically on
the order of 500ppm. CLOCK_MONOTONIC is pretty much never what you
really want.
Thanks!
I just notice the CLOCK_MONOTONIC is not good for timeouts. From the
man page:
"This clock does not count time that the system is suspended."
With the timeout it indeed now only hangs for five seconds instead of
forever waiting for dbus, though ^C still has no effect as expected.
I'm not sure what you expected? ^C now working for me, but maybe we
have different tests?
In the process, I did some testing with and without dbus running, and
found that gpxlogger is never able to find the local gpsd without
dbus, even in the perfectly normal case where gpsd is running with a
receiver providing fixes.
By default, gpslogger only tries DBus. To use TCP, you have to start
with:
gpxlogger localhost
or specify the export method:
gpxlogger -e shm
gpxlogger -e sockets
Fallback was never part of the gps_mainloop() code.
Meanwhile, cgps has no trouble. I suspect
that the dbus failure is failing to fall back to the non-dbus method
of connecting.
I make no assumptions. No other gpsd client has ever used gps_mainloop()
and that function is way more complicated than I expected.
No other client uses gps_mainloop() so many bugs in there...
Indeed. It still nees to interact better with signals.
What exactly is failing for you?