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

[Michael Lum]

Hi Gary,

our use case is a slow geo-fence as an adjunct to the main applications so we 
wanted to
keep CPU usage low and keep IP traffic off of the 'lo' interface.

We have continuous packet capture happening on the 'lo' interface and don't 
want the
gpsd traffic there.

My guess about the cause, something related to the way the flags are set:

The flags provided to the client (I'm using C++) across the socket interface is 
using
the JSON unpack routine that is setting the flags based on the values (not NaN) 
from
the JSON message.

(I have changed to do this sort of test as you suggested.  I check the values 
using
isfinite() and this seems to work so far.)  I'm only looking at fix.time, 
fix.mode and
fix.latitude, fix.longitude.

The flags provided to the client across shared memory are, I believe, directly 
determined
in gpsd.

Messages are arriving so frequently from the Ublox receiver that the flags are 
just
getting written over too quickly in shared memory?


=======================================================
FYI, Ublox NEO-7

Jun 14 17:38:08 nib-default kernel: usb 1-3.2: USB disconnect, device number 38
Jun 14 17:38:09 nib-default kernel: usb 1-3.2: new full-speed USB device number 
39 using xhci_hcd
Jun 14 17:38:10 nib-default kernel: usb 1-3.2: New USB device found, 
idVendor=1546, idProduct=01a7
Jun 14 17:38:10 nib-default kernel: usb 1-3.2: New USB device strings: Mfr=1, 
Product=2, SerialNumber=0
Jun 14 17:38:10 nib-default kernel: usb 1-3.2: Product: u-blox 7 - GPS/GNSS 
Receiver
Jun 14 17:38:10 nib-default kernel: usb 1-3.2: Manufacturer: u-blox AG - 
www.u-blox.com
Jun 14 17:38:10 nib-default kernel: cdc_acm 1-3.2:1.0: ttyACM0: USB ACM device 

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

Yo Michael!

On Wed, 13 Jun 2018 14:36:22 -0700
Michael Lum <address@hidden> wrote:

> I build the command like this:
> 
> scons test_gpsmm

Thanks, that works.  The usage message does not show the options you are giving 
it, but the code does 'support' it.

 # ./test_gpsmm -h
usage: ./test_gpsmm [-l n]

Running this

# ./test_gpsmm "shared memory"

Does indeed fail for me the way it fails for you.

Any idea why it fails?  I don't see it.

> Yes, I'm coming to the conclusion that I will have to check 
> 'freshness' based on the information you gave me instead of on the 
> flags.

Or, better yet, convert to the socket method instead of shared memory?

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