[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] USRP behavior during underflow
From: |
Josh Blum |
Subject: |
Re: [Discuss-gnuradio] USRP behavior during underflow |
Date: |
Wed, 18 Apr 2012 18:37:14 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 |
>
> Our guess is that when we stop sending samples to the transmitting USRP
> (when the underflow occurs), the transmitter (or parts thereof) is turned
FWIW, you can issue a end of burst tag to the usrp to properly end the
transmission. This will stop the underflow event from occurring.
If and when python blocks feature is merged, this can be integrated as
part of the packet encoder/framer whatever python foo.
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n59
> off. When the next packet arrives, the transmitter is turned on again, but
> the absolute phase of the carrier is lost.
>
>
>
> Is this something to be expected? Is there a way to keep the transmitter on
> during an underflow?
>
So there are two elements in the transmit chain that have a phase.
1) The DUC cordic. This resets phase when a new transmit burst begins
and continues to run as long as it sees samples.
You can effectively bypass the cordic by forcing it to be zero. You can
do with with tune_request_t, and the grc blocks have some examples in
the properties dialog.
2) The RF LO. The phase of this changes when you tune, but otherwise
continues to run regardless of transmitting or not.
I hope that helps,
-Josh