discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD: trouble configuring multiple RX channels rel


From: Josh Blum
Subject: Re: [Discuss-gnuradio] UHD: trouble configuring multiple RX channels reliably
Date: Wed, 27 Apr 2011 22:44:35 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8


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

> 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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]