Problem with USRP/FFT sink in GRC

Hi,

I am running a simple graph in GRC-0.65 with complex USRP as source
(with TVRX at the B side) and a complex FFT as a sink.
What I see is not expected: I see the FFT of a real signal
(symmetric around 0).

When I run the python example usrp_fft.py I get
the expected result.
./usrp_fft.py -RB -f 93.1e6 -d 16

I attach the grc graph for anyone who wants to take a look at it
and give me some hint as to what I might be doing wrong.

Thanks
Achilleas

I too am having an issue with GRC or gnu radio…

You see, version 0.60 could not transmit on side B because I was doing
this:
u.tune(0, subdev, freq), but the txrx could receive on side B.

In version 0.65 I switched the code to u.tune(subdev._which, subdev,
freq).
Now the A/B transmit works. Just today, I discovered that the tvrx on
side B
will send out “peculiar” signals until I change the subdev._which back
to
zero.

So I am not sure if this is a bug, a feature, or If am tuning this
wrong. I
am using USRP rev3 and month-recent version of the trunk.

How do I tune the USRP for receiving on side A?
How do I tune the USRP for receiving on side B?
How do I tune the USRP for transmitting on side A?
How do I tune the USRP for transmitting on side B?

-Josh

Or in other words…

To tune the transmitter on sideA : u.tune(0, subdev, freq)
To tune the transmitter on sideB : u.tune(1, subdev, freq)

But to tune the receiver for either side : u.tune(0, subdev, freq)

Is this correct? Is this they way all boards work?

-Josh

On Mon, Apr 30, 2007 at 08:28:54PM -0400, Josh B. wrote:

Or in other words…

To tune the transmitter on sideA : u.tune(0, subdev, freq)
To tune the transmitter on sideB : u.tune(1, subdev, freq)

But to tune the receiver for either side : u.tune(0, subdev, freq)

Is this correct? Is this they way all boards work?

Yes. Yes.

FWIW, the asymmetry is a result of the use of the upconverter in the
AD9862. In the receive case, the first argument specifies which DDC
you want to mess with. Because of how the the RX mux works, the DDC
assignment is completely orthogonal to the selection of ADCs.
However, on the Tx path, the DUC is actually in the AD9862 that is
wired to the specific daughterboard slot.

Yes, I know it’s ugly. There’s probably a better way to handle this.
If anyone wants to sort it out, please go ahead. We could implement
the change without breaking any existing code by creating a new
interface, say u.tune2. If anyone does look at this, be sure to
consider the behavior of the multichannel case.

Eric