Re: [Discuss-gnuradio] USRP behavior during underflow

[Francois Quitin]

Hi Josh, 

Thanks a lot for your answer. I tried bypassing the DUC cordic with the
tune_request command and it solved my problem! The absolute LO phase offset
between the transmitter and receiver is not lost between packets, so I'm
able to track it now. 

Thanks for your help, 

Francois



-----Message d'origine-----
De : address@hidden
[mailto:address@hidden De la part de
Josh Blum
Envoyé : mercredi 18 avril 2012 18:37
À : address@hidden
Objet : Re: [Discuss-gnuradio] USRP behavior during underflow


> 
> 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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio