gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty


From: Hal Murray
Subject: Re: [gpsd-dev] SemPiTernal - Bounding PPS uncertainty
Date: Thu, 21 Apr 2016 23:35:44 -0700

address@hidden said:
> Gary, have I got this transcribed correctly?

Looks good to me.

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

> We need the same information for the Uputronics HAT. 

Both are triggering on the rising edge.

The default pulse width should be in the data sheets.

High end gear (GPSDOs) use narrow pulses.  Low cost gear uses wide pulses.  
Anything over a few ms you can see with NTP.

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

[I haven't confirmed things with a scope.  I will if you think it's 
important.]


Gary:  If anybody balks at the idea of capturing both edges because it's 
already grabbing the right one, tell them that the PPS path is also used for 
capturing general I/O pulse timing.


-- 
These are my opinions.  I hate spam.






reply via email to

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