If uhd_transmitter instantiated after receiver, TX works, otherwise RX works

aris · June 14, 2012, 10:12pm

Hi all,

I’m observing some odd behavior that I can’t seem to figure out. This
is
in (your favorite script) tunnel.py

Here, self.sink is instantiated as a uhd_transmitter() and then
self.source
is a uhd_receiver(). Both are connected respectively to their part of
the
flow graph:

github.com

gnychis/gnuradio-3.5.0-dmr/blob/b3b9be2380553706f152fbf4ffee6804aef8525c/gr-digital/examples/ofdm/tunnel.py#L54


      
          from uhd_interface import uhd_transmitter
          from uhd_interface import uhd_receiver
          
          
import os, sys
          import random, time, struct
          
          
# /////////////////////////////////////////////////////////////////////////////
          #                             the flow graph
          # /////////////////////////////////////////////////////////////////////////////
          
          
class my_top_block(gr.top_block):
              def __init__(self, callback, fwd_callback, options):
                  gr.top_block.__init__(self)
          
          
	
                  self.sink = uhd_transmitter(options.args,
                                              options.bandwidth,
                                              options.tx_freq, options.tx_gain,
                                              options.spec, options.antenna,
                                              options.verbose)

The weird thing that I am observing is that whichever (uhd_transmitter
or
uhd_receiver) is instantiated last is the part of the flow graph that
operates properly. If the receiver is instantiated last, the receiver
is
able to receive packets (from another device) without a problem, but the
transmitted packets are unable to be decoded by a standalone receiver (a
different device running a receiver only). It is actually transmitting
(we
see power out of the antenna), but whatever it is transmitting is
undecodable by our receiver.

If you instantiate the transmitter before the receiver, then the
transmitter works just fine and our standalone receiver can receive its
packets. But, this breaks the uhd_receiver() running on the
transceiving
device.

Has anyone else observed this? I have double checked that both are
setting
the sampling rates, independent of which is instantiated first
(bandwidth
is the same)… so I’m a little confused what would make the difference
here.

Thanks a bunch!

George

george_n · June 18, 2012, 12:14am

A little more information about this…

The UHD version is 003.004.000-322fb97.
Daughterboard: xcvr2450
usrp: n200

Interestingly, what seems to break things is the call to set_freq(). If
I
comment out the set_freq() in the instantiation of the receiver, the
transmitter will work. If I comment it out in the instantiation of the
transmitter, the receiver will work. This is despite both calls to
set_freq() taking the same frequency. This must trigger whatever tuning
is
happening that breaks the opposing chain.

Trying a newer version of UHD now…

george_n · June 18, 2012, 2:22pm

hi George,
I noticed theses odd things several months ago. I am using USRP2s with
XCVR2450. Since my UHD was upgraded to 003.004.000 or newer version, my
USRP2s can’t work in half duplex mode. When uhd_transmitter is
instantiated later than uhd_receiver, tx works well but rx can’t receive
packets. When uhd_receiver is instantiated later than uhd_transmitter,
rx could receive packets, but tx works with abnormal spectrum.

Now I have to use an old version (003.003.002) UHD. With this version,
both tx and rx work well. So I doubt that there is a bug in version
003.004.xxx. Maybe Ettus can help us fix it.
King Qiu

george_n · June 18, 2012, 7:53pm

Thanks for the tip. I think I figured it out.

The property to use an LO offset was true for TX and not RX. This would
mean that tuning an individual chain and using it would be fine; but
since there is a shared LO, the offset would not be compensated for by
the DSP on the chain in the other direction, hence, it not working.

If you dont mind trying, here is a simple 1 liner patch:
diff --git a/host/lib/usrp/dboard/db_xcvr2450.cpp b/host/lib/usrp/dboard/db_xcvr - Pastebin.com

Another quick way to test this without the patch would be to tell the
tune request to use an LO offset of 0. Example:

usrp_source/sink.set_center_frequency(uhd.tune_request(my_freq, 0))

-josh

george_n · June 18, 2012, 10:00pm

Hi Josh,

Thanks a bunch for these pointers/patches and looking in to it! We are
currently testing them out, shouldn’t take long. However, we did verify
that reverting to the older version (003.003.002) did work for us as it
did
for King (thanks!).

Stay tuned… we’ll let you know ASAP.

George

george_n · June 19, 2012, 6:28am

Your attached patch also fixes the problem! Thanks a bunch for helping
narrow down this issue

george_n · June 18, 2012, 7:42pm

On 06/18/2012 05:21 AM, King Qiu wrote:

003.004.xxx. Maybe Ettus can help us fix it.
King Qiu

Thanks for the tip. I think I figured it out.

The property to use an LO offset was true for TX and not RX. This would
mean that tuning an individual chain and using it would be fine; but
since there is a shared LO, the offset would not be compensated for by
the DSP on the chain in the other direction, hence, it not working.

If you dont mind trying, here is a simple 1 liner patch:

-josh