Constraining data to out-of-phase clocks

[Rob Gaddi]

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[rickman]

On 5/13/2016 7:18 PM, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

To make sure I understand your issue, you want to *measure* the phase of
the clock the 1 pps is detected on to 1/8th the resolution of the 100
MHz clock itself? If you are not trying to measure that phase
relationship, I'm not sure why you would want to use 8 phases.

You can use the FFs in the I/O blocks to capture a true and inverted
clocked version of the signal on that pin. Each of four pins can
receive the same signal and be clocked by differently phased clocks. I
don't know how much differential timing you will see between the four
clocks as well as the true/inverted clocked FFs.

Another way to do this is to use a SERDES which PLLs the clock up in
frequency. But I don't think this lets you correlate the data received
to the main clock in an absolute way.

Otherwise I think you may need to do the sampling in external logic and
read the thermometer code in parallel.

A friend did something like this where he used a digital delay line that
I think he delay locked to the 1 PPS so he was on the edge of detecting
the 1 PPS on the same clock each cycle. I don't recall this for sure,
but it was something like this. His circuit was generating a 1 PPS for
an new atomic clock at the Naval Observatory. It sync'ed up to the
existing 1 PPS for a while to find the right phase, then locked and ran.
Sounds like what you are doing.

--

Rick C

 

[Tim Wescott]

On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can use
the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

There's not enough foreshadowing for me to figure out where the
thermometer comes in.

But I have lots of questions!

How precisely do you really need to know the 1PPS?

How can you know that the phase alignment is static, yet not know what it
is? The only way I can think of that you'd have a static phase alignment
is if there's a PLL locking to the 1PPS, and that implies a known phase
alignment.

Why not use a 100MHz clock that _is_ of known phase alignment? Seems to
me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp
with an integrator would add up to phase lock.

Certainly if you're using a free-running oscillator, even a crystal one,
your phase will, at best, be drifting all over the place, and it'll
probably have enough of an offset to it that it'll be running away rather
than exhibiting a random walk.

--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com

 

[rickman]

On 5/14/2016 12:48 AM, Tim Wescott wrote:

On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can use
the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

There's not enough foreshadowing for me to figure out where the
thermometer comes in.

But I have lots of questions!

How precisely do you really need to know the 1PPS?

How can you know that the phase alignment is static, yet not know what it
is? The only way I can think of that you'd have a static phase alignment
is if there's a PLL locking to the 1PPS, and that implies a known phase
alignment.

I can answer that, the 100 MHz and 1 PPS are from two different, but
both very stable sources... most likely. I expect this is like the
circuit my friend designed, a 1 PPS generator, or at least an internal
alignment to the external 1 PPS, but clocked from the local 100 MHz
clock. You would figure at any given time the phase relationship is
stable, but not known apriori. With a clock stability of 10^-... pick a
number, the phase would not change very fast.

Why not use a 100MHz clock that _is_ of known phase alignment? Seems to
me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp
with an integrator would add up to phase lock.

1 PPS from GPS, I expect clocked into the FPGA by a local atomic clock.

Certainly if you're using a free-running oscillator, even a crystal one,
your phase will, at best, be drifting all over the place, and it'll
probably have enough of an offset to it that it'll be running away rather
than exhibiting a random walk.

How about rubidium or cesium? I think they get better than 10^-12,
maybe 10^-15.

--

Rick C

 

[BobH]

On 05/13/2016 04:18 PM, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

The 1PPS signals out of the GPS receivers that I have seen, advertise
50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
understand of your project, I would just put the 1PPS signal in through
a couple of sync FF's and then compensate for an assumed delay of 2
clock cycles in the application of the sync'ed 1PPS signal downstream.

The phase relationship between the 1PPS input and the local 100MHz clock
won't be all that static unless you phase lock the 100MHz clock to the
1PPS. Even an exotic local oscillator is going to drift around with time
and temperature compared to the 1PPS.

Bobh

 

[rickman]

On 5/14/2016 1:17 AM, rickman wrote:

On 5/14/2016 12:48 AM, Tim Wescott wrote:
On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can use
the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

There's not enough foreshadowing for me to figure out where the
thermometer comes in.

But I have lots of questions!

How precisely do you really need to know the 1PPS?

How can you know that the phase alignment is static, yet not know what it
is? The only way I can think of that you'd have a static phase alignment
is if there's a PLL locking to the 1PPS, and that implies a known phase
alignment.

I can answer that, the 100 MHz and 1 PPS are from two different, but
both very stable sources... most likely. I expect this is like the
circuit my friend designed, a 1 PPS generator, or at least an internal
alignment to the external 1 PPS, but clocked from the local 100 MHz
clock. You would figure at any given time the phase relationship is
stable, but not known apriori. With a clock stability of 10^-... pick a
number, the phase would not change very fast.


Why not use a 100MHz clock that _is_ of known phase alignment? Seems to
me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp
with an integrator would add up to phase lock.

1 PPS from GPS, I expect clocked into the FPGA by a local atomic clock.


Certainly if you're using a free-running oscillator, even a crystal one,
your phase will, at best, be drifting all over the place, and it'll
probably have enough of an offset to it that it'll be running away rather
than exhibiting a random walk.

How about rubidium or cesium? I think they get better than 10^-12,
maybe 10^-15.

Now that I have read JL's post, I understand. You have two signals
provided by your customer and not enough information to know how they
are related or how to use them. This will all depend on what you need
to use the signals for. In other words, you have not provided enough
info for us to know how to design your system.

So how are you going to use these two signals? What are the
requirements you need to meet?

--

Rick C

 

[Rob Gaddi]

BobH wrote:

On 05/13/2016 04:18 PM, Rob Gaddi wrote:
I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.


The 1PPS signals out of the GPS receivers that I have seen, advertise
50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
understand of your project, I would just put the 1PPS signal in through
a couple of sync FF's and then compensate for an assumed delay of 2
clock cycles in the application of the sync'ed 1PPS signal downstream.

You know how sometimes when you get started on a project, and you get
some assumptions so firmly in your head that you don't even realize that
they're just assumptions? I had a substantially better opinion of the
jitter on the 1 PPS than is actually warranted. There are a _COUPLE_ of
receivers out there with 1 PPS jitter down to 10 ns (RMS), but for the
most part you're entirely correct. And even at 10, there's no
static relationship against a PLL-locked 100 MHz; it's just every pulse
for itself.

You'd think with as many times as I've learned that lesson, one of these
times it would stick.

The phase relationship between the 1PPS input and the local 100MHz clock
won't be all that static unless you phase lock the 100MHz clock to the
1PPS. Even an exotic local oscillator is going to drift around with time
and temperature compared to the 1PPS.

Now that's a question I have no idea how to resolve. Is the exotic
LO (let's assume cesium for fun) drifting and the PPS stable, or is it
(I'd guess) that no matter how stable the LO that the PPS is walking
around?

Making claims of objective truth on these timescales is hard.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Rob Gaddi]

rickman wrote:

On 5/14/2016 1:17 AM, rickman wrote:
On 5/14/2016 12:48 AM, Tim Wescott wrote:
On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can use
the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

There's not enough foreshadowing for me to figure out where the
thermometer comes in.

But I have lots of questions!

How precisely do you really need to know the 1PPS?

How can you know that the phase alignment is static, yet not know what it
is? The only way I can think of that you'd have a static phase alignment
is if there's a PLL locking to the 1PPS, and that implies a known phase
alignment.

I can answer that, the 100 MHz and 1 PPS are from two different, but
both very stable sources... most likely. I expect this is like the
circuit my friend designed, a 1 PPS generator, or at least an internal
alignment to the external 1 PPS, but clocked from the local 100 MHz
clock. You would figure at any given time the phase relationship is
stable, but not known apriori. With a clock stability of 10^-... pick a
number, the phase would not change very fast.


Why not use a 100MHz clock that _is_ of known phase alignment? Seems to
me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp
with an integrator would add up to phase lock.

1 PPS from GPS, I expect clocked into the FPGA by a local atomic clock.


Certainly if you're using a free-running oscillator, even a crystal one,
your phase will, at best, be drifting all over the place, and it'll
probably have enough of an offset to it that it'll be running away rather
than exhibiting a random walk.

How about rubidium or cesium? I think they get better than 10^-12,
maybe 10^-15.

Now that I have read JL's post, I understand. You have two signals
provided by your customer and not enough information to know how they
are related or how to use them. This will all depend on what you need
to use the signals for. In other words, you have not provided enough
info for us to know how to design your system.

So how are you going to use these two signals? What are the
requirements you need to meet?

Exactly, and so it's not, as both you and Tim mentioned, about
"measuring" the phase of the PPS signal per se. It's about being able
to clock it in, either by delaying the PPS or rotating the clock, in
such a way that you've guaranteed you're not sampling the PPS during the
maybe/maybenot interval. If you did you'd get a one clock ambiguity in
the sampling which would becomes period jitter. Always be early, or
always be late, but don't keep changing your mind.

Though as BobH pointed out, it's not quite so simple as that, either,
since the PPS reference from any purchasable source has tens of
nanoseconds of peak-to-peak period jitter. So my assumptions of phase
stability are blown, and it's back to the customer, bucket o' questions
in hand, to find out whether I'm supposed to faithfully replicate the
PPS or jitter clean it. So this question, while still interesting,
becomes moot for my actual application.

I hadn't even realized JL put it out to s.e.d. Generally I stay off his
groups and he off of mine, thus allowing both of us to maintain a
careful mystique of omniscience by sneaking off and asking folks on the
Internet.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Rob Gaddi]

Tim Wescott wrote:

On Mon, 16 May 2016 16:12:21 +0000, Rob Gaddi wrote:

rickman wrote:

On 5/14/2016 1:17 AM, rickman wrote:

Now that I have read JL's post, I understand. You have two signals
provided by your customer and not enough information to know how they
are related or how to use them. This will all depend on what you need
to use the signals for. In other words, you have not provided enough
info for us to know how to design your system.

So how are you going to use these two signals? What are the
requirements you need to meet?


Exactly, and so it's not, as both you and Tim mentioned, about
"measuring" the phase of the PPS signal per se. It's about being able
to clock it in, either by delaying the PPS or rotating the clock, in
such a way that you've guaranteed you're not sampling the PPS during the
maybe/maybenot interval. If you did you'd get a one clock ambiguity in
the sampling which would becomes period jitter. Always be early, or
always be late, but don't keep changing your mind.

Though as BobH pointed out, it's not quite so simple as that, either,
since the PPS reference from any purchasable source has tens of
nanoseconds of peak-to-peak period jitter. So my assumptions of phase
stability are blown, and it's back to the customer, bucket o' questions
in hand, to find out whether I'm supposed to faithfully replicate the
PPS or jitter clean it. So this question, while still interesting,
becomes moot for my actual application.

I hadn't even realized JL put it out to s.e.d. Generally I stay off his
groups and he off of mine, thus allowing both of us to maintain a
careful mystique of omniscience by sneaking off and asking folks on the
Internet.

And we ratted you out. Sorry.

C'est la vie. Honestly, once you've been seen to lose track of 4U
rackmount equipment in your own office, the mystique fades a bit.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[rickman]

On 5/16/2016 11:58 AM, Rob Gaddi wrote:

BobH wrote:

On 05/13/2016 04:18 PM, Rob Gaddi wrote:
I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.


The 1PPS signals out of the GPS receivers that I have seen, advertise
50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
understand of your project, I would just put the 1PPS signal in through
a couple of sync FF's and then compensate for an assumed delay of 2
clock cycles in the application of the sync'ed 1PPS signal downstream.


You know how sometimes when you get started on a project, and you get
some assumptions so firmly in your head that you don't even realize that
they're just assumptions? I had a substantially better opinion of the
jitter on the 1 PPS than is actually warranted. There are a _COUPLE_ of
receivers out there with 1 PPS jitter down to 10 ns (RMS), but for the
most part you're entirely correct. And even at 10, there's no
static relationship against a PLL-locked 100 MHz; it's just every pulse
for itself.

You'd think with as many times as I've learned that lesson, one of these
times it would stick.

The phase relationship between the 1PPS input and the local 100MHz clock
won't be all that static unless you phase lock the 100MHz clock to the
1PPS. Even an exotic local oscillator is going to drift around with time
and temperature compared to the 1PPS.


Now that's a question I have no idea how to resolve. Is the exotic
LO (let's assume cesium for fun) drifting and the PPS stable, or is it
(I'd guess) that no matter how stable the LO that the PPS is walking
around?

Making claims of objective truth on these timescales is hard.

It is still unclear to me what you wish to use the 1 PPS for exactly.
But if you require a 1 PPS which is locked to a 100 MHz, both of which
can be connected to the GPS signals, you would need to generate both
yourself. In another thread John has indicated he doesn't want to wait
for the synthesized 1 PPS to sync up to the GPS 1 PPS, but I don't see
where you have a choice if you really need the two signals locked in the
way you seem to want.

The issue is not a design issue really. It is fundamental to the fact
that the 1 PPS from the GPS has significant jitter.

As I've said before, I know someone who designed exactly this circuit
for one of the Naval Observatory's newer atomic clocks. I can put you
in touch if you would like. His design also has a time of day clock
display in case you need the time. lol

--

Rick C

 

[Tim Wescott]

On Mon, 16 May 2016 15:58:05 +0000, Rob Gaddi wrote:

BobH wrote:

On 05/13/2016 04:18 PM, Rob Gaddi wrote:
I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align
it to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but
undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has
to call for running the input signal from the input pin to 8 flops
such that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.


The 1PPS signals out of the GPS receivers that I have seen, advertise
50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
understand of your project, I would just put the 1PPS signal in through
a couple of sync FF's and then compensate for an assumed delay of 2
clock cycles in the application of the sync'ed 1PPS signal downstream.


You know how sometimes when you get started on a project, and you get
some assumptions so firmly in your head that you don't even realize that
they're just assumptions? I had a substantially better opinion of the
jitter on the 1 PPS than is actually warranted. There are a _COUPLE_ of
receivers out there with 1 PPS jitter down to 10 ns (RMS), but for the
most part you're entirely correct. And even at 10, there's no static
relationship against a PLL-locked 100 MHz; it's just every pulse for
itself.

You'd think with as many times as I've learned that lesson, one of these
times it would stick.

The phase relationship between the 1PPS input and the local 100MHz
clock won't be all that static unless you phase lock the 100MHz clock
to the 1PPS. Even an exotic local oscillator is going to drift around
with time and temperature compared to the 1PPS.


Now that's a question I have no idea how to resolve. Is the exotic LO
(let's assume cesium for fun) drifting and the PPS stable, or is it (I'd
guess) that no matter how stable the LO that the PPS is walking around?

Making claims of objective truth on these timescales is hard.

I'm pretty sure that it would be the 1PPS walking around, but walking
around with an average error of zero, or at least zero somewhere inside
the receiver, with a fixed offset to the spigot on the box, and another
fixed offset from that spigot to your chip. So your "objective truth" is
that the average time error is zero, or at least some knowable,
calibrateable constant.

GPS gets a message from each of a bunch of satellites that basically add
up to "this is what time it is and this is where I am". If the GPS
receiver knew what time it was, it could take three such messages and
determine where it is (because there are three spatial dimensions, so it
needs three equations to solve for three unknowns). But the GPS receiver
doesn't know what time it is, so it has to solve for time, too.

So a GPS receiver is either going to smooth the 1PPS itself, thereby
running the chance of making it worse, and requiring it to have a pretty
good time base, or it's going to not smooth the 1PPS, and instead just
use the most recent GPS time/position solution to decide when to pop off
the 1PPS pulse. If it doesn't smooth the 1PPS, then you can expect a
time error that's commensurate with the usual GPS position error of 10
meters or so (100 meters if the defense department decides to turn
selective availability on, and no guarantees that in time of war they
won't). 10 meters works out to 30ns, so...

--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com

 

[Tim Wescott]

On Mon, 16 May 2016 16:12:21 +0000, Rob Gaddi wrote:

rickman wrote:

On 5/14/2016 1:17 AM, rickman wrote:
On 5/14/2016 12:48 AM, Tim Wescott wrote:
On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align
it to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but
undefined.
There's plenty of time somewhere to not violate the setup time,
but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal
on all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park
a semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has
to call for running the input signal from the input pin to 8 flops
such that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of
the syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

There's not enough foreshadowing for me to figure out where the
thermometer comes in.

But I have lots of questions!

How precisely do you really need to know the 1PPS?

How can you know that the phase alignment is static, yet not know
what it is? The only way I can think of that you'd have a static
phase alignment is if there's a PLL locking to the 1PPS, and that
implies a known phase alignment.

I can answer that, the 100 MHz and 1 PPS are from two different, but
both very stable sources... most likely. I expect this is like the
circuit my friend designed, a 1 PPS generator, or at least an internal
alignment to the external 1 PPS, but clocked from the local 100 MHz
clock. You would figure at any given time the phase relationship is
stable, but not known apriori. With a clock stability of 10^-... pick
a number, the phase would not change very fast.


Why not use a 100MHz clock that _is_ of known phase alignment? Seems
to me that an VCXO plus some logic (possibly inside the FPGA) plus an
op-amp with an integrator would add up to phase lock.

1 PPS from GPS, I expect clocked into the FPGA by a local atomic
clock.


Certainly if you're using a free-running oscillator, even a crystal
one, your phase will, at best, be drifting all over the place, and
it'll probably have enough of an offset to it that it'll be running
away rather than exhibiting a random walk.

How about rubidium or cesium? I think they get better than 10^-12,
maybe 10^-15.

Now that I have read JL's post, I understand. You have two signals
provided by your customer and not enough information to know how they
are related or how to use them. This will all depend on what you need
to use the signals for. In other words, you have not provided enough
info for us to know how to design your system.

So how are you going to use these two signals? What are the
requirements you need to meet?


Exactly, and so it's not, as both you and Tim mentioned, about
"measuring" the phase of the PPS signal per se. It's about being able
to clock it in, either by delaying the PPS or rotating the clock, in
such a way that you've guaranteed you're not sampling the PPS during the
maybe/maybenot interval. If you did you'd get a one clock ambiguity in
the sampling which would becomes period jitter. Always be early, or
always be late, but don't keep changing your mind.

Though as BobH pointed out, it's not quite so simple as that, either,
since the PPS reference from any purchasable source has tens of
nanoseconds of peak-to-peak period jitter. So my assumptions of phase
stability are blown, and it's back to the customer, bucket o' questions
in hand, to find out whether I'm supposed to faithfully replicate the
PPS or jitter clean it. So this question, while still interesting,
becomes moot for my actual application.

I hadn't even realized JL put it out to s.e.d. Generally I stay off his
groups and he off of mine, thus allowing both of us to maintain a
careful mystique of omniscience by sneaking off and asking folks on the
Internet.

And we ratted you out. Sorry.

--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com

 

[rickman]

On 5/16/2016 12:12 PM, Rob Gaddi wrote:

rickman wrote:

On 5/14/2016 1:17 AM, rickman wrote:
On 5/14/2016 12:48 AM, Tim Wescott wrote:
On Fri, 13 May 2016 23:18:56 +0000, Rob Gaddi wrote:

I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align it
to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can use
the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has to
call for running the input signal from the input pin to 8 flops such
that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.

There's not enough foreshadowing for me to figure out where the
thermometer comes in.

But I have lots of questions!

How precisely do you really need to know the 1PPS?

How can you know that the phase alignment is static, yet not know what it
is? The only way I can think of that you'd have a static phase alignment
is if there's a PLL locking to the 1PPS, and that implies a known phase
alignment.

I can answer that, the 100 MHz and 1 PPS are from two different, but
both very stable sources... most likely. I expect this is like the
circuit my friend designed, a 1 PPS generator, or at least an internal
alignment to the external 1 PPS, but clocked from the local 100 MHz
clock. You would figure at any given time the phase relationship is
stable, but not known apriori. With a clock stability of 10^-... pick a
number, the phase would not change very fast.


Why not use a 100MHz clock that _is_ of known phase alignment? Seems to
me that an VCXO plus some logic (possibly inside the FPGA) plus an op-amp
with an integrator would add up to phase lock.

1 PPS from GPS, I expect clocked into the FPGA by a local atomic clock.


Certainly if you're using a free-running oscillator, even a crystal one,
your phase will, at best, be drifting all over the place, and it'll
probably have enough of an offset to it that it'll be running away rather
than exhibiting a random walk.

How about rubidium or cesium? I think they get better than 10^-12,
maybe 10^-15.

Now that I have read JL's post, I understand. You have two signals
provided by your customer and not enough information to know how they
are related or how to use them. This will all depend on what you need
to use the signals for. In other words, you have not provided enough
info for us to know how to design your system.

So how are you going to use these two signals? What are the
requirements you need to meet?


Exactly, and so it's not, as both you and Tim mentioned, about
"measuring" the phase of the PPS signal per se. It's about being able
to clock it in, either by delaying the PPS or rotating the clock, in
such a way that you've guaranteed you're not sampling the PPS during the
maybe/maybenot interval. If you did you'd get a one clock ambiguity in
the sampling which would becomes period jitter. Always be early, or
always be late, but don't keep changing your mind.

Though as BobH pointed out, it's not quite so simple as that, either,
since the PPS reference from any purchasable source has tens of
nanoseconds of peak-to-peak period jitter. So my assumptions of phase
stability are blown, and it's back to the customer, bucket o' questions
in hand, to find out whether I'm supposed to faithfully replicate the
PPS or jitter clean it. So this question, while still interesting,
becomes moot for my actual application.

I hadn't even realized JL put it out to s.e.d. Generally I stay off his
groups and he off of mine, thus allowing both of us to maintain a
careful mystique of omniscience by sneaking off and asking folks on the
Internet.

Certainly you are a lot more pleasant to discuss things with.

--

Rick C

 

[rickman]

On 5/16/2016 12:32 PM, Tim Wescott wrote:

On Mon, 16 May 2016 15:58:05 +0000, Rob Gaddi wrote:

BobH wrote:

On 05/13/2016 04:18 PM, Rob Gaddi wrote:
I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align
it to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but
undefined.
There's plenty of time somewhere to not violate the setup time, but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal on
all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park a
semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has
to call for running the input signal from the input pin to 8 flops
such that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of the
syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.


The 1PPS signals out of the GPS receivers that I have seen, advertise
50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
understand of your project, I would just put the 1PPS signal in through
a couple of sync FF's and then compensate for an assumed delay of 2
clock cycles in the application of the sync'ed 1PPS signal downstream.


You know how sometimes when you get started on a project, and you get
some assumptions so firmly in your head that you don't even realize that
they're just assumptions? I had a substantially better opinion of the
jitter on the 1 PPS than is actually warranted. There are a _COUPLE_ of
receivers out there with 1 PPS jitter down to 10 ns (RMS), but for the
most part you're entirely correct. And even at 10, there's no static
relationship against a PLL-locked 100 MHz; it's just every pulse for
itself.

You'd think with as many times as I've learned that lesson, one of these
times it would stick.

The phase relationship between the 1PPS input and the local 100MHz
clock won't be all that static unless you phase lock the 100MHz clock
to the 1PPS. Even an exotic local oscillator is going to drift around
with time and temperature compared to the 1PPS.


Now that's a question I have no idea how to resolve. Is the exotic LO
(let's assume cesium for fun) drifting and the PPS stable, or is it (I'd
guess) that no matter how stable the LO that the PPS is walking around?

Making claims of objective truth on these timescales is hard.

I'm pretty sure that it would be the 1PPS walking around, but walking
around with an average error of zero, or at least zero somewhere inside
the receiver, with a fixed offset to the spigot on the box, and another
fixed offset from that spigot to your chip. So your "objective truth" is
that the average time error is zero, or at least some knowable,
calibrateable constant.

GPS gets a message from each of a bunch of satellites that basically add
up to "this is what time it is and this is where I am". If the GPS
receiver knew what time it was, it could take three such messages and
determine where it is (because there are three spatial dimensions, so it
needs three equations to solve for three unknowns). But the GPS receiver
doesn't know what time it is, so it has to solve for time, too.

So a GPS receiver is either going to smooth the 1PPS itself, thereby
running the chance of making it worse, and requiring it to have a pretty
good time base, or it's going to not smooth the 1PPS, and instead just
use the most recent GPS time/position solution to decide when to pop off
the 1PPS pulse. If it doesn't smooth the 1PPS, then you can expect a
time error that's commensurate with the usual GPS position error of 10
meters or so (100 meters if the defense department decides to turn
selective availability on, and no guarantees that in time of war they
won't). 10 meters works out to 30ns, so...

I don't know for sure, but I find it hard to believe they would output
the 1 PPS based solely on one measurement each. While the 10 meter may
often constrain the accuracy of any one calculation, it is probabilistic
and can have a much larger actual error for a short amount of time.
While they may not be doing something equivalent to a PLL for the time,
I expect they are at least using some form of weighted average for
calculating the 1 PPS signal.

I had a GPS that would receive the signals ok in my house and connected
it to a utility that would map the location over time on an XY display.
I saw it walk off the property maybe once per day and come back within
a minute or less. That would be more like 50 meters. I've heard of
shipwrecks due to a loss of accuracy caused by poor constellations.
That has to be a lot more than 50 meters.

--

Rick C

 

[Tim Wescott]

On Mon, 16 May 2016 13:23:12 -0400, rickman wrote:

On 5/16/2016 12:32 PM, Tim Wescott wrote:
On Mon, 16 May 2016 15:58:05 +0000, Rob Gaddi wrote:

BobH wrote:

On 05/13/2016 04:18 PM, Rob Gaddi wrote:
I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align
it to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but
undefined.
There's plenty of time somewhere to not violate the setup time,
but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal
on all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park
a semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has
to call for running the input signal from the input pin to 8 flops
such that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of
the syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.


The 1PPS signals out of the GPS receivers that I have seen, advertise
50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
understand of your project, I would just put the 1PPS signal in
through a couple of sync FF's and then compensate for an assumed
delay of 2 clock cycles in the application of the sync'ed 1PPS signal
downstream.


You know how sometimes when you get started on a project, and you get
some assumptions so firmly in your head that you don't even realize
that they're just assumptions? I had a substantially better opinion
of the jitter on the 1 PPS than is actually warranted. There are a
_COUPLE_ of receivers out there with 1 PPS jitter down to 10 ns (RMS),
but for the most part you're entirely correct. And even at 10,
there's no static relationship against a PLL-locked 100 MHz; it's just
every pulse for itself.

You'd think with as many times as I've learned that lesson, one of
these times it would stick.

The phase relationship between the 1PPS input and the local 100MHz
clock won't be all that static unless you phase lock the 100MHz clock
to the 1PPS. Even an exotic local oscillator is going to drift around
with time and temperature compared to the 1PPS.


Now that's a question I have no idea how to resolve. Is the exotic LO
(let's assume cesium for fun) drifting and the PPS stable, or is it
(I'd guess) that no matter how stable the LO that the PPS is walking
around?

Making claims of objective truth on these timescales is hard.

I'm pretty sure that it would be the 1PPS walking around, but walking
around with an average error of zero, or at least zero somewhere inside
the receiver, with a fixed offset to the spigot on the box, and another
fixed offset from that spigot to your chip. So your "objective truth"
is that the average time error is zero, or at least some knowable,
calibrateable constant.

GPS gets a message from each of a bunch of satellites that basically
add up to "this is what time it is and this is where I am". If the GPS
receiver knew what time it was, it could take three such messages and
determine where it is (because there are three spatial dimensions, so
it needs three equations to solve for three unknowns). But the GPS
receiver doesn't know what time it is, so it has to solve for time,
too.

So a GPS receiver is either going to smooth the 1PPS itself, thereby
running the chance of making it worse, and requiring it to have a
pretty good time base, or it's going to not smooth the 1PPS, and
instead just use the most recent GPS time/position solution to decide
when to pop off the 1PPS pulse. If it doesn't smooth the 1PPS, then
you can expect a time error that's commensurate with the usual GPS
position error of 10 meters or so (100 meters if the defense department
decides to turn selective availability on, and no guarantees that in
time of war they won't). 10 meters works out to 30ns, so...

I don't know for sure, but I find it hard to believe they would output
the 1 PPS based solely on one measurement each. While the 10 meter may
often constrain the accuracy of any one calculation, it is probabilistic
and can have a much larger actual error for a short amount of time.
While they may not be doing something equivalent to a PLL for the time,
I expect they are at least using some form of weighted average for
calculating the 1 PPS signal.

I had a GPS that would receive the signals ok in my house and connected
it to a utility that would map the location over time on an XY display.
I saw it walk off the property maybe once per day and come back within
a minute or less. That would be more like 50 meters. I've heard of
shipwrecks due to a loss of accuracy caused by poor constellations. That
has to be a lot more than 50 meters.

There are some crowded harbors where the margin of error is less than
that. My master's thesis was building a data-link receiver for the US
Coast Guard's then-experimental differential GPS service*. At the time
selective availability was sometimes on ("SA" -- they turned it on for
Gulf War #1, AFAIK), and with SA on you could only get a 90% CEP of 100
meters. With differential GPS you could get it down to less than 10m.

I don't know if it's done, but when I was in grad school (and paying
attention, thanks to my prof) they were also talking about using
pseudolites, which are basically low-powered GPS satellites sitting on
the ground, doing what GPS satellites do. They augment the constellation
in places where it Really Matters (like narrow harbor mouths). A minute
of web research tells me that they're out there, but not whether they're
in common use.

* Everyone sees that and thinks I'm a microwave designer. No. The data
link was operating at their radiobeacon frequencies, around 300kHz. It's
a different world altogether, with entirely different propagation and
even noise characteristics than microwaves. It did, however, give me an
early appreciation for the fact that all the nice theory you're taught is
based on whatever you can do when the math is easy, not necessarily what
happens when you start from real-world phenomenon and try to work things
out from there.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

 

[BobH]

On 05/16/2016 08:58 AM, Rob Gaddi wrote:

BobH wrote:
On 05/13/2016 04:18 PM, Rob Gaddi wrote:

The phase relationship between the 1PPS input and the local 100MHz clock
won't be all that static unless you phase lock the 100MHz clock to the
1PPS. Even an exotic local oscillator is going to drift around with time
and temperature compared to the 1PPS.


Now that's a question I have no idea how to resolve. Is the exotic
LO (let's assume cesium for fun) drifting and the PPS stable, or is it
(I'd guess) that no matter how stable the LO that the PPS is walking
around?

I expect that the 1PPS out of the GPS receiver will be based on some
high frequency clock, My suspicion is that it is a 20MHz clock, hence
the 50nS jitter.

My guess is that both clocks are going to wander with respect to each
other, and if you use the simple 2 sync FF's you might get better
results if they do wander. If the clocks are almost synchronous, you
will get times when the input will fail to meet the setup for
significant durations and may get missed clock edges in bunches, where
if the clocks were not too close, you would only get an occasional
missed clock edge. This is speculation on my part though.


> Making claims of objective truth on these timescales is hard.

For Sure! Everything about GPS is handled statistically though, so it
just defines a probable window for it.

Good Luck,
BobH

 

[BobH]

On 05/16/2016 09:32 AM, Tim Wescott wrote:

GPS gets a message from each of a bunch of satellites that basically add
up to "this is what time it is and this is where I am". If the GPS
receiver knew what time it was, it could take three such messages and
determine where it is (because there are three spatial dimensions, so it
needs three equations to solve for three unknowns). But the GPS receiver
doesn't know what time it is, so it has to solve for time, too.

The fancy GPS "Timing Receivers" allow you to lock the position value to
a surveyed value (or a few day average of the position) and then you get
a more accurate time calculation with fewer sats.

Unless you are in a deep urban canyon or a real canyon, 4 sats should be
pretty easy to see for a full 3D fix with time. More sats lets the
receiver software pick and choose which ones to use for the lowest
residual error on the calculations.

BobH

 

[rickman]

On 5/16/2016 7:40 PM, BobH wrote:

On 05/16/2016 09:32 AM, Tim Wescott wrote:
GPS gets a message from each of a bunch of satellites that basically add
up to "this is what time it is and this is where I am". If the GPS
receiver knew what time it was, it could take three such messages and
determine where it is (because there are three spatial dimensions, so it
needs three equations to solve for three unknowns). But the GPS receiver
doesn't know what time it is, so it has to solve for time, too.

The fancy GPS "Timing Receivers" allow you to lock the position value to
a surveyed value (or a few day average of the position) and then you get
a more accurate time calculation with fewer sats.

Unless you are in a deep urban canyon or a real canyon, 4 sats should be
pretty easy to see for a full 3D fix with time. More sats lets the
receiver software pick and choose which ones to use for the lowest
residual error on the calculations.

It's not just how many sats, but where they are. Best if they are not
close together but rather spread around most of the sky.

--

Rick C

 

[BobH]

On 05/16/2016 04:43 PM, rickman wrote:

On 5/16/2016 7:40 PM, BobH wrote:
On 05/16/2016 09:32 AM, Tim Wescott wrote:
GPS gets a message from each of a bunch of satellites that basically add
up to "this is what time it is and this is where I am". If the GPS
receiver knew what time it was, it could take three such messages and
determine where it is (because there are three spatial dimensions, so it
needs three equations to solve for three unknowns). But the GPS
receiver
doesn't know what time it is, so it has to solve for time, too.

The fancy GPS "Timing Receivers" allow you to lock the position value to
a surveyed value (or a few day average of the position) and then you get
a more accurate time calculation with fewer sats.

Unless you are in a deep urban canyon or a real canyon, 4 sats should be
pretty easy to see for a full 3D fix with time. More sats lets the
receiver software pick and choose which ones to use for the lowest
residual error on the calculations.

It's not just how many sats, but where they are. Best if they are not
close together but rather spread around most of the sky.

True. That is why elevation accuracy is the worst axis. It is really
hard to get a signal from a satellite below you!

BobH

 

[Tim Wescott]

On Mon, 16 May 2016 13:23:12 -0400, rickman wrote:

On 5/16/2016 12:32 PM, Tim Wescott wrote:
On Mon, 16 May 2016 15:58:05 +0000, Rob Gaddi wrote:

BobH wrote:

On 05/13/2016 04:18 PM, Rob Gaddi wrote:
I've got a project coming up in which one of the things I'm going to
need to do is take in the 1 PPS output from a GPS receiver and align
it to the 100 MHz frequency reference clock.

The problem here is that the phase relationship is static but
undefined.
There's plenty of time somewhere to not violate the setup time,
but I
have to find where it is.

My thought had been to use one of the FPGA PLLs to spin up 8 phases
(well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal
on all of them. Then resychronize those to the 0° clock, read the
thermometer code, and figure out what the data phase is. Then I can
use the value opposite that and know I've got enough margin to park
a semitrailer in.

All well and good, except it dawns on me that I don't know how to
convince the tools to make timing for that. Somehow my SDC file has
to call for running the input signal from the input pin to 8 flops
such that the clock/data skew is less than 1 ns.

Anyone know how I'd do such a thing? Altera seems to support
set_max_skew, which might do it if I can disentangle the arcana of
the syntax from
http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
But I'm not necessarily wedded to Altera on this project.


The 1PPS signals out of the GPS receivers that I have seen, advertise
50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
understand of your project, I would just put the 1PPS signal in
through a couple of sync FF's and then compensate for an assumed
delay of 2 clock cycles in the application of the sync'ed 1PPS signal
downstream.


You know how sometimes when you get started on a project, and you get
some assumptions so firmly in your head that you don't even realize
that they're just assumptions? I had a substantially better opinion
of the jitter on the 1 PPS than is actually warranted. There are a
_COUPLE_ of receivers out there with 1 PPS jitter down to 10 ns (RMS),
but for the most part you're entirely correct. And even at 10,
there's no static relationship against a PLL-locked 100 MHz; it's just
every pulse for itself.

You'd think with as many times as I've learned that lesson, one of
these times it would stick.

The phase relationship between the 1PPS input and the local 100MHz
clock won't be all that static unless you phase lock the 100MHz clock
to the 1PPS. Even an exotic local oscillator is going to drift around
with time and temperature compared to the 1PPS.


Now that's a question I have no idea how to resolve. Is the exotic LO
(let's assume cesium for fun) drifting and the PPS stable, or is it
(I'd guess) that no matter how stable the LO that the PPS is walking
around?

Making claims of objective truth on these timescales is hard.

I'm pretty sure that it would be the 1PPS walking around, but walking
around with an average error of zero, or at least zero somewhere inside
the receiver, with a fixed offset to the spigot on the box, and another
fixed offset from that spigot to your chip. So your "objective truth"
is that the average time error is zero, or at least some knowable,
calibrateable constant.

GPS gets a message from each of a bunch of satellites that basically
add up to "this is what time it is and this is where I am". If the GPS
receiver knew what time it was, it could take three such messages and
determine where it is (because there are three spatial dimensions, so
it needs three equations to solve for three unknowns). But the GPS
receiver doesn't know what time it is, so it has to solve for time,
too.

So a GPS receiver is either going to smooth the 1PPS itself, thereby
running the chance of making it worse, and requiring it to have a
pretty good time base, or it's going to not smooth the 1PPS, and
instead just use the most recent GPS time/position solution to decide
when to pop off the 1PPS pulse. If it doesn't smooth the 1PPS, then
you can expect a time error that's commensurate with the usual GPS
position error of 10 meters or so (100 meters if the defense department
decides to turn selective availability on, and no guarantees that in
time of war they won't). 10 meters works out to 30ns, so...

I don't know for sure, but I find it hard to believe they would output
the 1 PPS based solely on one measurement each.
snip

At least one of the data sheets implied exactly that. I could see having
a philosophy of "do our best from moment to moment, and let the customer
make _their_ best from that". As a sometime-customer of places that want
to give me highly-cooked data, I can even appreciate the sentiment.

--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com