Re: [gpsd-dev] refclock 28 gone wacky on me

[Gary E. Miller]

Yo Hal!

On Sun, 19 Jun 2016 17:24:56 -0700
Hal Murray <address@hidden> wrote:

> address@hidden said:
> > Yes, that is expected.  You need to tetll the Skytrazzq to force
> > the top of the second, and save to flash.   
> 
> What does that mean?

The Skytraq GPS, and some others, have two modes they can report
the GPS mode.

The first way, the way we expect, is the GPS computes a new PVT
solution at the top of every second, and then sends a message
that that new fix.

So a fix report would look like this:

{"class":"TPV","device":"/dev/ttyS0","mode":3,"time":"2016-06-20T02:14:34.000Z","ept":0.005,"lat":44.068348315,"lon":-121.313259926,"alt":1176.971,"epx":15.315,"epy":18.206,"epv":43.081,"track":121.0306,"speed":1.582,"climb":0.303,"eps":36.41,"epc":86.16}

Notice the fractional seconds of the fix is .000

The second way is for the GPS to report the fix when it is most convenient
for the GPS cpu to report it.  The GPS will emit the fix with fractional
seconds to note the exact time the fix was valid.

{"class":"TPV","device":"/dev/ttyS0","mode":3,"time":"2016-06-20T02:14:34.940Z","ept":0.005,"lat":44.068348315,"lon":-121.313259926,"alt":1176.971,"epx":15.315,"epy":18.206,"epv":43.081,"track":121.0306,"speed":1.582,"climb":0.303,"eps":36.41,"epc":86.16}

Noteice the fix time has the fractional seconds of .940

The problem comes in that gpsd never expected the PVT solution to 
come that late in the second.  The full sentence may actually be decoded
after the start of the next second, and after the PPS for the next
second is received.

There is likely a not too bad solution, but it is not currently implmented
in the gpsd code.


> address@hidden said:
> > Did that which is why I didn't understand the delivery coming at
> > near  the end of the second.  It appears thought that the firmware
> > *slowly*  brings the delivery back to where it should be.   
> 
> I've lost track of the details of this discussion.

It happesn, too many similar discussions at the same time.  Which is
why I encourage people to recap all the details in each message.

> Many GPS chips seem to have a 100 ms timer that drifts slowly so the
> offset within the second when the NMEA strings come out will slowly
> drift then jump back and start over.

I doubt it is not an intentional timer.  It seems to correlate with the
number of sats in the solution.  The more sats, the more math to do
before the solution is fully computed.

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

pgpXEBSfpSOQP.pgp
Description: OpenPGP digital signature