UHD: trouble configuring multiple RX channels reliably

GNU Radio
1

I’m kind of stumped here. I used to be able to do this with the gnuradio
interface but I can’t make it work with the UHD interface. Don’t know
if
I’m missing something in my code or there’s a bug in UHD.

I have two DBDRX rev2 boards on USRP1. I want to tune each receiver to
different RF frequencies. Based on the UHD example code, I did the
following:

uhd::usrp::multi_usrp::make(args) // works fine most times (see #3
below)
usrp->set_rx_subdev_spec(“A:0 B:0”) // Dboard A is ch 0, Dboard B is
ch 1
(right?)
usrp->set_rx_rate(rate) // for all channels. Works fine
usrp->set_time_now(…) // okay
for (ch=0; ch < 2; ch++) {
usrp->set_rx_freq(freq[ch], ch);
usrp->set_rx_gain(gain[ch], ch);
}
usrp->issue_stream_cmd(cmd);
usrp->get_device()->recv(…)

Now I do get two streams of IQ data at right sampling rate. But there
are
several issues I see:

  1. set_rx_gain() seems to apply the gain to the wrong channel sometimes.
    It
    changes from boot to boot. Based on signal strength I see, it also
    seems to
    use a wrong value on occasion. Sometimes I even get a signal that’s
    unrecognizable by my demod until I power cycle the device (this may be
    more
    of issue #2 or #3 below.)

  2. set_rx_frq() works okay (i.e. I can demodulate fine) if I set both
    ch’s
    to the same frequency, say f0. But as soon as I set them to different
    frequencies, say f0 and f1 for ch0 and ch1, respectively, it’s as if the
    f0
    setting is lost.

  3. General instability. When I restart my app with a different subdev
    spec
    such as “A:0” or no subdev spec for single channel operation, calls to
    set_rx_gain(f0, 0) or usrp::make() sometimes hangs. I have to power
    cycle
    the device to get going again.

It feels as though the subdev config in general is quite unstable
for my multi-channel setup or my code is missing something very basic.
When
I double check the freq and gain settings with the get functions, they
all
look fine though.

Any insights?

Thanks,

Michael

2

It feels as though the subdev config in general is quite unstable
for my multi-channel setup or my code is missing something very basic. When
I double check the freq and gain settings with the get functions, they all
look fine though.

Any insights?

It turns out that the RX mux was calculated in reverse. Effectively, the
channels were swapped. This would have been hard to notice on a pair of
boards with frac-N synthesizers, but with DBSRX, the DDC offset made it
noticeable. I pushed a fix to the master:

http://code.ettus.com/redmine/ettus/projects/uhd/repository/diff?rev=1e7227319cdf9098c6ddf344ad5bbd2c82ca2cda&rev_to=3dfdda7c82b65fe3acbdadcafde3e93e129345d2

Thanks,
-Josh

3

Thanks for the fix. I tested it on my USRP1 + 2 DBSRX system and it
seems
to work.

There are couple of remaining issue though.

  1. The instability problem is still there. If I keep restarting my app,
    USRP1 seems to come up in a state where I get either corrupted IQ signal
    (in
    what way, I don’t know. Sometime lower SNR, sometimes flat garbage) or
    one
    of the initialization UHD calls (multi_usrp::make, set_rx_freq, etc)
    just
    hang and require device power cycle. It doesn’t take many trials to hit
    this state. I don’t have this issue when I use the gnuradio framework.
    Note that I’ve been having this issue with E100 (w/ a RFX dboard) as
    well so
    I don’t think it’s a motherboard or DBSRX specific problem.

  2. The latest UHD repository master (4/27) seems to have a serious
    regression for E100. I get data samples coming in but expected signal
    is
    not there (or corrupted in serious way). As I replied to you in another
    thread, I saw this happen also with the “usrp_e100_frame_size2” branch
    you
    posted for me on 4/26 and merged to the master today. In any case, my
    E100-friendly UHD git version is from 4/19, so it looks like the
    regression
    happened at some point between then and now.

For now I will use the latest master for my USRP1 and keep the old one
for
E100. :slight_smile:

Michael

4

My bad. I misread the git revision log on the web site:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions
Somehow the frame size checkin showed up under “master”.

I will try out the reverse diff.

Thanks,

Michael

5

On 04/27/2011 10:10 PM, Michael Dev wrote:

Thanks for the fix. I tested it on my USRP1 + 2 DBSRX system and it seems
to work.

Cool!

  1. The instability problem is still there. If I keep restarting my app,
    USRP1 seems to come up in a state where I get either corrupted IQ signal (in
    what way, I don’t know. Sometime lower SNR, sometimes flat garbage) or one
    of the initialization UHD calls (multi_usrp::make, set_rx_freq, etc) just
    hang and require device power cycle. It doesn’t take many trials to hit
    this state. I don’t have this issue when I use the gnuradio framework.
    Note that I’ve been having this issue with E100 (w/ a RFX dboard) as well so
    I don’t think it’s a motherboard or DBSRX specific problem.

I havent seen the other stuff, but I have caught it hanging w/ two DBSRX
installed. Me thinks it is the FX2 not returning from an I2C
transaction. As soon as I thought I could reliably reproduce the problem
murphy’s law kicked in and I hadnt seen it again. This should be fun to
figure out…

  1. The latest UHD repository master (4/27) seems to have a serious
    regression for E100. I get data samples coming in but expected signal is
    not there (or corrupted in serious way). As I replied to you in another
    thread, I saw this happen also with the “usrp_e100_frame_size2” branch you
    posted for me on 4/26 and merged to the master today. In any case, my

I did not merge that into the master yet?

E100-friendly UHD git version is from 4/19, so it looks like the regression
happened at some point between then and now.

None of that changed in a serious way. But since you mentioned RFX, it
might be this change which involved moving the R divider of the RFX onto
the clock distribution: 1304340f269b6474a49970ee302e08ca9ed8d0ed

I cant test it now, but can you can try this reverse diff of the
changeset and see if that works?
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/905a681afd3b8d089a3dbfe7aa31bbcb5a020c05/diff?format=diff&rev_to=1304340f269b6474a49970ee302e08ca9ed8d0ed

-Josh

6

On 04/28/2011 02:54 PM, Michael Dev wrote:

Backing out that RFX change didn’t help.

Just so you know, I backed that change out of the master. The lower
clock rates do seem to cause an issue for me on RFX + E100. The change
was also introduced on the 19th which is when you said it last worked
for you. Can you try the master now? it really seems unlikely be
something else.

For what it’s worth, my USRP1 + RFX dboard setup doesn’t have the same
issue. Kinda says it’s an E100 issue, not RFX.

Unfortunately, The change wouldn’t effect USRP1 because it has no clock
dividers.

On your USRP1 issue. I found some reset registers that weren’t being
poked in UHD that were poked by gnuradio-usrp. The change didnt seem to
harm anything for me. Does this help with any of the flakiness you see?
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/show?rev=usrp1_init_resets

Thanks,
-Josh

7

Backing out that RFX change didn’t help.

For what it’s worth, my USRP1 + RFX dboard setup doesn’t have the same
issue. Kinda says it’s an E100 issue, not RFX.

Has anyone been able to use the E100 successfully with the current git
master?

Michael

8

-Josh

Thanks for your support.

Michael

Mixed results. The bad: It made things worse in that, for dual channel
rx, I
can get a clean signal for only once after power cycle – it never gives
me
a good signal if I restart my app. (For single channel rx, it restarts
fine.) The good: I haven’t encountered a hang during my brief test, so
it’s
possible the hang problem may have been mitigated with the patch.

Michael

9

On Thu, Apr 28, 2011 at 3:14 PM, Josh B. [email protected] wrote:

something else.

(MD) How is it different than what I tried per your suggestion
yesterday? I
took the master tip and backed out the RFX change using the reverse diff
for
that checkin. Isn’t it what the master tip is currently? Maybe I’m
missing
something here.

For what it’s worth, my USRP1 + RFX dboard setup doesn’t have the same
issue. Kinda says it’s an E100 issue, not RFX.

Unfortunately, The change wouldn’t effect USRP1 because it has no clock
dividers.

(MD) Oh, okay.

On your USRP1 issue. I found some reset registers that weren’t being
poked in UHD that were poked by gnuradio-usrp. The change didnt seem to
harm anything for me. Does this help with any of the flakiness you see?

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/show?rev=usrp1_init_resets

Thanks,
-Josh

(MD) OK, I will give a shot later. Please note that the flakiness is on
both
USRP1 and E100 whenever I use UHD. To recap and add a little more
detail,
the problem is that:

A: Restarting my app often gives me unrecognizable/dirty rx samples.
Once I
get a clean signal, it seems to stay that way until I happen to restart
my
app.
B: UHD config calls sometimes hang and I have to power cycle.

Thanks for your support.

Michael

10

On Thu, Apr 28, 2011 at 3:14 PM, Josh B. [email protected] wrote:

something else.

Whatever it was, the master as of last night
(76fb9508a9cb4cb45ef48af4bd3afb4ac507813b) seems to be working again for
my
E100+RFX. And it looks like the recv_frame_size support for E100 has
been
merged to the master as well. That’s nice.