gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] ✘$GPGST busted time


From: Eric S. Raymond
Subject: Re: [gpsd-dev] ✘$GPGST busted time
Date: Tue, 29 Mar 2016 14:08:41 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

Gary E. Miller <address@hidden>:
> > Bug fixed.
> 
> Sorry, I can't agree.  

I could actually see in the regression tesrs where my fix prevented
spurious output. Appears we now have a different bug.

> The TPV has the right time, but not the GST.  They should be the same.

Yes, they should.

OK, this is probably a bug in the NMEA0183 driver.  And you should
troubleshoot it, because right now nobody understands that code but
me and that's a problem.

It *might* be as simple as changing this line in processGST()

    return GST_SET | ONLINE_SET;

to 

    return GST_SET | TIME_SET | ONLINE_SET;

In case it isn't, I'll explain what's going on.

NMEA0183 sentences are emitted in bursts, each burst corresponding to a sample
processed near top of second.  When you recognize an NMEA device you don't know
much of anything about the sentence mix or the order the sentences will be
emitted in; you have to get that by watching a full cycle.

This matters because only some sentences carry a full timestamp.

/**************************************************************************
 *
 * Scary timestamp fudging begins here
 *
 * Four sentences, GGA and GLL and RMC and ZDA, contain timestamps.
 * GGA/GLL/RMC timestamps look like hhmmss.ss, with the trailing .ss
 * part optional.  RMC has a date field, in the format ddmmyy.  ZDA
 * has separate fields for day/month/year, with a 4-digit year.  This
 * means that for RMC we must supply a century and for GGA and GLL we
 * must supply a century, year, and day.  We get the missing data from
 * a previous RMC or ZDA; century in RMC is supplied from the daemon's
 * context (initialized at startup time) if there has been no previous
 * ZDA.
 *
 **************************************************************************/

If you're lucky, the chip emits ZDA containing a full timestamp.  When it
does, ZDA is the start sentence of the burst and you've got your timestamp
for the rest of the cycle (including any GST thar might be omitted).

You usually won't be lucky.  Most receivers don't emit ZDA, so you have to
latch yymmdd from RMC, possibly later in the cycle.  Other sentences, like GST,
have partial timestamps (hhmmss) or none at all.  For those you have to merge
in the latched yymmdd.

Debugging problems in this code is not very difficult once you've
spotted and can reproduce them, you just run gpsfake cranking up the
debug level until you can see what's going wrong.  But anticipating
all the edge cases is very difficult.  I don't expect this to be the
last we trip over.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

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