discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Joseph Wamicha
Subject: Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
Date: Thu, 02 Sep 2010 09:36:25 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Hi,

Thank you. Tx/Rx on the old Flex2400 using the usrp2 is now working.


On 01/09/2010 21:41, Jason Abele wrote:
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




reply via email to

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