Forum: GNU Radio USRP continues to transmit after usrp_siggen.py stopped

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.
Kimminau Jr., Leo F. (Guest)
on 2009-01-26 22:17
(Received via mailing list)
Using a PowerMac G5 to control the USRP, if I stop usrp_siggen.py, the
USRP continues to transmit.  Is this expected?

This behavior is different than on a PowerBook G4, where the USRP stops
transmitting when usrp_siggen.py is stopped.


Leo Kimminau
Johnathan C. (Guest)
on 2009-01-27 07:05
(Received via mailing list)
On Sun, Jan 25, 2009 at 9:21 PM, Kimminau Jr., Leo F. 
<removed_email_address@domain.invalid>
wrote:

> Using a PowerMac G5 to control the USRP, if I stop usrp_siggen.py, the USRP
> continues to transmit.  Is this expected?

No.

> This behavior is different than on a PowerBook G4, where the USRP stops
> transmitting when usrp_siggen.py is stopped.

Can you elaborate on any other differences between the configurations?
 OS version, GNU Radio version, developer tools (GCC, swig, Python),
etc.?

Thanks

-Johnathan
Eric B. (Guest)
on 2009-01-27 12:23
(Received via mailing list)
On Mon, Jan 26, 2009 at 09:03:32PM -0800, Johnathan C. wrote:
> Can you elaborate on any other differences between the configurations?
>  OS version, GNU Radio version, developer tools (GCC, swig, Python),
> etc.?
>
> Thanks
>
> -Johnathan

I think this is a known problem (not sure there's a ticket on it).  I
believe that what is happening is that on the faster machine, the Tx
pipeline in the FPGA is getting disabled before it has a chance to
drain.  The result of this is that the pipeline is halted with a
non-zero constant value getting clocked into the DACs resulting in a
carrier for all daughterboards that contain an LO.

Eric
This topic is locked and can not be replied to.