[Top][All Lists]

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

Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff68

From: Eric S. Raymond
Subject: Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c
Date: Wed, 6 Sep 2017 18:17:00 -0400
User-agent: Mutt/1.5.24 (2015-08-30)

Hal Murray <address@hidden>:
> I can't tell which one of us is in the wrong alternate universe.  From my 
> view, it looks like you are in a pig-headed mode and aren't paying attention 
> to what I'm trying to say.  But maybe I'm not saying it clearly.  Eric: Would 
> you please scan this thread and see how it looks from the outside.

Gary is correct in the general assertion that worst-case sentences like (in
the NMEA case) skyviews can overrun a one-second transmission window even
if your average case is OK.  I have *seen this happen*, though only at

Whether this is what is causing your actual problem I don't know. Apparently
you think it isn't.  I've been too busy preparing for two project releases 
to follow that argument closely.

> (And if the problems are caused by a worst case that is only occasional, 
> shouldn't gpsd be able to filter them out?  Even if gpsd sends occasional bad 
> samples, ntpd will filter them out.)

The mischief gets done at a level GPSD can't compensate for.  The problem with
trying to filter is that the 1PPS does not itself come with a timestamp -
I can't think og any way to tell that's associated with the wrong in-band
                <a href="";>Eric S. Raymond</a>

Please consider contributing to my Patreon page at
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.

reply via email to

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