|
From: | Anthony Stirk |
Subject: | Re: [gpsd-users] SemPiTernal - Bounding PPS uncertainty |
Date: | Sat, 23 Apr 2016 07:33:03 +0100 |
Uputronics board uses the Ublox default (you can actually change it) but leading (I thought this was "industry standard") and the width is about 200mS postive rising etc.Cheers,
AnthonyOn Fri, Apr 22, 2016 at 6:26 AM, Eric S. Raymond <address@hidden> wrote:By the IRC equivalent of repeatedly beating Gary with a rubber hose, I
finally extracted an explanation of certain cryptic remarks he's been
uttering about the pps-gpio driver being buggy. Here it is:
As the pps-gpio module is in April 2016 it has a flaw. It catches only
one edge of the PPS. You have a 50/50 chance you are seeing the
trailing edge rather than the leading edge (which is the actual top of
second). A patch to fix this has been submitted to the Linux kernel
maintainers but not merged.
Which edge the kernel will see, and the pulse width, are constant
depending on the GPS type and firmware. If the kernel sees the
trailing edge, the width of the pulse emitted by your GPS will
introduce a fixed lag from top of second to the time when you
actually see the PPS.
Pulse widths (and the induced lag) range from so fast the serial
driver can't see them to, worst case, 0.5s. The worst case is rare;
typical pulse widths are 50 to 200ms. Because the error is constant,
you can compensate it out with an offset if you know what it is.
//TO-DO: Measure the pulse width on the Adafruit and Uputronics hats.
//Figure out if they make the leading or trailing edge visible, somehow.
Gary, have I got this transcribed correctly?
I hope you're home this weekend, Phil, because I have a workout in
mind for that fancy diagnostic scope of yours. We need to measure the
PPS pulse width on the Adafruit HAT. If possible we need to figure
out whether it's he leading or trailing edge the kernel presents to
the RFC2783 interface.
We need the same information for the Uputronics HAT.
--
>>esr>>
[Prev in Thread] | Current Thread | [Next in Thread] |