Re: [Discuss-gnuradio] grGPS Preliminary Schematic

[Martin Dvh]

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.

(Life would be so much easier if all the clocks on the usrp would first go 
through the fpga.
Which could then upconvert/divide/pll/override/combine any clock in verilog 
software.)

Greetings,
Martin


> I'm aware that this is a very weak signal system, which is why I'm 
> concerned about the phase noise. Since the Maxim Chip is a SOC, there 
> really isn't much to be done with respect to adjusting the noise budget 
> other than improving the Reference oscillator phase noise. An external 
> GPS Band Pass filter and LNA are about the only degrees of freedom 
> available.
>
>
> Dave