[time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd

[Chris Albertson]

The problem here is "real world".  Yes in theory you can do it perfectly
but in the real world do all makes and models of GPS receivers get it
right?   I would not bet on it.

This is just like the argument over using NMEA only for timing.  Some GPS
receivers push out NEMA sentences with very little jitter and others only
follow the NMEA spec with only requires plus or minus one second accuracy
and then there is every shade of grey between.

My conservative engineering background tells me that unless the variation
of the pulse width is species you should assume the width is not controlled
at all.  It may even look good in testing but a firmware update would kill
that.  Likely in there is no regression test for not specified features.
People now days who write software (or firmware especially) will build an
automated test suit that lets them checks f the software still works after
making changes.  They are careful to test each written requirement.

The UART on the PC can interrupt on either raising or facing edges so if
the PPS is inverted you interrupt on the falling edge.   But you have to
get this right too

one IMPORTENT thing to  get right is to remember that on modern control
line under RS232 the logic is "active low".  TTL logic is "active high"
where a higher voltage means "one" and allow voltage means "zero" but this
is backwards for modern control under RS232   So, it is WAY-EASY to get it
wrong when connecting a TTL PPS to a modern control line.     You might
need an inverter because many level shifters invert the signal

The one thing that helps is the at 1Hz the signal is slow enough to see on
a volt meter, Even an old VTVM reacts fast enough

On Wed, Nov 9, 2016 at 2:44 PM, Tom Van Baak <tvb at leapsecond.com> wrote:

> Bob,
>
> The PIC's I use have essentially no jitter. If they generate a 1PPS the
> edge and the pulse width are perfect, down to picoseconds. The talk about
> "other stuff" and "priority" and "number of compares" and "ambiguity" is
> worrisome. It sounds like a design or coding flaw to me, like what happens
> when people try to do precise time with a high level language.
>
> /tvb
>
> ----- Original Message -----
> From: "Bob Stewart" <bob at evoria.net>
> To: "Discussion of precise time and frequency measurement" <
> time-nuts at febo.com>
> Sent: Wednesday, November 09, 2016 9:30 AM
> Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2
> SoC serial port for ntpd
>
>
> I'd like to comment on the idea of measuring the width of the pulse. My
> experience with creating the 1PPS from an interrupt is that it's fairly
> straightforward how to do the set interrupt: The interrupt happens, you
> execute one, maybe two instructions to raise the output pin, and you leave
> the interrupt routine. But, resetting the pin is a different story. Unless
> you've got a lot of interrupt vectors to play with, the reset part of the
> 1PPS signal is delegated to a general purpose timing interrupt where you're
> doing a lot of other stuff - and it has a somewhat lower priority. So, you
> wind up doing a number of compares to see if you should reset the pin,
> which adds some ambiguity to the set/reset times.
> Granted, I'm doing this on a general purpose PIC, but I have read comments
> about various receivers having some jitter on the reset side of their 1PPS
> pulse.
> Bob
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California