Forum: GNU Radio Re: After calling stop(), USRP still seems active.

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
00815bf11a9b254398b5e14aebd2d7d8?d=identicon&s=25 Jonas Hodel (Guest)
on 2007-05-03 03:26
(Received via mailing list)
Eric Blossom wrote:
> Can you send me the complete script off the list?
Hi Eric,

Thanks for your response! I have attached, which since my
last post I have checked and changed slightly, but the problem doesn't
seem to be there.
> BTW, what are you really trying to accomplish?
I am developing a USRP Server computer that can be controlled from any
client computer, (clients run Matlab under Windows). Clients require the
ability to terminate running flow graphs, hence my requirement for
stop(). To test the stop() functionality (independent of my threaded
server code) I am running in the python interpreter.

from test_tone import *
tone = test_tone()

The only way I can get the USRP to actually stop transmitting something
is to delete my instantiated test_tone object. Calling stop() stops the
tone but the USRP still transmits something (difference between actually
being off and pretending to be off is 40 dB).
> Also, can you figure out how to get rid of this signature?
> It's not appropriate for posting to what is obviously a public mailing
> list.
I am sorry about the signature but unfortunately it is attached as it
leaves. Maybe I should setup an external email address.
> Eric

Thanks for your help,


This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
Da5df98b071ce8369340856c1120ec84?d=identicon&s=25 Lee (Guest)
on 2007-05-03 05:10
(Received via mailing list)
I think this could be a symptom of using an older version bitfile for
fpga load, where the fifo's held the last value when emptied instead of
being zero'd. (?)
This topic is locked and can not be replied to.