On Mon, Apr 12, 2010 at 15:27, John Orlando <j...@epiq-solutions.com> 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. Johnathan _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio