Re: [Discuss-gnuradio] ramping down (tx_empy continued)

[Brett Trotter]

Brett Trotter wrote:
> 
> 
> Eric Blossom wrote:
>> 
>> On Tue, Jan 16, 2007 at 07:41:58AM -0800, Brett Trotter wrote:
>>> 
>>> I've been pondering a few ways to do the wait and ramp down (wait
>>> something
>>> like 16 clocks and then ramp down by right shifting on each clock)- but
>>> to
>>> do so, I need to know what the last value was so I can shift it. Will
>>> tx_i_*/tx_q_* remain persistent between clocks (my deduction was yes?)
>>> If
>>> so, my plan here was to have a reg that holds a 4-bit counter that
>>> starts at
>>> 15 whenever tx empty goes high/true and then just keep right shifting
>>> the
>>> appropriate value (based on load_next) until zero (or just keep shifting
>>> until data since 0 >> 1 = 0- would that save on logic?).
>> 
>> Brett, if you jam zero's into the front of the signal processing path
>> like you suggested in your first message, you don't have to ramp the
>> input down.  The interpolating filters will take care of the
>> discontinuity for you.
>> 
>> No need to make this hard.  I think your original code will work.
>> 
>>> Then I had one question- is there ever a situation where we're out of
>>> data
>>> for any number of channels, but there's still one transmitting (e.g. can
>>> tx_empty ever be asserted when we're feeding just one of the 4
>>> destinations?). I'm under the (mistaken?) impression that tx_empty
>>> asserts
>>> when we stop feeding the buffer altogether (underrun)- so without doing
>>> some
>>> digging- do we fill zero's to the channels we're not using when we're
>>> still
>>> feeding one of them?
>>> 
>>> With those answered, I think I can probably try and get a version done
>>> today
>>> for testing.
>> 
>> 
>> Eric
>> 
> 
> odd - my oscilloscope still showed a small sine wave (same as with
> original firmware) at the end of the benchmark_tx program's run- despite
> my altering the sink line to include fpga firmware. Perhaps my code did
> work but didn't load?
> 
> When I specified a full path, strace showed it was accessing
> /usr/local/share/usrp/rev2//usr/local/share/usrp/rev2/usrp_std.rbf, so I
> know it tried- and when I removed the path, it quit complaining so I
> presumed my bitstream loaded- yet as mentioned, the sine wave was still
> present. I'll give it another test today, and will be happy to provide my
> image to anyone else who wants to see if they see the same?
> 
> Thanks for your input, I'll let you know shortly.
> 
> Also, forgive me, I'm a terrible top-poster by habit and I'll try to
> bottom post from now on.
> 

Replying to myself- If I run the benchmark_tx like this:
address@hidden digital]# ./benchmark_tx.py -f 10e6 -r 100k -M .01
>>> gr_fir_fff: using 3DNow!
.......
when it terminates, I still see a ~40mV p-p sine wave (albeit somewhat
jagged).

If I do -M 10 instead and ctrl+c in the middle, the signal goes to zero as
expected.

What could be going on?
-- 
View this message in context: 
http://www.nabble.com/ramping-down-%28tx_empy-continued%29-tf3021634.html#a8395034
Sent from the GnuRadio mailing list archive at Nabble.com.