Hi In modern GPS modules the sawtooth error is no longer truncated at the 1 ns level. The have been giving you far more resolution than that for 10 years now. The resolution is not just useless bits. If you compare the result to a cesium standard they do improve the GPS.
Bob On Mar 6, 2014, at 1:30 AM, [email protected] wrote: > > Wow! One post and I've got the two top heavyweights against me! Let > me introduce myself. > > I am a retired electronics engineer with over 50 years of experience > in instrumentation and metrology. Here is my patent list: > > http://www.pst.netii.net/patents.htm > > Among the achievements listed, I claim credit for the first > disclosure of the now universal dual-d phase-frequency detector, and > for the technique called "Phase Margin Analysis" as applied to hard > disk bdrive it error analysis. The technology has evolved > tremendously since the 1970's, but this was the first to show that > rapid bit error analysis was possible. The internet would not be > possible without this basic technique, since it would not be > possible to manufacture hard disks fast enough. > > Another significant invention is Binary Sampling. I will talk more > about this later, but some information is on my web site at > > http://www.pst.netii.net/sampler/index.htm > > also starting on page 6 of > > http://www.pst.netii.net/pdfs/tdrpaper.pdf > > One of the significant advantages of the Binary Sampler is the > elimination of Gaussian and Impulse noise. Unlike conventional diode > bridge samplers, the performance improves as the frequency > increases. > > After working with the Binary Sampler, I am always dismayed to view > the noisy graphs presented in time-nuts and other forums. The noise > is hiding the interesting stuff and making it virtually impossible > to understand what is actually going on. I Think the Binary Sampler > can do a lot to help unravel the issues. > > I now intersperse replies: > >> Hi( > >> While you see a lot of pretty plots in GPS spec sheets showing >> clean looking sawtooth sort of offsets marching down the page, >> that?s not what I see on a real receiver. The real data, even >> compared to a 5071A is much more random. It will indeed ?hang?, >> but it also will reverse far more often than the pretty data >> sheets suggest. A simple model would be to add the sawtooth to >> some sort of random process. The sawtooth comes from the TCXO, the >> random looking stuff comes from the GPS solution. > >> The oscillator in most timing modules is one form or another of a >> TCXO. Often they have digital compensation (one way or another). >> Their frequency versus temperature curves are not the simple third >> order curve you would expect from a bare crystal. They have a much >> higher order frequency versus temperature curve (6th, 8th ?). That >> makes even the simple ?frequency goes down when temp goes up? >> decision pretty tough. If they are doing some sort of auto >> correction TCXO based on the GPS it would get even more crazy. In >> that case the curve would be changing real time. > >> Since the sawtooth changes multiple ?runs? per minute in a room >> that holds 2C / 30 minutes, you could guess that a control of >> 0.01C would be needed to have any luck steering the oscillator. >> It?s nowhere near that simple, so that?s not even up to the ?wild >> guess? level of confidence. If it?s close, that?s not going to be >> very easy all by it?s self. A double loop control is likely to be >> needed. > >> Combine the random jitter with the (possibly) tough temperature >> control problem, and frequency reversals - this is a real can of >> worms. > >> ??????????? > >> Way lots easier approach: > >> 1) You already need a CPU to set up the GPS, read the sawtooth data stream >> and do a control loop. It?s free / same with either approach. >> 2) Rip a VCTCXO out of something (or buy one cheap). >> 3) PWM control the TCXO, use it as your CPU clock >> 4) Generate a PPS with a timer output on the CPU. >> 5) Do a cheap / simple / easy TDC on the GPS pps, it will cost less that >> what ever was going to drive the heater. > >> Now you have a GPSDO with a much lower jitter PPS output. You need >> to write from scratch code for the CPU either way. The code for >> the GPSDO is probably simpler than the temperature control code. >> It?s certainly no more difficult. This way you have an output at >> what ever the TCXO frequency is for ?other stuff?. > >> Bob > > Thanks, Bob. I don't propose using temperature to control the GPS > clock. I plan to use a AD9912 DDS (1GHz 48Bit 4uHz 0.19ps > $59@Newark.) > >> On Mar 5, 2014, at 6:48 PM, Tom Van Baak <[email protected]> >> wrote: > >>> I agree with Bob. > >>> For casual use, "hanging bridges" are not really a problem, >>> statistically speaking -- so don't worry. > >>> Yes, you can apply various techniques to reduce/eliminate the >>> rare effect: forced temperature change, forced Vcc change, 2 or 3 >>> or more shared-antenna receivers, modulating phase, frequency, >>> voltage, temperature, etc. But as you spend too much time >>> engineering this uncertain hack you maybe start to wonder if the >>> real solution is just to apply known digital, numerical >>> correction instead of wishful analog cover-up. Been there, done >>> that. > >>> For more serious use, at the tens or unit nanosecond level, the >>> robust solution is simply to apply 1PPS sawtooth correction from >>> the receiver. > > The sawtooth error data is truncated at 1 ns. I would like to get > far below that error. > >>> This issue comes up every now and then as people gradually >>> transition from casual to serious use. I welcome any hard data or >>> plots that demonstrate the difference among all approaches. There >>> *is* a slight difference for sure. It's just that most people >>> throw in the towel and use sawtooth corrections instead of trying >>> to avoid them and cover up with less deterministic methods. > > Tom, > > Thanks for your reply. The sawtooth error correction is described in > "Timing for VLBI", by Tom Clark and Rick Hambly, at > > http://www.cnssys.com/files/tow-time2011.pdf > > John Ackermann shows graphs that compare the results in "GPS > Pulse-per-Second Comparative Noise", at > > https://www.febo.com/pages/gps_pps/ > > It appears the implementation of the sawtooth error correction > severely degrades the performance of the system. There could be many > reasons, which is why it is important to nail down as many of the > error sources as possible. > >>> /tvb > >> ----- Original Message ----- >> From: "Bob Camp" <[email protected]> >> To: "Discussion of precise time and frequency measurement" >> <[email protected]> >> Sent: Wednesday, March 05, 2014 3:03 PM >> Subject: Re: [time-nuts] Another "atomic" clock question > >> Hi > >> If you are going to decode and use the sawtooth data out of the >> receiver, there?s no need to eliminate the hanging bridges. The >> sawtooth data does that for you already. Put another way, heating >> the receiver is *harder* than just using the decoded data?. > >> Bob > > Thanks, Bob. I am not planning on heating the crystal. I want to > replace it with a precision DDS. > > The sawtooth data is truncated at 1ns. I want to do much better. > > Again, this is not intended as a quick-and-dirty fix. I would like > to separate out the error sources in a GPSDO and see what can be > done to improve the results. > > Thanks, > > Mike > _______________________________________________ > 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.
