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
<[email protected] <mailto:[email protected]>> 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 -- [email protected]
<mailto:[email protected]>
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 -- [email protected] <mailto:[email protected]>
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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
