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 <[email protected]> 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 <[email protected]> > 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] >> To unsubscribe, go to 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. _______________________________________________ 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.
