Re: [Discuss-gnuradio] grGPS Preliminary Schematic

[David Bengtson]

Martin Dvh wrote:
> David Bengtson wrote:
> > On 4/6/06, *Robert W McGwier* <address@hidden 
> > <mailto:address@hidden>> wrote:
> >
> >     David Bengtson wrote:
> >      > Martin Dvh wrote:
> >      >> Why don't you use the usrp to generate your 16.384 or 32.768 MHz
> >      >> refclock.
> >      >> Most daugterboards (except the tvrx) use this feature (They all
> >     use a
> >      >> 4Mhz refclock on io pin 0.
> >      >> The only difference with your design is that you need another
> >     frequency.
> >      >> The cyclone fpga in the usrp has internal PLLs which can
> >     generate all
> >      >> kinds of frequencies.
> >      >> (They are not used at the moment)
> >      >>
> >      >
> >      > (Sorry, there is a typo, the reference frequencies are
> >     16.368/32.736 MHz)
> >      > That might work. 16.368 MHz/4 MHz is 1023/250, or a comparison
> >      > frequency of 16 kHz. From a frequency generation point of view, I
> >      > could probably get the right frequency from the USRP
> >      > I'm concerned about jitter and noise on that line though. The
> >      > reference is used directly for the comparison frequency in the
> >     on-chip
> >      > PLL, to generate a LO that is 1571.328 MHz. A 16 kHz
> >     The generation of 1571.328 from this source is almost surely a deal
> >     killer because of the phase noise.   That LO must be accurate, 
> > stable,
> >     and as phase noise free as possible.  We are trying to work with a
> >     signal of only a few dB dynamic range signal and it is weak, right at
> >     the noise floor in most systems.  Cascaded LNA's will bring the 
> > signal
> >     up but also lower the IP3 and the dynamic range and greatly increase
> >     the
> >     front end susceptibility to overload, interference, and collapse.  
> > This
> >     particular oscillator and the attendant mixer cannot be scrimped 
> > on.  At
> >     least do a serious noise budget analysis to make sure the system will
> >     actually be usable after built.
> Just to clear things up about the fpga.
> The 4Mhz refclock is generated using our own code in the fpga by 
> dividing 64 Mhz by 8.
> You can use the internal PLL to generate other frequencies, or ose other 
> divide factors.
> You can also code your own (fractional) divider (like the rational 
> resampler) to generate other frequencies without adding phase noise.
> You still keep the original phase noise the 64 Mhz clock on the usrp 
> board has.
> The 64Mhz clock is generated with a TCXO but I don't know the phase 
> noise specs (ask Matt).
> You could also opt for using the 32.736 Mhz signal on your board as the 
> clock for the entire usrp.
> Just export the 32.736 on a SMA header and modify the usrp to use J2001 
> as clock input.
> This does mean modifying the hardware of the usrp which will put most 
> people off off using this.
>
> You can also run the fpga from the 32.736 Mhz clock when you input it 
> through the normal daughterboard IO.
> This means modifying the fpga code (not the hardware) and you cannot use 
> the AD/DA's on the usrp board anymore since they are hardwired to the 
> usrp clock.
> (Which will allways be 64 Mhz without hardware modifications)
> This will however be no problem for this application since the gps chip 
> has its own AD.

Right now, I have the Reference clock from the 2475 coming out through 
an internal buffer and then to an SMA connector. I based this on some 
conversation that I had with Matt 6 month's ago or so. My intent was to 
run the FPGA from that signal.

Some of the other comments have made me think that perhaps I should 
instead hook the Reference output to a regular I/O pin on the FPGA so 
that some adventurous souls could run multiple things from this. I'm 
primarily a hardware guy, so I'm not sure the best way from a software 
point of view.

My opinion is that having the Reference clock come from the FPGA is a 
bad idea from a phase noise/spurious point of view, and I'm going to 
keep the reference clock on board.

Dave