gpsd-dev
[Top][All Lists]
Advanced

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

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


From: Hal Murray
Subject: Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c
Date: Wed, 06 Sep 2017 14:56:40 -0700

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

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.

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.

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.

>> 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?

(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 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.  Are you subtracting off the packet length to 
get the start-time of a sentence?

If that is a show stopper, where is it documented?  Is there a list of 
devices that need fudging at ntpd because of that quirk?

---------

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

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

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
Are you processing the fraction?  What does that mean?  Are you rounding or 
truncating?


-- 
These are my opinions.  I hate spam.






reply via email to

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