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

[José Miguel Gonçalves]

On 05-04-2012 18:33, Eric S. Raymond wrote:
> José Miguel Gonçalves<address@hidden>:
> > 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).
> Under what circumstances can this happen? It doesn't seem to occur
> with the full log.  Does it happen only when the sentence inventory
> emitted is reduced?

I've seen it only with the partial set of messages whose log I've sent 
previously.
I'm not sure if it happens also with the full set (I will test it when I have 
access to the receiver again).

> I'm reluctant to change that test because doing that would break
> functionality on other devices.  If that means we have to attach a
> note saying you can't disable sentences and still expect the PolaR2x
> to work with GPSD, then that's how it has to be.

I don't see how can this break other devices. If you receive a GGA message with 
the GPS quality indicator field bigger than 0, it's because you have a valid fix. 
So, I think it's pretty safe to assume that, if the receiver sends a void altitude 
field when we have a valid fix, we have a 2D fix.

> > 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.
> I agree, the reported error estimates are preferable.  This sounds like
> the device may be hitting some kind of strange edge case in the NMEA
> driver's cycle-detection logic.  Again, the fix here may well be not to
> try to reduce the set of sentences omitted.

I don't agree. In my opinion (that only recently look at the gpsd's sources) the 
problem is on the gpsd's sync philosophy with the NMEA messages and some quirks 
that are needed to assume values for some fields that are not explicitly set by 
some messages.
I think a better approach (that I've used in the past for software that I 
implemented for my company) is to extract only the values explicitly set by the 
NMEA messages and detect the time interval between NMEA batch of messages, using 
that interval to assemble and compute (if possible) values that were not 
explicitly set in the messages that the receiver provided. This approach can have 
problems with slower baudrate devices that dump a lot of messages, causing the 
time interval not detectable, but I think nowadays this is really not a problem, 
with all devices capable of 9600bps or higher and using USB instead of RS-232 
interfaces.

Regards,
José Gonçalves