Re: [Discuss-gnuradio] What does the USRP transmit after I've done tx->stop.

[Eric Blossom]

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