Re: [gpsd-dev] Very basic PPS question:

[tz]

If the pulse needs to be "stretched", how is it going to capture the
rising edge. If the pulse has to be long, then there will be lots of
jitter in the time measurement.  It is best to have some kind of timer
input capture, but failing that a high-priority (perhaps even
non-maskable) edge interrupt on a GPIO pin that can store (and/or
"set-to-.000") whatever counter-timer resource is being used for
timing.

The Raspberry Pi seems to work well.

It might be better to miss pulses than to recognize them very late.

On Sat, Oct 19, 2013 at 4:19 PM, Hal Murray <address@hidden> wrote:
>
>> When a GPS asserts PPS, is it top of second for the in-stream data
>> *preceding* or *following*?
>
> If there is a standard, at least one device out there gets it wrong.  You may
> have to make a table.
>
> -----------
>
> address@hidden said:
>> I am not an expert.  I have heard that it can go either way, it can be
>> device-dependent, and there is a window around the PPS edge (which can be
>> the leading or trailing edge) where NTP will "associate" the NMEA sentence
>> with the PPS signal.  The window can be fudged to be earlier or later than
>> its default position.
>
> All the device manufacturers that I'm familiar with use the leading/rising
> edge of the PPS pulse.
>
> The confusion comes when people connect it to a modem control pin rather than
> a normal TTL/CMOS level logic receiver.  Almost all the TTL/CMOS to RS-232
> converter chips include an inverter and the ntpd drivers that handle PPS have
> an option to use the other edge.  So does the kernel interface.
>
> ----------
>
> Eric, for your PPS trivia collection...
>
> Most high end GPS gear uses a narrow PPS pulse, typically 10-20 microseconds.
>  That's narrow enough that some PCs can't/don't catch it, and sometimes they
> only get it some of the time.
>
> Most low end gear has longer pulse so this isn't a problem.  100 milliseconds
> is typical.
>
> TAPR has a pulse stretching gizmo: FatPPS
>   http://tapr.org/kits_fatpps.html
> It says "Price is TBD", so maybe that should be "had" rather than "has".
> I expect they will build another batch if they get enough interest.  It
> didn't use any parts that are hard to find.
>
>
>
> This might be a bug/oversight in the kernel(s).  I haven't looked at the
> detailed specs for any of the current modem chips.
>
> I don't see how to fix this if all you can do is read the current status.
> But I think I've seen some chips that had interrupt status bits, so if you
> asked for an interrupt when it went low-high, and it went low-high-low, the
> interrupt status bit for the low-high interrupt would be set and tell you
> that it was high at one point in the past even if it is currently low.
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>