[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] grGPS Preliminary Schematic

From: David Bengtson
Subject: Re: [Discuss-gnuradio] grGPS Preliminary Schematic
Date: Thu, 06 Apr 2006 18:51:33 -0400
User-agent: Thunderbird 1.5 (Windows/20051201)

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
     >> 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
     > 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
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]