[time-nuts] I've been thinking about a GPS receiver experiment
kb8tq at n1k.org
Wed Oct 25 12:18:27 UTC 2017
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.
> On Oct 25, 2017, at 12:14 AM, Ole Petter Ronningen <opronningen at 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.
> On Wed, Oct 25, 2017 at 12:56 AM, Magnus Danielson <
> magnus at rubidium.dyndns.org> wrote:
>> 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.
>> 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
>>> Comments appreciated.
>>> Skip Withrow
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>>> and follow the instructions there.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the Time-nuts_lists.febo.com