I've been thinking about a GPS receiver experiment
Hello time-nuts,
I've been thinking about a GPS receiver experiment and just wondering
if there are any opinions or prior experience that might save me a lot
of time.
What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has
settings for OCXO/rubidium/cesium dynamics.
Then, (and here is the unknown part) what if the GPS receiver 1pps is
used to discipline the rubidium? This basically forms a feedback
loop, so could either hurt or help - depending. Supposedly the better
oscillator would give a better GPS solution. And the better solution
(1pps) should provide a better oscillator frequency.
We know that GPS receivers using asynchronous clocks have 1pps errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?
Comments appreciated.
Regards,
Skip Withrow
Skip,
I would rather use the rich Novatel reports and read out the time error
and use that as your phase detector, then the normal PI-loop stuff with
an optional low-pass to add and then use that to steer the rubidium.
It's one of those, when I get time, projects.
Cheers,
Magnus
On 10/25/2017 12:17 AM, Skip Withrow wrote:
Hello time-nuts,
I've been thinking about a GPS receiver experiment and just wondering
if there are any opinions or prior experience that might save me a lot
of time.
What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has
settings for OCXO/rubidium/cesium dynamics.
Then, (and here is the unknown part) what if the GPS receiver 1pps is
used to discipline the rubidium? This basically forms a feedback
loop, so could either hurt or help - depending. Supposedly the better
oscillator would give a better GPS solution. And the better solution
(1pps) should provide a better oscillator frequency.
We know that GPS receivers using asynchronous clocks have 1pps errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?
Comments appreciated.
Regards,
Skip Withrow
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.
Hello Skip,
I have a theory, but it will be interesting to see what others say.
Assuming that the
1 PPS error to which you refer is the so-called "sawtooth" error, I've come
to suspect
that the rate at which the individual PPS pulses walk across the sawtooth
is related to,
and likely proportional to, the error of the internal (or in this case, the
external) clock
oscillator. If I'm right about its being proportional, then it seems to me
that having
the GPS's clock oscillator right on would freeze the PPS error at some
fixed value,
not necessarily zero. If true, you'd experience a constant bias error to
the timing of
the PPS pulses.
Now you would seem to be in the perfect position to refute or verify my
thinking,
provided you have the means to vary an external clock's frequency in a
controlled
way, by watching how the PPS error behavior changes as a function of the
clock
frequency.
If you manage to try the experiment, I'd greatly appreciate hearing the
outcome.
Dana K8YUM
On Tue, Oct 24, 2017 at 5:17 PM, Skip Withrow skip.withrow@gmail.com
wrote:
Hello time-nuts,
I've been thinking about a GPS receiver experiment and just wondering
if there are any opinions or prior experience that might save me a lot
of time.
What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has
settings for OCXO/rubidium/cesium dynamics.
Then, (and here is the unknown part) what if the GPS receiver 1pps is
used to discipline the rubidium? This basically forms a feedback
loop, so could either hurt or help - depending. Supposedly the better
oscillator would give a better GPS solution. And the better solution
(1pps) should provide a better oscillator frequency.
We know that GPS receivers using asynchronous clocks have 1pps errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?
Comments appreciated.
Regards,
Skip Withrow
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
The “best” approach would be to use a receiver that reports what’s going on to some pretty
good resolution (say picoseconds). You also measure the pps offset (say to picoseconds).
Then you feed both numbers into a software loop.
Since you are after a loop with a “many days” sort of response, you have lots of time to do the
math. Updates every minute are probably overkill. Since the math can take a long time, the CPU
requirements aren’t very crazy. Equally, you can use a PC and get the job done. OS overhead
likely isn’t going to be a big deal.
You can separate out the math and run it at a pretty high level. Tweaking this or that would all
be done in a high level language. No need for going crazy with assembler The loop is likely to
be a “step and wait” sort of thing. There will be a bit of tweaking. Doing that in something easy
to use is an advantage. Having it buried in some mystery firmware written by who knows who
is not a good thing in this case.
Bob
On Oct 24, 2017, at 7:09 PM, Dana Whitlow k8yumdoober@gmail.com wrote:
Hello Skip,
I have a theory, but it will be interesting to see what others say.
Assuming that the
1 PPS error to which you refer is the so-called "sawtooth" error, I've come
to suspect
that the rate at which the individual PPS pulses walk across the sawtooth
is related to,
and likely proportional to, the error of the internal (or in this case, the
external) clock
oscillator. If I'm right about its being proportional, then it seems to me
that having
the GPS's clock oscillator right on would freeze the PPS error at some
fixed value,
not necessarily zero. If true, you'd experience a constant bias error to
the timing of
the PPS pulses.
Now you would seem to be in the perfect position to refute or verify my
thinking,
provided you have the means to vary an external clock's frequency in a
controlled
way, by watching how the PPS error behavior changes as a function of the
clock
frequency.
If you manage to try the experiment, I'd greatly appreciate hearing the
outcome.
Dana K8YUM
On Tue, Oct 24, 2017 at 5:17 PM, Skip Withrow skip.withrow@gmail.com
wrote:
Hello time-nuts,
I've been thinking about a GPS receiver experiment and just wondering
if there are any opinions or prior experience that might save me a lot
of time.
What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has
settings for OCXO/rubidium/cesium dynamics.
Then, (and here is the unknown part) what if the GPS receiver 1pps is
used to discipline the rubidium? This basically forms a feedback
loop, so could either hurt or help - depending. Supposedly the better
oscillator would give a better GPS solution. And the better solution
(1pps) should provide a better oscillator frequency.
We know that GPS receivers using asynchronous clocks have 1pps errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?
Comments appreciated.
Regards,
Skip Withrow
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.
I did log the #TIME message for several weeks on an OEMV-3 a while back.
The results were a bit suspicious, so I checked with Novatel support -
turns out the PPS on the OEMV (and I presume that also holds for OEM4) is
derived from L1 only - and the jitter is nothing to brag about. So for
disciplining with PPS, something like a UBlox would be better as far as I
can tell.
The other option is to log the #RANGE-message from the Novatel, convert to
RINEX and solve with PPP, and use the output of that to adjust the
rubidium. The added benefit is that you'll have an excellent log of what
your reference is doing if you get odd results in some measurements.
Ole
On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Skip,
I would rather use the rich Novatel reports and read out the time error
and use that as your phase detector, then the normal PI-loop stuff with an
optional low-pass to add and then use that to steer the rubidium.
It's one of those, when I get time, projects.
Cheers,
Magnus
On 10/25/2017 12:17 AM, Skip Withrow wrote:
Hello time-nuts,
I've been thinking about a GPS receiver experiment and just wondering
if there are any opinions or prior experience that might save me a lot
of time.
What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has
settings for OCXO/rubidium/cesium dynamics.
Then, (and here is the unknown part) what if the GPS receiver 1pps is
used to discipline the rubidium? This basically forms a feedback
loop, so could either hurt or help - depending. Supposedly the better
oscillator would give a better GPS solution. And the better solution
(1pps) should provide a better oscillator frequency.
We know that GPS receivers using asynchronous clocks have 1pps errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?
Comments appreciated.
Regards,
Skip Withrow
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/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/m
ailman/listinfo/time-nuts
and follow the instructions there.
Hi
Since you are doing a loop design that involves “months long” data runs, having
good logging and monitoring is a key part of the process. Without the testing side
of the process you are pretty much guaranteed to go astray in one way or the other.
That’s not to say you have to have a giant lab full of millions of dollars of gear. You
will need something to compare to and good logs of what goes in, what comes out,
and as much of the intermediates as you can stand to look at.
Bob
On Oct 25, 2017, at 12:14 AM, Ole Petter Ronningen opronningen@gmail.com wrote:
I did log the #TIME message for several weeks on an OEMV-3 a while back.
The results were a bit suspicious, so I checked with Novatel support -
turns out the PPS on the OEMV (and I presume that also holds for OEM4) is
derived from L1 only - and the jitter is nothing to brag about. So for
disciplining with PPS, something like a UBlox would be better as far as I
can tell.
The other option is to log the #RANGE-message from the Novatel, convert to
RINEX and solve with PPP, and use the output of that to adjust the
rubidium. The added benefit is that you'll have an excellent log of what
your reference is doing if you get odd results in some measurements.
Ole
On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
Skip,
I would rather use the rich Novatel reports and read out the time error
and use that as your phase detector, then the normal PI-loop stuff with an
optional low-pass to add and then use that to steer the rubidium.
It's one of those, when I get time, projects.
Cheers,
Magnus
On 10/25/2017 12:17 AM, Skip Withrow wrote:
Hello time-nuts,
I've been thinking about a GPS receiver experiment and just wondering
if there are any opinions or prior experience that might save me a lot
of time.
What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS even has
settings for OCXO/rubidium/cesium dynamics.
Then, (and here is the unknown part) what if the GPS receiver 1pps is
used to discipline the rubidium? This basically forms a feedback
loop, so could either hurt or help - depending. Supposedly the better
oscillator would give a better GPS solution. And the better solution
(1pps) should provide a better oscillator frequency.
We know that GPS receivers using asynchronous clocks have 1pps errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?
Comments appreciated.
Regards,
Skip Withrow
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/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/m
ailman/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.
Hei Ole Petter,
You don't want to look at the PPS in that case.
You want to look at how the receivers clock solution pans out.
Since the receivers clock is set but then ticks to the speed of the
rubidium, you now got a high resolution frequency and phase comparison.
Depending on the clock-mode, you might or might not experience
clock-reset events. Typically 1 ms shifts of clock time. One needs to
handle that in case you are not able to drive the clock quick enough
towards on average be where the GPS/UTC average solution drives it to.
Anyway, so there is a different clock message, just don't recall it from
the top of my head. I just recall that the Novatels is fairly generous
with this data
Cheers,
Magnus
On 10/25/2017 06:14 AM, Ole Petter Ronningen wrote:
I did log the #TIME message for several weeks on an OEMV-3 a while back.
The results were a bit suspicious, so I checked with Novatel support -
turns out the PPS on the OEMV (and I presume that also holds for OEM4)
is derived from L1 only - and the jitter is nothing to brag about. So
for disciplining with PPS, something like a UBlox would be better as far
as I can tell.
The other option is to log the #RANGE-message from the Novatel, convert
to RINEX and solve with PPP, and use the output of that to adjust the
rubidium. The added benefit is that you'll have an excellent log of what
your reference is doing if you get odd results in some measurements.
Ole
On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson
<magnus@rubidium.dyndns.org mailto:magnus@rubidium.dyndns.org> wrote:
Skip,
I would rather use the rich Novatel reports and read out the time
error and use that as your phase detector, then the normal PI-loop
stuff with an optional low-pass to add and then use that to steer
the rubidium.
It's one of those, when I get time, projects.
Cheers,
Magnus
On 10/25/2017 12:17 AM, Skip Withrow wrote:
Hello time-nuts,
I've been thinking about a GPS receiver experiment and just
wondering
if there are any opinions or prior experience that might save me
a lot
of time.
What I have been thinking about doing is taking a GPS receiver
(Novatel OEM4-G2) that has provisions for an external clock (5 or 10
MHz) and driving it with a rubidium oscillator (that has 1pps
disciplining, (such as the X72 v5.05 or SRS PRS-10). The GPS
even has
settings for OCXO/rubidium/cesium dynamics.
Then, (and here is the unknown part) what if the GPS receiver
1pps is
used to discipline the rubidium? This basically forms a feedback
loop, so could either hurt or help - depending. Supposedly the
better
oscillator would give a better GPS solution. And the better
solution
(1pps) should provide a better oscillator frequency.
We know that GPS receivers using asynchronous clocks have 1pps
errors
and hanging bridges (OEM4 is spec'd at 20ns rms), If the
oscillator is
on 10MHz and disciplined will the 1pps error be reduced such as the
Thunderbolt?
Comments appreciated.
Regards,
Skip Withrow
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
<mailto:time-nuts@febo.com>
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
<https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com <mailto:time-nuts@febo.com>
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
<https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
and follow the instructions there.