On Thu, Apr 12, 2007 at 06:07:01PM -0700, George Barrinuevo wrote: > Eric, > > I will try the 2 ctl-c method. Also, is there a > software reset command in GNURadio to recover from any > corruption? This can be a software initiated reboot > of the USRP or something similar. > > Thanks,
We can't get completely back to the power-on state from software, because there is some h/w state in the AD9862's that we can't write from s/w. When we open the USRP, we do rewrite all the registers that we can get at, so that's pretty close to a reset. There is also a long standing bug where in some cases the first few blocks of samples received from the USRP are semi-bogus. When the problem shows up, it's in the first 1024 complex samples. The problem is in the FX2 firmware. Larry Doolittle tracked it down a year or more ago for his UXO detector at LBNL, but the changes never made it back into our code base. Eric > --- Eric Blossom <[EMAIL PROTECTED]> wrote: > > > On Thu, Apr 12, 2007 at 02:03:11PM -0700, George > > Barrinuevo wrote: > > > I get strange results running my block. To > > resolve > > > this problem, I must unplug the DC power from the > > USRP > > > for 3 seconds and plug it back in. Is there a > > > GNURadio, C++, PYTHON command to reset the USRP > > > hardware so that I do not have to a hard power > > down > > > and up? > > > > > > I probably get these issues since ctl-c does not > > work > > > to cancel the GNURadio python code and therefore I > > > must use 'kill -9' instead which probably causes > > the > > > issue described above. > > > > > > Thanks, > > > > > > George Barrinuevo > > > [EMAIL PROTECTED] > > > > Try two control-C's > > > > Eric > > > > > George Barrinuevo > [EMAIL PROTECTED] _______________________________________________ Discuss-gnuradio mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
