discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] usrp2_fft.py and changing the gain


From: John Orlando
Subject: Re: [Discuss-gnuradio] usrp2_fft.py and changing the gain
Date: Tue, 13 Apr 2010 16:09:29 -0500

On Tue, Apr 13, 2010 at 1:54 AM, Johnathan Corgan
<address@hidden> wrote:
> On Mon, Apr 12, 2010 at 15:27, John Orlando <address@hidden> wrote:
>
>> However, as soon as I try to change the gain via the usrp2_fft.py GUI,
>> I get an 'O' character spit out on the USRP2's serial port, and the
>> GUI completely freezes.  I then have to do a manual exit from
>> the GUI window to get back to a cmd prompt, and can re-launch things from 
>> there.
>
> What you are seeing is a known bug with the current design of the
> USRP2 firmware.  The internal gain calculations for the DBSRX by the
> microcontroller take too long for the polling loop to keep up with the
> state machine transitions.  When this happens, I find that I can
> usually change the frequency via the GUI and the receive stream will
> start again.
>
> The solution to this is to go either go to a fully interrupt driven
> firmware design, and/or to move the daughterboard code back out of the
> firmware and onto the host like USRP1.  I believe both of these things
> are happening in the Ettus Research UHD driver design, but I am not
> certain.

Thanks for the insight Jonathon.  I was doing some testing with our
BURX board as well, and got the same GUI freezing result.  The gain
calculations for our board is trivial, so I wouldn't think that it is
a matter of time being consumed doing these calculations.  However,
both the DBSRX and the BURX board use an I2C interface to communicate
from the host to the daughterboard.  So I wonder if it is really just
a matter of the aeMB getting held up doing the I2C transaction.  But
if this were the case, I'd think _any_ I2C communication would cause
the freeze (such as changing the center frequency, which also happens
over I2C).  And changing the center frequency works just fine on both
boards.

Hmm...may not be worth much investigating with UHD coming soon,
assuming this fixes this.  I guess it'll just be a head-scratcher for
now.

Thanks again...
-- 
Regards,
John Orlando
CEO/System Architect
Epiq Solutions
www.epiq-solutions.com




reply via email to

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