Forum: GNU Radio if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

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:
https://github.com/gnychis/gnuradio-3.5.0-dmr/blob...

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

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...

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

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:
http://pastebin.com/KiR3e6j0

-josh

> 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:
> http://pastebin.com/KiR3e6j0
>

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

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

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