Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems

[Jason Abele]

On Wed, Sep 01, 2010 at 03:08:53PM -0400, Marcus D. Leech wrote:
> On 09/01/2010 12:51 PM, Jason Abele wrote:
> >>I'll need to do some re-soldering and burn-db-eeprom with USRP1 and 
> >>hopefully this
> >>should fix the problem:
> >>http://gnuradio.org/redmine/wiki/1/USRPClockingNotes
> >Also, since you use UHD, you can change the daughterboard ID of a
> >daughterboard on a USRP2 from your host PC using:
> >
> ><prefix>/share/uhd/utils/uhd_burn_db_eeprom
> >
> >An example of changing the DBID for a DBSRX is show here:
> >http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1
> >
> >
> >Jason
> >
> >
> So, Jason, is this because the older FLEX-series boards used an
> on-board clock that is
>   *different* than the one supplied by the USRP2, and the driver code
> (either Classic or
>   UHD) assumes a different clock rate than the one that was
> previously on-board, and thus
>   is mis-programming the PLL?
> 
> If the two clocks are the same frequency, then I don't understand why
> changing from
>   "clock supplied on-board" to "clock supplied by USRP2" would "fix"
> the problem.
>   Inquiring minds want to know...


There are two problems:

1. When daughterboards were built with onboard oscillators, they were
all 64MHz (presumably to play nicely with the USRP1 64MHz oscillator),
but the USRP2 uses a 100MHz reference.  Thus, when the daughterboard
driver tunes the synthesizer, it is presuming a 100MHz reference on the
USRP2 (actually, the UHD daughterboard drivers ask the motherboard what
clock reference frequencies it can provide, and then chooses the "best"
option), thus it would misconfigure the RFX synthesizer because it would
not know that the reference frequency was 64MHz.

2. Actually, it never gets to mistuning the synthesizer because we used
the daughterboard id to separate the "MIMO B" version of the RFX (ie.
uses refclock from USRP motherboard) from the non-MIMO versions (with
oscillator on board).  However, the USRP2 (using either raw ethernet or
UHD drivers) does not implement the daughterboard control for the
non-MIMO versions.  Hence why the burn_db_eeprom command is needed to
change the daughterboard id.

I put an issue in our issue tracker to add a warning to the UHD code and
some notes in the daughterboard documentation to let users know about
converting non-MIMO versions of the RFX to MIMO versions, I expect the
fix will roll into one of the next few releases.

Jason