Re: [gpsd-users] Shared memory 'flags' set?

[Gary E. Miller]

Yo Michael!

On Tue, 12 Jun 2018 16:41:59 -0700
Michael Lum <address@hidden> wrote:

> the problem is related to the delay in gps_waiting(). 
> 
> My original code used 500,000 as the delay (for the socket interface)
> and that worked fine.

IMHO, that is way too long.  Depending on the GPS you are using, the
data may come from gpsd in unexpected chunks.  In some case you may
get mutiple message of the same type, but with different data, in
one GPS cycle.

> I tried test_gpsmm and it worked.

Great.

> Note:  the shared memory interface section of the Client HOWTO says
> gps_waiting() is not available for the interface.

Citation?  I just read about gps_waiting() in libgps.3.  It just says there
acn be a race condition.

> I'm not sure how I can reliably determine that lat/long are valid.

Depends a lot on how you are reading  the data.

Three bacic things to always check.  Check that lat/lon are not NaN or
INF.  Check that you have a 2D or 3D fix.  Check that the time stamp
in the PVT message is new.

> I can look at the TIME data to know it (TIME) has been updated but
> does that mean the lat/long are "fresh"?

Fairly unrelated and depends a lot on your GPS and how it is configured.
Many GPS output wild TIME before they have a fix.  You want to check
the timestamp in the TPV message for freshness.

> Note2: when I tried to build with ONLY the shared memory export (no
> socket or D-bus) there were warnings during the make:

Interesting, but no failure mode for just unused variable warings..
Somethings we need to improve.

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

pgpJ71jLMaa9S.pgp
Description: OpenPGP digital signature