What does the USRP transmit after I've done tx->stop

Hi All,

I am transmitting a stream of buffers from the USRP (based on libusrp
with
standard .rbf file). After I’ve done tx->stop (where tx is a pointer to
usrp_standard_tx) it seems that the USRP is repeating the last
transmitted
buffer (or couple of buffers ?). Is this correct ?

BR/
Per

Per Z. wrote:

Hi All,

I am transmitting a stream of buffers from the USRP (based on libusrp with
standard .rbf file). After I’ve done tx->stop (where tx is a pointer to
usrp_standard_tx) it seems that the USRP is repeating the last transmitted
buffer (or couple of buffers ?). Is this correct ?

Continually, until you unplug the board? If so, I’ve noticed this
behavior too as of recent… I used to be able to replicate it 100% of
the time, but haven’t tried for a couple weeks.

Are you using the current GNU Radio trunk?

  • George

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don’t know how relevant this is, but I have fixed similar problems
in the past by making sure that the host app sends data that’s an even
multiple of 512 bytes. (This is harder than you think :))

I found that if you send a number of sample bytes equivalent to 1 same
mod 512 bytes, for instance, the last sample is repeated for some time
and can be observed as a short pilot tone. I never did too much
digging into this, however – I just modified the transmitting app to
pad.

  • -Dan

On Apr 25, 2008, at 7:31 AM, George N. wrote:

buffer (or couple of buffers ?). Is this correct ?


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgSBP4ACgkQy9GYuuMoUJ7gqgCg1D9y0VS5kACJP2n1HNJoLphD
u+oAniv+yi/QK3L19WDcRZ077xHh0ebO
=LbHy
-----END PGP SIGNATURE-----

On Fri, Apr 25, 2008 at 09:21:18AM -0700, Dan H. wrote:

-Dan

pointer to

  • George

I believe what is happening is that the transmit path is being
disabled in the FPGA before the zeros that get shoved into the head of
the DSP pipe when it underruns propagate through the pipeline. Thus
it’s stuck with a non-zero constant feeding the DACs. When run
through any of the d’boards with an LO, the constant turns into a
carrier at RF.

I think the right way to fix this is to have a “decay to zero” module
right before the DACs that is controlled by a delayed copy of the
tx_enable signal (I may have the signal name wrong… This is from
memory)

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs