[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.
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, (continued)
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Gary E. Miller, 2017/09/05
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Eric S. Raymond, 2017/09/05
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Gary E. Miller, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Hal Murray, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Gary E. Miller, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Hal Murray, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Gary E. Miller, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Hal Murray, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Gary E. Miller, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c,
Hal Murray <=
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Eric S. Raymond, 2017/09/06
- Re: [gpsd-dev] ✘reset "Support UBX NAV-PVT" commit 22a020ec1c2bc85eff681ecacc6d2bb79fdddc9c, Gary E. Miller, 2017/09/06