Empathy List Archives

HM

Hal Murray

Wed, Nov 9, 2016 7:08 AM

Who cares if the PPS is inverted?

Good point. I wasn't paying attention to the PPS only context in the
subject. I keep forgetting which way is best for PPS. Fortunately, all the
software I've used knows how to handle inverted PPS.

The original message in this thread also mentioned RX and TX.

I'd probably get the RS-232 version since I'm likely to want the RX/TX too
and it's more likely to be useful on other projects.

--
These are my opinions. I hate spam.

gem@rellim.com said: > Who cares if the PPS is inverted? Good point. I wasn't paying attention to the PPS only context in the subject. I keep forgetting which way is best for PPS. Fortunately, all the software I've used knows how to handle inverted PPS. The original message in this thread also mentioned RX and TX. I'd probably get the RS-232 version since I'm likely to want the RX/TX too and it's more likely to be useful on other projects. -- These are my opinions. I hate spam.

SS

Scott Stobbe

Wed, Nov 9, 2016 12:53 PM

Just make sure you get a board with more than one Rx/Tx pair, unless you
are happy with two boards; one for Rx/Tx and one for PPS.

On Wed, Nov 9, 2016 at 2:08 AM, Hal Murray hmurray@megapathdsl.net wrote:

gem@rellim.com said:

Who cares if the PPS is inverted?

Good point. I wasn't paying attention to the PPS only context in the
subject. I keep forgetting which way is best for PPS. Fortunately, all
the
software I've used knows how to handle inverted PPS.

The original message in this thread also mentioned RX and TX.

I'd probably get the RS-232 version since I'm likely to want the RX/TX too
and it's more likely to be useful on other projects.

--
These are my opinions. I hate spam.

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

Just make sure you get a board with more than one Rx/Tx pair, unless you are happy with two boards; one for Rx/Tx and one for PPS. On Wed, Nov 9, 2016 at 2:08 AM, Hal Murray <hmurray@megapathdsl.net> wrote: > > gem@rellim.com said: > > Who cares if the PPS is inverted? > > Good point. I wasn't paying attention to the PPS only context in the > subject. I keep forgetting which way is best for PPS. Fortunately, all > the > software I've used knows how to handle inverted PPS. > > The original message in this thread also mentioned RX and TX. > > I'd probably get the RS-232 version since I'm likely to want the RX/TX too > and it's more likely to be useful on other projects. > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >

CA

Chris Albertson

Wed, Nov 9, 2016 4:41 PM

On Tue, Nov 8, 2016 at 11:08 PM, Hal Murray hmurray@megapathdsl.net wrote:

gem@rellim.com said:

Who cares if the PPS is inverted?

If the signal is NOT inverted then the raising edge will be within
nanoseconds of the UTC seconds "tick". The inverted PPS will have the
edge delayed somewhat. It is not even clear if the length of the delay is
constant.

If using the PPS for timing and the PPS is inverted you will have to
measure the delay length an account for in the config file.

--

Chris Albertson
Redondo Beach, California

On Tue, Nov 8, 2016 at 11:08 PM, Hal Murray <hmurray@megapathdsl.net> wrote: > > gem@rellim.com said: > > Who cares if the PPS is inverted? > If the signal is NOT inverted then the raising edge will be within nanoseconds of the UTC seconds "tick". The inverted PPS will have the edge delayed somewhat. It is not even clear if the length of the delay is constant. If using the PPS for timing and the PPS is inverted you will have to measure the delay length an account for in the config file. -- Chris Albertson Redondo Beach, California

SS

Scott Stobbe

Wed, Nov 9, 2016 4:57 PM

FWIW, the 16450 uart can interrupt on any modem line change, whether it be
rising or falling.

On Wed, Nov 9, 2016 at 11:41 AM, Chris Albertson albertson.chris@gmail.com
wrote:

On Tue, Nov 8, 2016 at 11:08 PM, Hal Murray hmurray@megapathdsl.net
wrote:

gem@rellim.com said:

Who cares if the PPS is inverted?

If the signal is NOT inverted then the raising edge will be within
nanoseconds of the UTC seconds "tick". The inverted PPS will have the
edge delayed somewhat. It is not even clear if the length of the delay is
constant.

If using the PPS for timing and the PPS is inverted you will have to
measure the delay length an account for in the config file.

--

Chris Albertson
Redondo Beach, California

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

FWIW, the 16450 uart can interrupt on any modem line change, whether it be rising or falling. On Wed, Nov 9, 2016 at 11:41 AM, Chris Albertson <albertson.chris@gmail.com> wrote: > On Tue, Nov 8, 2016 at 11:08 PM, Hal Murray <hmurray@megapathdsl.net> > wrote: > > > > > gem@rellim.com said: > > > Who cares if the PPS is inverted? > > > > If the signal is NOT inverted then the raising edge will be within > nanoseconds of the UTC seconds "tick". The inverted PPS will have the > edge delayed somewhat. It is not even clear if the length of the delay is > constant. > > If using the PPS for timing and the PPS is inverted you will have to > measure the delay length an account for in the config file. > > > > > -- > > Chris Albertson > Redondo Beach, California > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >

BS

Bob Stewart

Wed, Nov 9, 2016 5:30 PM

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

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Chris Albertson <albertson.chris@gmail.com>

To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wednesday, November 9, 2016 10:41 AM
Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd

On Tue, Nov 8, 2016 at 11:08 PM, Hal Murray hmurray@megapathdsl.net wrote:

gem@rellim.com said:

Who cares if the PPS is inverted?

If the signal is NOT inverted then the raising edge will be within
nanoseconds of the UTC seconds "tick". The inverted PPS will have the
edge delayed somewhat. It is not even clear if the length of the delay is
constant.

If using the PPS for timing and the PPS is inverted you will have to
measure the delay length an account for in the config file.

--

Chris Albertson
Redondo Beach, California

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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 ----------------------------------------------------------------- AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info From: Chris Albertson <albertson.chris@gmail.com> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Sent: Wednesday, November 9, 2016 10:41 AM Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd On Tue, Nov 8, 2016 at 11:08 PM, Hal Murray <hmurray@megapathdsl.net> wrote: > > gem@rellim.com said: > > Who cares if the PPS is inverted? > If the signal is NOT inverted then the raising edge will be within nanoseconds of the UTC seconds "tick". The inverted PPS will have the edge delayed somewhat. It is not even clear if the length of the delay is constant. If using the PPS for timing and the PPS is inverted you will have to measure the delay length an account for in the config file. -- Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.

TV

Tom Van Baak

Wed, Nov 9, 2016 10:44 PM

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@evoria.net
To: "Discussion of precise time and frequency measurement" time-nuts@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

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@evoria.net> To: "Discussion of precise time and frequency measurement" <time-nuts@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

BS

Bob Stewart

Wed, Nov 9, 2016 11:28 PM

Tom,
How many times have people posted here, on time-nuts, not to trust the trailing edge of a 1PPS pulse?

Bob -----------------------------------------------------------------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Tom Van Baak <tvb@LeapSecond.com>

To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wednesday, November 9, 2016 4:44 PM
Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd

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@evoria.net
To: "Discussion of precise time and frequency measurement" time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Tom, How many times have people posted here, on time-nuts, not to trust the trailing edge of a 1PPS pulse? Bob ----------------------------------------------------------------- AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info From: Tom Van Baak <tvb@LeapSecond.com> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Sent: Wednesday, November 9, 2016 4:44 PM Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd 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@evoria.net> To: "Discussion of precise time and frequency measurement" <time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.

AG

Adrian Godwin

Wed, Nov 9, 2016 11:39 PM

But trailing isn't the same as falling. The leading edge can be of either
polarity.

On Wed, Nov 9, 2016 at 11:28 PM, Bob Stewart bob@evoria.net wrote:

Tom,
How many times have people posted here, on time-nuts, not to trust the
trailing edge of a 1PPS pulse?

Bob -----------------------------------------------------------------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

   From: Tom Van Baak <tvb@LeapSecond.com>

To: Discussion of precise time and frequency measurement <
time-nuts@febo.com>
Sent: Wednesday, November 9, 2016 4:44 PM
Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2
SoC serial port for ntpd

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@evoria.net
To: "Discussion of precise time and frequency measurement" <
time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.

But trailing isn't the same as falling. The leading edge can be of either polarity. On Wed, Nov 9, 2016 at 11:28 PM, Bob Stewart <bob@evoria.net> wrote: > Tom, > How many times have people posted here, on time-nuts, not to trust the > trailing edge of a 1PPS pulse? > > Bob ----------------------------------------------------------------- > AE6RV.com > > GFS GPSDO list: > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > > From: Tom Van Baak <tvb@LeapSecond.com> > To: Discussion of precise time and frequency measurement < > time-nuts@febo.com> > Sent: Wednesday, November 9, 2016 4:44 PM > Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 > SoC serial port for ntpd > > 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@evoria.net> > To: "Discussion of precise time and frequency measurement" < > time-nuts@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >

BS

Bob Stewart

Wed, Nov 9, 2016 11:55 PM

Hi Adrian,
Then I apologize for doing such a poor job of getting my meaning across. What I was trying to show was that for a number of reasons, you can't necessarily trust the trailing edge of a 1PPS pulse. If you're generating a pulse every second from a clock, and that's all your doing, then, yes, it's an easy job to make the pulsewidth very stable at whatever value you choose.

Bob
-----------------------------------------------------------------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Adrian Godwin <artgodwin@gmail.com>

To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@febo.com
Cc: Tom Van Baak tvb@leapsecond.com
Sent: Wednesday, November 9, 2016 5:39 PM
Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd

But trailing isn't the same as falling. The leading edge can be of either polarity.

On Wed, Nov 9, 2016 at 11:28 PM, Bob Stewart bob@evoria.net wrote:

Tom,
How many times have people posted here, on time-nuts, not to trust the trailing edge of a 1PPS pulse?

Bob -------------------------- ------------------------------ ---------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/ GFS-GPSDOs/info

From: Tom Van Baak tvb@LeapSecond.com
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wednesday, November 9, 2016 4:44 PM
Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd

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@evoria.net
To: "Discussion of precise time and frequency measurement" time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/ mailman/listinfo/time-nuts
and follow the instructions there.

Hi Adrian, Then I apologize for doing such a poor job of getting my meaning across. What I was trying to show was that for a number of reasons, you can't necessarily trust the trailing edge of a 1PPS pulse. If you're generating a pulse every second from a clock, and that's all your doing, then, yes, it's an easy job to make the pulsewidth very stable at whatever value you choose. Bob ----------------------------------------------------------------- AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/GFS-GPSDOs/info From: Adrian Godwin <artgodwin@gmail.com> To: Bob Stewart <bob@evoria.net>; Discussion of precise time and frequency measurement <time-nuts@febo.com> Cc: Tom Van Baak <tvb@leapsecond.com> Sent: Wednesday, November 9, 2016 5:39 PM Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd But trailing isn't the same as falling. The leading edge can be of either polarity. On Wed, Nov 9, 2016 at 11:28 PM, Bob Stewart <bob@evoria.net> wrote: Tom, How many times have people posted here, on time-nuts, not to trust the trailing edge of a 1PPS pulse? Bob -------------------------- ------------------------------ --------- AE6RV.com GFS GPSDO list: groups.yahoo.com/neo/groups/ GFS-GPSDOs/info From: Tom Van Baak <tvb@LeapSecond.com> To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Sent: Wednesday, November 9, 2016 4:44 PM Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd 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@evoria.net> To: "Discussion of precise time and frequency measurement" <time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/ mailman/listinfo/time-nuts and follow the instructions there. ______________________________ _________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/ mailman/listinfo/time-nuts and follow the instructions there.

BC

Bob Camp

Wed, Nov 9, 2016 11:55 PM

Hi

On Nov 9, 2016, at 6:28 PM, Bob Stewart bob@evoria.net wrote:

Tom,
How many times have people posted here, on time-nuts, not to trust the trailing edge of a 1PPS pulse?

The rest of the caution is : The leading edge is the one that is “on time” and the second edge is an
unknown offset from it …. If you have something made back in the 1950’s you might have an issue
with an analog one shot.

Bob

Bob -----------------------------------------------------------------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Tom Van Baak <tvb@LeapSecond.com>

To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wednesday, November 9, 2016 4:44 PM
Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd

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@evoria.net
To: "Discussion of precise time and frequency measurement" time-nuts@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi > On Nov 9, 2016, at 6:28 PM, Bob Stewart <bob@evoria.net> wrote: > > Tom, > How many times have people posted here, on time-nuts, not to trust the trailing edge of a 1PPS pulse? The rest of the caution is : The leading edge is the one that is “on time” and the second edge is an unknown offset from it …. If you have something made back in the 1950’s you might have an issue with an analog one shot. Bob > > Bob ----------------------------------------------------------------- > AE6RV.com > > GFS GPSDO list: > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > > From: Tom Van Baak <tvb@LeapSecond.com> > To: Discussion of precise time and frequency measurement <time-nuts@febo.com> > Sent: Wednesday, November 9, 2016 4:44 PM > Subject: Re: [time-nuts] How to get PPS from ublox mini-PCI GPS to APU2 SoC serial port for ntpd > > 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@evoria.net> > To: "Discussion of precise time and frequency measurement" <time-nuts@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

time-nuts@lists.febo.com

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