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: [EMAIL PROTECTED] 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. _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
