gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘ gpxlogger


From: Gary E. Miller
Subject: Re: ✘ gpxlogger
Date: Sat, 14 Aug 2021 16:03:10 -0700

Yo Fred!

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?

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

Attachment: pgpEoFNMXqNFK.pgp
Description: OpenPGP digital signature


reply via email to

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