[time-nuts] GPS-disciplining an ordinary VCXO?

[SAIDJACK at aol.com]

Mark,
 
typical GPS receivers do not lock their crystal to anything, they just use  
a free-running one. Please search the archives for "TVB hanging bridges"  
discussions to get good details on that phenomenon. The Trimble Thunderbolt 
is  one example of a unit that does lock its oscillator to the GPS system as  
discussed here before also.
 
Yes, the Ettus B200 has a GPSDO in it that I am familiar with,  and that 
one has an OCXO. Looks like they are using a 4KHz loop BW on  that Ettus 
schematic. As discussed before if you want to use something as noisy  as a NEO 
10MHz output you will want a loop bandwidth smaller than 1Hz. Heck I  would 
not be surprised if the Analog Devices PLL cannot even lock properly to  the 
NEO 10MHz output reference due to all that phase jumping.
 
At this point I would suggest for you to try out stuff, see where it leads  
you, then report your results here so we can try to point you in one 
direction  or another and try to offer our help..
 
Bye,
Said

 
 
In a message dated 9/29/2014 12:54:52 Pacific Daylight Time,  
haunma at keteu.org writes:

Hi  Said,

I suspect somewhere between 1 and 10 ns is easily achievable  inside the
FPGA.  I am curious about the sawtooth though.  The  standard explanation is
that the timepulse output (1 PPS or 10 MHz or  whatever it happens to be)
does not "line up" with the master  oscillator.  Do typical GPS modules lock
their VCO or TCXO based on  the position/time solution, or not?  Seems like
this could all be  avoided (sawtooth etc) if they did.

You will probably be dismayed to  hear that I already have a pile of those
cheap 26-MHz Pletronics OCXOs just  sitting on my desk :)  But I really need
to focus on the radio aspects  of this project.  If it goes well there will
probably be a board spin  anyway, and I can re-evaluate at that time.  I
guess you have in mind  something like the Ettus  B200:
http://files.ettus.com/schematics/b200/b200.pdf
(Here he is  locking a VCTCXO to a GPSDO module which I assume has an  OCXO
inside.)

Mark

SAIDJACK at aol.com [SAIDJACK at aol.com]  wrote:
> Hi Mark,
>  
> yes, the PLL is there to remove  any tempco of the system and all error  
> sources etc, so you  don't have to individually quantify the errors. That 
is the 
>   nice thing about loops. You only need a good model if you have to work  
in  
> holdover without GPS disciplining.
>  
>  You will need a phase detector with nanosecond resolution preferably,  
but  
> even 10ns resolution works just fine considering most GPS  have sawtooth 
> errors  larger than that. Take a look at the PID  wiki to get some idea 
of how to 
> program  the loop and assure  sufficient phase-margin for stability, and 
how 
> to  heuristically  calibrate the loop constants. After that theory goes 
out 
> the  door  and it is time for experimentation because every system will 
be  
> different, even  if you use the exact same type of  parts.
>  
> I still think you should discipline a nice OCXO,  then phase lock the  
> Crystek part to that OCXO rather than  trying to discipline the VCXO 
directly. It  
> won't add too much  complexity to the board.
>  
> Good luck,
>  bye,
> Said
>  
>  
> In a message dated  9/29/2014 11:42:18 Pacific Daylight Time,  
> haunma at keteu.org  writes:
> 
> Hi  Said,
> 
> Didn't want to tie up  the list any more with this, but wanted to  say 
thanks
> for your  help.  If I were a real electronics guy designing  this for a  
real
> product, we'd probably be considering one of your   parts!  Instead I'm a
> theory guy with mostly   research/algorithms/software experience, so yes, 
> this
> is  totally a one-off  for me.  Just a learning experience.
>  
> 
> 
> Anyway, back to the  PFD, I wasn't sure how I  would get numbers out of 
it to
> stuff into a  filter, but if it is  running ~ 10^6 times faster than the
> filter output,  maybe it is  enough to filter the 1-bit directly.
> 
> BTW, wouldn't the   control loop null out any DAC temperature coefficient 
in
> the same way  that  it tracks the tempco of the VCXO?  I suppose the 
issue  is
> that the DAC  tempco, multiplied by the VCXO control gain,  could dwarf 
the
> uncontrolled  VCXO tempco?  The VCXO gain is  about 25 ppm/V and its main
> tempco is ~  300 ppb/C, equivalent to  a DAC tempco of 12 mV/C, which is
> pretty awful for  a  DAC.
> 
> (The CVHD-950, by the way, does not specify a tempco on  the data  sheet
> or provide a graph; these numbers are from the  Abracon  ABLNO-V-xxx.)
> 
> Thanks again,
> 
>  Mark
> 
> 
> SAIDJACK at aol.com  [SAIDJACK at aol.com]  wrote:
> > Hi Mark,
> >  
> > that  really  is up to you and your skill-set. I don't use FPGA's in 
>  products 
> >   anymore because they are not  field-serviceable generally, expensive, 
> >  usually   require some sort of recurrent registration of the compiler, 
>  the  ones I 
> > like  have external program storage so are  not easily  protected 
against 
> > theft, and are  not  needed if you have a good  Microcontroller and a 
> handful of  
> > discrete gates. I  do use PLD's  from time to time to  do simple 
dividers 
> etc.
> >  
> > But   integrating everything into an FPGA for a one-off if you are 
versed 
>  at   
> > programming them and know how to do IIR and FIR  filters etc is a  
> completely 
> >  different  story.
> >  
> > Lastly,  there is no need to  generate a DC signal with a 1-bit DAC  
> >  (sigma-delta,  PWM etc) for a one-off design since there are very good 
 
>  and  low-cost 
> > 12 bit or 16 bit DAC's available. I would use  two  cheap 12 bit DAC's  
> (SPI 
> > or better I2C)  cascaded to give me 20+  bits equivalent DAC 
resolution.  
>  Don't 
> > forget that the DAC  reference is just as important  as the DAC, maybe 
> even  
> > more so  for  applications that will see larger temp variations.
> >  
>  >  As I said before we have discussed this subject on numerous  
occasions   
> over 
> > the last decade in very  great detail, you may want to search and  read 
 
> >  through the archives - there is great detail on all of the   above.
> >  
> > Nowadays you can get a great 10MHz  OCXO on Ebay  for $10, buy a  
> > PLD/FPGA/Micro eval  board for less than $30, and  add a DAC and some 
> low-pass   filtering 
> > and voltage reference for  probably less than  $10. So you can do a  
> > complete, high-end  double-oven  GPSDO for around $50.. Adding the 
Crystek 
> VCXO  onto 
>  >  an Analog Devices PLL eval board would give you the desired   
> high-frequency,  
> > low phase noise output.
>  >  
> >  bye,
> > Said
> >   
> >  
> > In a message dated  9/29/2014 10:36:14  Pacific Daylight Time,  
> > haunma at keteu.org   writes:
> > 
> > Said,  would you suggest implementing  the  dividers and PFD in the 
FPGA, 
> > along
> >  with  the digital  filtering?  Or feeding the FPGA with some  version 
of  
> the
> >  PFD output?  I am trying  to avoid an extra A/D step here, but I   
have no
> >  experience with it.  Post-filter, I am satisfied that a   simple  
one-bit 
> D/A
> > with passive filtering will get  me to 16 bits  resolution for  the VCXO
> > control, enough  for ppb  resolution.
> > 
> > Thanks for the data   point on the vcxo  thermal sensitivity; it's very 
 
> >  useful!
> > 
> >  Regards,
> > 
> >  Mark
> > 
> > Said Jackson  [saidjack at aol.com]   wrote:
> > > Stephane, you will need to  replace the analog  low-pass filter  that 
> > follows
> > >  the  phase comparator with a digital low pass filter to  get 0.1Hz 
or   
> lower
> > > loop bandwidth.  This is what a  GPSDO   does.  A simple PID loop is 
what
> > >  accomplishes this   typically.
> > [...]
> > >  On the thermal sensitivity of that  Crystek vcxo:  it is slow enough 
 for
> > > even a loop with 0.1Hz  BW to compensate for  it  easily if you 
shield 
> the
> > > crystal   from  airflow.
> > 
>