After calling stop(), USRP still seems active

GNU Radio
1

Hello,

I have run into a problem using flow_graph stop(). To test the problem,
I wrote a quick test script that simply sinks a tone to the USRP
(test_tone.py).

Basically this is:

class test_tone(gr.flow_graph):

def __init__(self):
    gr.flow_graph.__init__(self)

etc, etc

    |
    |
    |
   \ /
    '

# Connects the signal source (src = gr.sig_source_f) to the FM

modulation, provides software gain
# and finally sinks to the USRP.
self.connect(src, fmtx, gain, self.u)

This works fine as I am able to receive the tone. However, the code
below produces strange results:

#!/usr/bin/env python
from test_tone import *
import time

def hold(seconds):
print “holding for %d seconds” % seconds
time.sleep(seconds)

First run I get a tone.

hold(2)
t.start()
print “play back started”
hold(5)
print “play back ended”
t.stop()

On this second run I don’t get a tone.

hold(2)
t.start()
print “play back started again”
hold(5)
print “play back ended”
t.stop()

The first time through I receive the tone, the second time through
(stop, then restart the flowgraph) I don’t get a tone (rather what
sounds like garbage). Additionally, according to my RSSI reading the
USRP continues to transmit a residual signal, even though the flow graph
should be stopped. The only way I can get the USRP to actually stop
transmitting something is to delete and then re-instantiate my test_tone
object.

When stop() tells the scheduler to stop evaluating the graph, this
should stop everything, right?

Has anyone else encountered similar problems when using flowgraph stop()
in conjunction with the USRP?

(I am running the latest stable release, 3.0.3**, on Ubuntu).

Thanks,

Jonas

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

2

On Mon, Apr 30, 2007 at 02:17:38PM +1200, Jonas wrote:

Hello,

I have run into a problem using flow_graph stop(). To test the problem,
I wrote a quick test script that simply sinks a tone to the USRP
(test_tone.py).

Hi Jonas,

Can you send me the complete script off the list?

BTW, what are you really trying to accomplish?

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.

=======================================================================
Eric

3

I think this could be a symptom of using an older version bitfile for the
fpga load, where the fifo’s held the last value when emptied instead of
being zero’d. (?)
-Lee

Hi Lee,

I’m using the latest tarball (gnuradio-3.0.3.tar.gz). Does this have the
newer version bitfile?

As fas as I can tell it appears as though the flowgraph does end when I
call stop, so I think the problem is at the USRP level.

Thanks, Jonas

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