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

[Gary E. Miller]

Yo Hal!

On Wed, 06 Sep 2017 14:56:40 -0700
Hal Murray <address@hidden> wrote:

> >> I did add it up.  It does fit.  
> 
> >Then we are using math from alternat universes.  
> 
> >> Let me try again.  There are 5 types of sentences.  Each second
> >> has 1 each except for GPGSV which has 3.  So there are 7 sentences
> >> each second.  Back of envelope.  7 sentences times 100 bytes per
> >> sentence times 10 bits per byte. That 7000 bits, well below 9600.
> >> (The 100 bytes/sentence is way high.)  
> 
> > You are fogetting many terms.  The delay from PPS to the first
> > sentence, the delay between each sentence, the length variation in
> > sentences, the USB queueing time.  
> 
> > But even 7,000 is WAY too close for 9.600 to actually fit, given the
> > sentence length variations, etc.  I would never want to run
> > closer then 2x.  
> 
> > Believe your data, your data is telling you it does not work.  
> 
> 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.

Pig headed is not trying the suggested work around.  Theory is great,
experiments and hard data are better.

> My 7000 was a conservative back of the envelope.  All the sentences
> are well under 100 bytes.  The scope shows about a 1/2 second of idle
> time.  I said that in a previous message.

Yup, so I'll not repeat my reply to your repeated statement.

> The last sentence in the clump is GPVTG.  It consistently arrives
> about the middle of the second.  xx.668 is the latest I see in quick
> scan of 27 samples (one screen).  Earliest is 533.  I'll make a
> histogram or whatever if you think that will help.

Can't hurt, but if as we discussed last pass, your NMEA is coming
in early, then that is the problem.

> On a different device, I have seen at least one case of "doesn't fit"
> where the 3xGPGSV were sent every 5 seconds and that pushed some
> stuff over into the next second.  This is not that case.  This time,
> they are being sent every second and it all fits.

Not the case, so why bring it up?  I'll just ignore it sice you say
it does not apply.

> >> And as I said already, your 'typical' is OK, It is the occasioanl
> >> worst case that causes your failure.  Stop worrying about
> >> typical.  
> 
> I haven't seen any interesting worst cases.  What should I be looking
> for? Every second has the same pattern.  The length variations are
> only a few bytes.  Will it help if I make histograms of arrival times?

repeat of question above, my answers are still the same, as above.

> (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.)

Hindsight is 20/20, we only know the second was wrong when we get
the second PPS seemingly in the same second.  I'm willing to try any
solution, but if the problem is the NMEA providing the time too early
then I see no solution.

> >> The serial stuff starts about the same time as the PPS.  Sometimes
> >> it's a few ms before the PPS.  Earliest I've seen is 7 ms before
> >> PPS.  
> 
> > If it is before the PPS then that is a real problem.  A show stopper
> > problem.  The PPS MUST be at the top of the second.  The NMEA MUST
> > NOT start before the top of the second.  
> 
> Sometimes, the burst begins before the PPS.  But only a few ms, much
> much less than the packet length.

Your log does no support this conclusion.

> Are you subtracting off the packet
> length to get the start-time of a sentence?

If your data is correct, not relevant.  If, as you say, the end of the
packet is received after the PPS is seen then if can not have affected
the determination of the current second.


> If that is a show stopper, where is it documented?

In these emails.  Since it has never been seen before, this is the
only documentation.  Assuming it is what you are really seeing.  It
would explain your logs and your end effect.


> Is there a list
> of devices that need fudging at ntpd because of that quirk?

Nope, never been seen before, this is a firat.

> One possibility is that the device is just broken and/or sending
> something obscure that is confusing gpsd.

And one way to test that is to change your speed, which I seem to
have to keep asking for...

> Which PPS does the time in GPRMC refer to, previous or next?

Until ntpd learns time travel, any NMEA can only affect the next PPS.

> I'm seeing things like:
> 58002 18366.492 72
> $GPRMC,050605.830,A,3726.0854,N,12212.2656,W,000.0,117.2,060917,,,A*71
> 
> That says the GPRMC sentence with time 050605.830 arrived at
> 18366.492 seconds this day.
> 050605 = > 18365

And with no data on your ntpd setup, annd system clock, not useful
data.  The log time stamps only useful when your local clock is
very stable by ntpd.

> Are you processing the fraction?

Me?  No, I do not have your hardware, and I can't calculate that fast,
even
with fingers and toes.

Nor do I see any way, either way, that could effect your issue.

>  What does that mean?  Are you
> rounding or truncating?

Mean?  You expect meaning to life?  Since PPS are on the top of the
second, not relevant to gpsd.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpsPOnX1AIIU.pgp
Description: OpenPGP digital signature