[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty |
Date: |
Fri, 22 Apr 2016 08:01:58 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hal Murray <address@hidden>:
> > 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.
>
> It doesn't take a fancy scope.
I was pretty sure it didn't. That was me gently teasing Phil about
how much he enjoyed showing off his newest toy last Saturday when my
wife and I were over at his and his wife's place for boardgaming.
"Betrayal at the House on the Hill", if that means anything to you.
To be fair, it's a damned impressive piece of kit even to a duffer
like me who knows very little about oscilloscopes - very capable,
portable, ruggedized, obviously designed for serious industrial
troubleshooting in field conditions (which is what Phil does).
(Mark, you'll get to meet Phil at Penguicon. He's a friend of the
project and a close associate of mine and Susan Sons's. He is the guy
who taught me enough soldering that I could assemble the HAT.)
> > We need the same information for the Uputronics HAT.
>
> Both are triggering on the rising edge.
I want to be very sure I know what you're asserting here. Are you
saying that you *know* the pps-gpio driver reports the leading edge in
both cases? While this is certainly plausible I'd like to know your
authority for it. It's a crucial, delicate point on which I would
hate for us to inadvertently spread misinformation.
Once verified it would be excellent news for the composition of the
HOWTO. It would mean I could exile the complications about edge
detection to an appendix that becomes relevant only when we have to
qualify a new HAT and check that the pps-gpio driver doesn't trigger
on trailing edge.
> The default pulse width should be in the data sheets.
I see one for the module in the AdaFruit HAT here:
https://cdn-shop.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf
There's a functional description of 1PPS on Page 7, but the description of
the 1PPS pin on page 13 doesn't give pulse timing. It does claim 10ns
typical accuracy,
> High end gear (GPSDOs) use narrow pulses. Low cost gear uses wide pulses.
> Anything over a few ms you can see with NTP.
Makes sense.
> Lab gear that uses PPS all agree to trigger on the rising edge. I can't
> think of any exceptions. (But I'm sure there is lots of gear using PPS that
> I don't know about.) Where you get into wrong edge problems is if you add
> TTL/CMOS to RS-232 level converters to connect low cost GPS toys to your PC.
> Connecting a TTL signal directly to a RS-232 modem control input pin ends up
> triggering on
This paragraph seems incomplete.
> [I haven't confirmed things with a scope. I will if you think it's
> important.]
I'll let Phil deploy his this weekend and have an educational experience
watching him do it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
- [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Eric S. Raymond, 2016/04/22
- Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Hal Murray, 2016/04/22
- Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Phil Salkie, 2016/04/22
- Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Eric S. Raymond, 2016/04/22
- Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Hal Murray, 2016/04/22
- Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Gary E. Miller, 2016/04/22
- Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Phil Salkie, 2016/04/22
- Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty, Gary E. Miller, 2016/04/22