[time-nuts] I've been thinking about a GPS receiver experiment

[Bob kb8tq]

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