Ramping down (tx_empy continued)

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?).

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.

View this message in context:
http://www.nabble.com/ramping-down-(tx_empy-continued)-tf3021634.html#a8392238
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Eric B. wrote:

at

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.

View this message in context:
http://www.nabble.com/ramping-down-(tx_empy-continued)-tf3021634.html#a8393168
Sent from the GnuRadio mailing list archive at Nabble.com.

Brett Trotter wrote:

do so, I need to know what the last value was so I can shift it. Will
like you suggested in your first message, you don’t have to ramp the
asserts

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:
[root@localhost 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-(tx_empy-continued)-tf3021634.html#a8395034
Sent from the GnuRadio mailing list archive at Nabble.com.

On Tue, Jan 16, 2007 at 09:54:00AM -0800, Brett Trotter wrote:

an additional note- tested with the original firmware and ctrl+c’ing still
leaves the sine-wave, with my new firmware, it goes away as desired…

Good.

I remain perplexed as to why letting the program end normally results in the
tx_empty not happening or the clock stopping or whatever is causing the
transmitter to transmit the last sample.

I believe that what’s happening is that when it ends normally, the
host library disables the transmit path. When it’s killed with ^C it
just blows out and doesn’t disable the transmit path (Note that the
python code handles ^C properly)

Thus, what’s happening in the “normal termination” case is that the
tx_chain is disabled, and therefore the zeros that you’re inserting
into the head of the tx signal processing path aren’t being
processed and never get to the DACs…

So much for the simple solution :wink:

Eric

an additional note- tested with the original firmware and ctrl+c’ing
still
leaves the sine-wave, with my new firmware, it goes away as desired…

I remain perplexed as to why letting the program end normally results in
the
tx_empty not happening or the clock stopping or whatever is causing the
transmitter to transmit the last sample.

View this message in context:
http://www.nabble.com/ramping-down-(tx_empy-continued)-tf3021634.html#a8395268
Sent from the GnuRadio mailing list archive at Nabble.com.

So, then we have to go dac side, with ramping, and pay attention to
tx_enable
as well…
I’ll see what I can do.

Eric B. wrote:

the
into the head of the tx signal processing path aren’t being
Discuss-gnuradio Info Page


View this message in context:
http://www.nabble.com/ramping-down-(tx_empy-continued)-tf3021634.html#a8397435
Sent from the GnuRadio mailing list archive at Nabble.com.