Re: [gpsd-users] gpsd WATCH_RAW

[Gary E. Miller]

Yo Roger!

On Mon, 9 Mar 2015 14:13:38 +0000
Roger Oberholtzer <address@hidden> wrote:

> > You'll get those.  All tyhat's required is that the sentence have a
> > known talker prefix.  $P qualifies - it's NMEA0183 srandard for
> > vendor sentences.
> 
> That sounds good. In fact, the exact string looks like this:
> 
>      $PASHR,204133.360,031.83,T,-00.27,-00.56,-00.94,0.152,0.080,0.598,1,0*06

If you could get us a complete sample, say one minute of data, we can
add it to our test case collection.

If you can provide documentation and maybe a decode we could possible add 
a driver for it.

> Both Applanix and OxTS GPS receivers are equipped with IMUs and
> provide this string. Others may as well.

I have a GPS on order from China that will have something similar.

> In my code that is going to be replaced with calls to libgps, I set
> the serial port driver to send data when a line is complete:
> 
>         pst.c_lflag = ICANON;                   // Allow special
> input chars pst.c_cc[VEOL] = '\n';                  // Set GPS EOL
> character (GPS uses \r\n)
> 
> I guess that gps_read will not be returning such data. I will get
> whatever characters have arrived.

It all depends on what you ask for, and whether we decode the new data 
yet.

> For simply recording this to a file this is ok. But I also parse the
> data to take relevant action (hence the nicety or getting complete
> lines). Perhaps it would be better to open two connection via libgps.

Nah,  we get it into sentences for you.

> One for the raw data I will simply put in a disk file for later use.
> And another to the shared memory segment that contains the 'current'
> lat/long values (which are what I need in this context).

The SHM interface is not stable, best to stick to the JSON if you can.

> If I receive raw data via gps_read(), might it be the case that these
> strings have already been parsed and the results in the shared memory
> segment?

Eventually, but same for the JSON stream.

> Or, as I suspect, are these two things asynchronous?

Nope.  gpsd is stingle threaded.

> If I
> open a connection to the shared memory segment, I do not want to poll
> it for changes.

Sadly polling is how iit works now.  Maybe a semaphore in the future.

> But I need to check for changes as close as possible
> to when the data arrives.

Which is the advantage of the JSON.

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