Hi Magnus, on our Fury system the phase relationship between the 1PPS (clean OCXO version) and the 10MHz is established during power-on, then held stable (it is generated by the same 10MHz crystal) unless it for some reason drifts more than +/-220ns away from UTC at which point it is reset to UTC, or until it is changed by user-command. We do also have the raw GPS 1PPS available (jumper selection option) which is asynchronous to the 10MHz, and as you mentioned will drift since it is generated by a separate crystal, and clocking system. One could use two or three cascaded FF's two avoid the setup/hold/metastability issues, then set the phase via software command so as to compensate for the FF-induced phase delays. You are right, there are so many ways to cross that river :) bye, Said In a message dated 12/12/2008 15:16:00 Pacific Standard Time, magnus@rubidium.dyndns.org writes: You really can't sync up some PPSes to the 10 MHz by simple DFFs since the variations may be more than 100 ns during some phases of the training and holdover shifts. The PPS output should always be generated using the 10 MHz such as they have a stable phase-relationship. The generated PPS is then compared to the source PPS and controlled phase adjustments should be done. Cheers, Magnus

SAIDJACK@aol.com skrev: > Hi Magnus, > > on our Fury system the phase relationship between the 1PPS (clean OCXO > version) and the 10MHz is established during power-on, then held stable (it is > generated by the same 10MHz crystal) unless it for some reason drifts more than > +/-220ns away from UTC at which point it is reset to UTC, or until it is > changed by user-command. This is indeed reasnoble. Depending on your application you may have some maximum frequency offset as well as maximum time offset. These can result in unnecessary long drift back times, so just jump in to the nearest 10 MHz cycle and glide in from there makes sense. > We do also have the raw GPS 1PPS available (jumper selection option) which > is asynchronous to the 10MHz, and as you mentioned will drift since it is > generated by a separate crystal, and clocking system. Indeed. As expected. > One could use two or three cascaded FF's two avoid the > setup/hold/metastability issues, then set the phase via software command so as to compensate for > the FF-induced phase delays. Indeed. > You are right, there are so many ways to cross that river :) Certainly. As there is no standard of how this interface can be done, expect that almost any inconceivable way have been used. What is "obvious" to you may not be obvious to another, infact it could be viewed as contra-productive or comes at excess cost. Cheers, Magnus