gpsd-users
[Top][All Lists]
Advanced

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

Re: [gpsd-users] gpsd and shared memory


From: Gary E. Miller
Subject: Re: [gpsd-users] gpsd and shared memory
Date: Thu, 1 Oct 2015 11:53:30 -0700

Yo Roger!

On Thu, 1 Oct 2015 05:38:16 +0000
Roger Oberholtzer <address@hidden> wrote:

> Our goal is to have
> this action be as close as possible to the location as it can be.

Given the practical limitations of GPS signals, that would be a CEP(95)
of around 7 meters.
 
> Would I be wasting my time to use the gpsd shared memory segment each
> meter to decide where the vehicle is? I have these concerns:

You'll get exactly the same data, at very close to the same latency,
as just connection on 2947.

>   -  When parsing a 10 Hz NMEA stream (i.e., GGA records at 10 Hz),
> what kind of delay might there be from when the NMEA record became
> available on the serial port and when information about location is
> updated in shared memory?

The main component of the delay is the speed of the serial port
itself.  So the main thing to do is get that as fast as possible.
Beyond that interrupt latency in the CPU is the next biggest factor, so
multi-core helps a lot.  Once gpsd has the data its time to process
is tiny, on the order of micro Seconds on any 64 bit cpu.

>  - Even though I could read the shared memory segment each meter, I
> guess I would need to know the UTC time that the location in memory
> applies to. Are the locations and UTC time so connected in memory?

Yup, all data from the GPS is time stamped by the GPS and gpsd maintains
that association.  It ainted called PVT data for nothin'.

> Our current NMEA solution
> considers the last GGA record to be 'now'.

Depending on the serial port speed, and the GPS itself, that could be
off by 50 mSec to over 1 Sec.  Get a GPS with a PPS output and compare the
it to your calculated time.


> I often read that the JSON stream is the preferred one. In my
> application, using the JSON stream would not really get me much over
> the existing NMEA method that is working.

Correct, that data is the same, it is just a lot easier to parse a JSON
stream than a binary one.  If you use the libgps the that is all hidden from
you anyway.

> I have been interested in
> the shared memory approach because the application would not need to
> parse the GPS data (NMEA or JSON).

Yeah, you just need to track the ABI, which has not been stable, and
decode binary structures defined by C code.  Or use libgps and not worry
about it.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1(541)382-8588

Attachment: pgpOlVv1S699k.pgp
Description: OpenPGP digital signature


reply via email to

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