On Fri, Apr 25, 2008 at 09:21:18AM -0700, Dan Halperin wrote: > I don't know how relevant this is, but I have fixed similar problems > in the past by making sure that the host app sends data that's an even > multiple of 512 bytes. (This is harder than you think :)) > > I found that if you send a number of sample bytes equivalent to 1 same > mod 512 bytes, for instance, the last sample is repeated for some time > and can be observed as a short pilot tone. I never did too much > digging into this, however -- I just modified the transmitting app to > pad. > > -Dan > > On Apr 25, 2008, at 7:31 AM, George Nychis wrote: > > > > > > > Per Zetterberg wrote: > >> Hi All, > >> I am transmitting a stream of buffers from the USRP (based on > >> libusrp with > >> standard .rbf file). After I've done tx->stop (where tx is a > >> pointer to > >> usrp_standard_tx) it seems that the USRP is repeating the last > >> transmitted > >> buffer (or couple of buffers ?). Is this correct ? > > > > > > Continually, until you unplug the board? If so, I've noticed this > > behavior too as of recent... I used to be able to replicate it 100% > > of the time, but haven't tried for a couple weeks. > > > > Are you using the current GNU Radio trunk? > > > > - George
I believe what is happening is that the transmit path is being disabled in the FPGA before the zeros that get shoved into the head of the DSP pipe when it underruns propagate through the pipeline. Thus it's stuck with a non-zero constant feeding the DACs. When run through any of the d'boards with an LO, the constant turns into a carrier at RF. I think the right way to fix this is to have a "decay to zero" module right before the DACs that is controlled by a delayed copy of the tx_enable signal (I may have the signal name wrong... This is from memory) Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
