USRP2-FLEX2400 Transmit and Receive problems

GNU Radio
1

Hi,

We are currently experiencing Transmit and possibly Receive problems
with the USRP2-Flex2400 boards.

  • The USRP2 is detected:

find_usrps -e eth0

00:50:c2:85:32:73 hw_rev = 0x0400

  • The latest firmware and Raw Ethernet FPGA images have been written
    onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin

  • To test receive, we transmit a 2.4GHz, 10 dBm RF signal using the HP
    8350B Sweep Oscillator/Signal Generator. This is detected by both the
    USRP2-FLEX2400 (using usrp2_fft.py script) and Agilent Spectrum Analyzer
    (Please see screen shots attached). However, the usrp2_fft.py shows some
    odd sidebands around the the 2.4GHz central frequency when the signal
    generator is turned on.

  • Both LEDs D and F are lit up.

  • Gnuradio version 3.2.2 is being used on Ubuntu Lucid Lynx (10.04).

We then turn off the Signal Generator, and transmit a 2.4GHz signal
solely using the USRP2-FLEX2400 by running ‘usrp2_siggen.py -f 2.4e9 -e
eth0’. Nothing gets picked up by the Agilent Spectrum Analyzer
USRP2-FLEX2400.

Is there a USRP2-FLEX2400 transmit/receive problem while using the
latest firmware and raw ethernet FPGA code?

Thanks,
Jaw.

2

Hi,

We are currently experiencing Transmit and possibly Receive problems
with the USRP2-Flex2400 boards.

  • The USRP2 is detected:

find_usrps -e eth0

00:50:c2:85:32:73 hw_rev = 0x0400

  • The latest firmware and Raw Ethernet FPGA images have been written
    onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin

  • To test receive, we transmit a 2.4GHz, 10 dBm RF signal using the HP
    8350B Sweep Oscillator/Signal Generator. This is detected by both the
    USRP2-FLEX2400 (using usrp2_fft.py script) and Agilent Spectrum
    Analyzer. However, the usrp2_fft.py shows some odd sidebands around the
    the 2.4GHz central frequency when the signal generator is turned on.
    Also, there’s barely any difference in dB receive strength with the
    signal generator turned on:

usrp2_fft.py output when signal generator is off:
http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-Off.png
usrp2_fft.py output when signal generator is off:
http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-On.png

  • Both LEDs D and F are lit up.

  • Gnuradio version 3.2.2 is being used on Ubuntu Lucid Lynx (10.04).

We then turn off the Signal Generator, and transmit a 2.4GHz signal
solely using the USRP2-FLEX2400 by running ‘usrp2_siggen.py -f 2.4e9 -e
eth0’. Nothing gets picked up by the Agilent Spectrum Analyzer
USRP2-FLEX2400.

Is there a USRP2-FLEX2400 transmit/receive problem while using the
latest firmware and raw ethernet FPGA code? Could this be the symptoms
of an SDRAM problem even if both LEDs D and F are lit up?

Thanks,
Jaw.

3

Hi,

  • I’m now using the uhd firmware and fpga code (txrx_uhd_20100706.bin
    and u2_rev3_uhd_20100706.bin images).

  • I get some interesting results; when running the examples, it appears
    that the daughterboard can not be recognized and is unknown.

  • I’m not sure if this in any way will affect the results but due to
    firmware/fpga incompatibilities between the host machine code and the
    firmware & fpga code (Error: Expected fpga compatibility number 1, but
    got 0:), I changed USRP2_FPGA_COMPAT_NUM and USRP2_FW_COMPAT_NUM to 0
    and 5 from 1 and 6 in host/lib/usrp/usrp2/fw_common.h.

I was then able to run the host/examples code. The code is straight out
of the repository. Please find the results below:

root@astrodonius:git-uhd/host/examples# ./benchmark_rx_rate

Creating the usrp device with: …
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

OTesting receive rate 0.500000 Msps (10.000000 second run)

 Received packets: 13813
 Received samples: 5000306
 Lost samples: 0
 Lost packets: 0 (approximate)
 Sustained receive rate: 0.500000 Msps

Testing receive rate 1.000000 Msps (10.000000 second run)

 Received packets: 27625
 Received samples: 10000250
 Lost samples: 0
 Lost packets: 0 (approximate)
 Sustained receive rate: 1.000000 Msps

Testing receive rate 2.000000 Msps (10.000000 second run)

 Received packets: 55249
 Received samples: 20000138
 Lost samples: 0
 Lost packets: 0 (approximate)
 Sustained receive rate: 2.000000 Msps

Testing receive rate 4.000000 Msps (10.000000 second run)

 Received packets: 110498
 Received samples: 40000276
 Lost samples: 0
 Lost packets: 0 (approximate)
 Sustained receive rate: 4.000000 Msps

Testing receive rate 8.333333 Msps (10.000000 second run)

 Received packets: 230203
 Received samples: 83333486
 Lost samples: 0
 Lost packets: 0 (approximate)
 Sustained receive rate: 8.333333 Msps

Testing receive rate 16.666667 Msps (10.000000 second run)

 Received packets: 460190
 Received samples: 166588780
 Lost samples: 78192
 Lost packets: 216 (approximate)
 Sustained receive rate: 16.658847 Msps

Testing receive rate 25.000000 Msps (10.000000 second run)
./lib/usrp/usrp2/fw_common.h
Received packets: 683928
Received samples: 247581936
Lost samples: 2418160
Lost packets: 6680 (approximate)
Sustained receive rate: 24.758184 Msps
Done!

root@git-uhd/host/examples# ./rx_timed_samples

Creating the usrp device with: …
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

Setting RX Rate: 6.250000 Msps…
Actual RX Rate: 6.250000 Msps…
Setting device timestamp to 0…

Begin streaming 1000 samples, 3 seconds in the future…
OGot packet: 362 samples, 3 full secs, 0.000000 frac secs
Got packet: 362 samples, 3 full secs, 0.000058 frac secs
Got packet: 276 samples, 3 full secs, 0.000116 frac secs

Done!

root@astrodonius:git-uhd/host/examples# ./tx_timed_samples

Creating the usrp device with: …
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

Setting TX Rate: 6.250000 Msps…
Actual TX Rate: 6.250000 Msps…
Setting device timestamp to 0…

Sent 1000 samples

Done!

root@astrodonius:git-uhd/host/examples# ./tx_waveforms

Creating the usrp device with: …
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

Setting TX Rate: 6.250000 Msps…
Actual TX Rate: 6.250000 Msps…

Setting TX Freq: 0.000000 Mhz…
Actual TX Freq: 0.000000 Mhz…

Setting TX Gain: 0.000000 dB…
Actual TX Gain: 0.000000 dB…

Done!

There’s a machine in the lab with an ISE license so I’m not sure if this
is

4

The RFX2400 is dated 2/6/2006.

5

You are using a very old RFX2400 which is configured with its own
onboard oscillators instead of using the master oscillator from the
motherboard. You can reconfigure it to work with USRP2 by following the
directions under “Synchronizing all daughterboard LOs” here:

http://gnuradio.org/redmine/wiki/1/USRPClockingNotes

Matt

6

On 08/31/2010 01:48 PM, Joseph Wamicha wrote:

Hi Leech,

Thank you for your response. I’m using 2.4 GHz characterized antennas.
No I’m not feeding the signal directly into the USRP2. I have a 2.4GHz
resonant monopole antenna on the signal generator and another 2,
2.4GHz resonant antennas on both the RX and TX/RX SMA connectors of
the FLEX2400.

How close are the antennae?

What parameters did you pass to usrp2_fft.py? If you look closely at
the spectrum, it looks
perfectly symmetrical about DC, which should never be the case if
all the “pieces” agree
that this is a complex signal.

What happens if you tune usrp2_fft.py a few Khz away from 2.4GHz
exactly?

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

7

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:

/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

8

Hi Marcus,

I get exactly the same behaviour. I have finally traced the problem to
an old Flex2400 using an internal clock rather than the usrp2 clock.
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

9

On Wed, Sep 01, 2010 at 03:08:53PM -0400, Marcus D. Leech wrote:

http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1
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

10

Hi,

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

11

On 09/01/2010 12:51 PM, Jason A. wrote:

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…

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium