Buh… No graphs?
Um… “I’m a little teapot, short and stout…” :) I’ll link it here instead: http://www.kfu.com/~nsayer/Venus838LPx-T_graphs.zip > On Oct 7, 2016, at 7:46 AM, Nick Sayer via time-nuts <time-nuts@febo.com> > wrote: > > This is a bit overdue, but I finally got around to making at least an attempt > to measure the stability of the Venus838LPx-T timing module’s PPS stability. > > The results are a bit of a mixed bag. > > The module under test is one built into one of my OH300 GPSDOs. It’s inside > of a closed chassis, mounted about a half inch away from an OCXO, sitting on > my workbench inside an unconditioned garage. My guess is that over the course > of the test the ambient temperature varied by perhaps 15°F. The PPS output of > the module - as well as being fed into the controller and PLL - is fed into a > buffer before being presented on the diagnostic port. From there, it went > straight into input 1 of my 53220A. Input 2 came from the PPS output of a > Thunderbolt. The 53220A’s 10 MHz reference comes also from that same > Thunderbolt. No effort has been made to apply the sawtooth corrections > indicated by the PSTI,00 sentences. Both receivers are fed from the same > antenna and splitter. Reception is nearly ideal, with the Thunderbolt having > 7 or 8 satellites at all times, most of them with S:N > 45. > > The first surprise is that although both PPS signals are ostensibly synced > with GPS, there’s a 135 ns residual between the two. The residual (after ~15 > hours or so) has a ~2E-13 slope. This graph is the phase difference with that > residual removed. > > > > There are three variances visible. Firstly, there’s about a ±6ns “fuzz” > around the center on almost all samples. That can be explained by the > quantization error indicated in the NMEA output. Plotting those errors shows > a similar fuzz with a range of ±6 ns. Secondly, there’s a much slower wander > that’s mostly confined to a ±10 ns corridor. I attribute this to GPS itself. > How much of the wandering is due to which receiver is something I haven’t > attempted to figure out. Running this test with an undisciplined rubidium > oscillator might help, but the short term stability of the 5680A isn’t very > good, so I didn’t want to make it the first test standard. > > The third variance is more serious. Periodically the variance is much larger > - sometimes ±25ns or even more. These variances are not accounted for in the > sawtooth correction values. The only good thing that can be said about them > is that they’re fairly well balanced and can be easily averaged out. > > If you take a closer look at one, they sometimes appear adjacent to hanging > bridges: > > > > This isn’t always the case, but it’s often enough to potentially be more than > coincidence. > > All that said, I believe the resulting ADEV is in line with expectations for > a GPS receiver: > > > > > I’ve made an inquiry with SkyTraq to ask about the excessive excursions. I’ll > report back what their answer is. Given that the excursions are easily > averaged away, and given how inexpensive these modules are, I’m not bent out > of shape about it. And if it’s something SkyTraq can figure out how to update > in the firmware to report in their QE messages (so that it can be corrected > for externally), I won’t mind at all. > > _______________________________________________ > 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.
