Re: [gpsd-users] gpsd WATCH_RAW

[Roger Oberholtzer]

> 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

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

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.

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

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? Or, as I 
suspect, are these two things asynchronous? If I open a connection to the 
shared memory segment, I do not want to poll it for changes. But I need to 
check for changes as close as possible to when the data arrives.


Roger Oberholtzer

Ramböll RST

Office: +46 (0)10-615 6020
Mobile: +46 (0)70-815 1696
address@hidden
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se