[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Brett Trotter
Subject: Re: [Discuss-gnuradio] ramping down (tx_empy continued)
Date: Tue, 16 Jan 2007 08:29:02 -0800 (PST)

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

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.
View this message in context: 
Sent from the GnuRadio mailing list archive at Nabble.com.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]