[Top][All Lists]

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

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

From: Michael Lum
Subject: Re: [gpsd-users] Shared memory 'flags' set?
Date: Wed, 13 Jun 2018 10:49:57 -0700

Hi Gary,

an update on my testing:

sorry test_gpsmm doesn't appear to work (I had local changes in gpsd.c that 
allowed shm_update() only if LATLON_SET was present).

I changed test_gpsmm to 10,000 but I still don't see LATLON (for shared memory).
I've attached "script" output where I ran the following:

./test_gpsmm "shared memory"

The output is very different.

Thanks for the information on checking for 'freshness'.

My comment about gps_waiting() not being available for shared memory came from 
paragraph 3 of this:


by default test_gpsmm is using 5,000,000 (!) for gps_waiting()

-----Original Message-----
From: gpsd-users [mailto:address@hidden On Behalf Of Gary E. Miller
Sent: June-12-18 5:41 PM
To: address@hidden
Subject: Re: [gpsd-users] Shared memory 'flags' set?

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.


> 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.

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

Attachment: typescript.gz
Description: typescript.gz

reply via email to

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