Re: [gpsd-dev] [PATCH] Fix on NMEA driver 2D mode

[José Miguel Gonçalves]

On 05-04-2012 15:43, Eric S. Raymond wrote:
> José Miguel Gonçalves<address@hidden>:
> > Hi Eric,
> >
> > On 21-03-2012 22:12, Eric S. Raymond wrote:
> > > José Miguel Gonçalves<address@hidden>:
> > > > While working with a Septentrio PolarRx2 receiver, I've noticed that
> > > > I never got 2D fixes with xgps, while the Septentrio proprietary
> > > > software told me that it had a fix. I've tracked down the bug to the
> > > > GGA processing in the NMEA driver.
> > > If you re-patch yours so the test (session->newdata.mode != MODE_2D)
> > > is replaced by (session->newdata.mode>   MODE_2D), do you still get fixes?
> > No!
> >
> > > I'd like to have a test logfile for this receiver.  Can you supply one?
> > Sure. I attach two NMEA log files for this device with a 2D fix. One
> > outputting GGA+GSA+GSV+VTG+ZDA+GST (nmea_2d.log) and the other
> > outputting all the NMEA messages that the receiver supports
> > (nmea_2d_full.log).
> > From the full log, I get these fixes with the current GPSD head
>
> "class":"TPV","tag":"RMC","device":"stdin","mode":2,"time":"2012-03-22T11:22:58.000Z","ept":0.005,"lat":38.737331333,"lon":-9.140637500,"track":0.0000,"speed":0.000}
> {"class":"TPV","tag":"RMC","device":"stdin","mode":2,"time":"2012-03-22T11:22:59.000Z","ept":0.005,"lat":38.737327500,"lon":-9.140636667,"track":0.0000,"speed":0.000}
> {"class":"TPV","tag":"RMC","device":"stdin","mode":2,"time":"2012-03-22T11:23:00.000Z","ept":0.005,"lat":38.737322500,"lon":-9.140635833,"track":339.2000,"speed":0.051}
> {"class":"TPV","tag":"RMC","device":"stdin","mode":2,"time":"2012-03-22T11:23:01.000Z","ept":0.005,"lat":38.737317833,"lon":-9.140634000,"track":0.0000,"speed":0.000}
>
> Is this the expected behavior? Does it fix your problem?

The problem happens when only partial NMEA messages (but enough to supply a PVT) 
are sent by the receiver, and it's only solved when you use the test 
(session->newdata.mode != MODE_2D).

Meanwhile, another problem that I've detected is that, when the receiver supplies 
a GBS message, gpsd never uses it because of the time stamp test. In that case I 
always see the log message "second in $GPGBS error estimates doesn't match". I had 
to remove the timestamp test in processGPGBS(), to be able to use the GBS info. I 
prefer to have accurate error information supplied by the receiver, even if with a 
1 second delay, that one that is extrapolated by gpsd using DOP values.

Regards,
José Gonçalves