gpsd-dev
[Top][All Lists]
Advanced

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

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


From: Eric S. Raymond
Subject: Re: [gpsd-dev] [PATCH] Fix on NMEA driver 2D mode
Date: Thu, 12 Apr 2012 11:59:43 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

José Miguel Gonçalves <address@hidden>:
> The problem does not occur with the full set of NMEA messages.
> Moreover, it does not happen if I add the GLL message to the set of
> messages that the device sends.

Good.
 
> A device that behaves like you describe is not really following the
> standard. I understand that you want to support the biggest set of
> receivers that you can, but I think that you should privilege the
> ones that behave correctly.

Sadly, attempting that would be a disaster. The NMEA standard is
proprietary and complex; additionally, while I've never seen it, I
have good reason to believe that it is vague about edge cases and
exceptional conditions.  Thus, "behave correctly" is not necessarily
well-defined even if one can see NMEA 0813 - and I think mamy GPS
implementors never have seen it.  Instead they emulate the behaviors they've
seen in other devices, along with the mutations that arose during 
previous folk transmission.

Under these circumstances, you basically need to code to cope with maximum 
perversity in what comes up the pipe.

What's your expected gain from reducing the sentence set?  You haven't
given me a good reason to support that yet at the cost of 
reduced bulletproofing, but perhaps there is one.

> >>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.
> >
> >That...sounds like the way the NMEA driver actually works. :-)
> >
> >You might want to take a closer look at the cycle-detection logic.
> 
> I don't fully understand the logic behind gpsd cycle detection, but
> the behaviour of the gpsd output is not the one that I would expect
> if it followed the logic that I described. Exemplifying with an
> extract of gpspipe_patch.log, I would expect that the output of
> gpspipe instead of this:

Ah, I think I understand your confusion. 

Timestamped sentences are aggregated into a composite report shipped
only on end of cycle, with values filled in as you describe.

But there are some un-timestamped sentences such as GSV groups which
are not treated as part of the regular cycle, with reports shipped
immediately.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

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