Forum: GNU Radio ramping down (tx_empy continued)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Brett Trotter (Guest)
on 2007-01-16 17:44
(Received via mailing list)
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-%28tx_empy-cont...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2007-01-16 18:22
(Received via mailing list)
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
Brett Trotter (Guest)
on 2007-01-16 18:29
(Received via mailing list)
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-%28tx_empy-cont...
Sent from the GnuRadio mailing list archive at Nabble.com.
Brett Trotter (Guest)
on 2007-01-16 19:46
(Received via mailing list)
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-%28tx_empy-cont...
Sent from the GnuRadio mailing list archive at Nabble.com.
Brett Trotter (Guest)
on 2007-01-16 19:54
(Received via mailing list)
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-%28tx_empy-cont...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2007-01-16 20:23
(Received via mailing list)
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 ;)

Eric
Brett Trotter (Guest)
on 2007-01-16 21:48
(Received via mailing list)
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
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/ramping-down-%28tx_empy-cont...
Sent from the GnuRadio mailing list archive at Nabble.com.
This topic is locked and can not be replied to.