Top block trash not cleaning up where it used to. File sink not writing in some instances

GNU Radio
1

Hello everyone.

I’ve posted this problem here before, and the solution didn’t work out
as I
hoped. The thread title didn’t mention my real problem, so here it is
again.

I have various instances of my top block, detector(). It has a parameter
(options) that passes onto it the options for the USRP and block
configurations.

What I’m doing is running the top block for a range of options, stopping
it
whenever it’s done.

Before, this was all that was needed:

options.filename = “xpto”
detector1 = detector(options)

detector1.start()
time.sleep(x)
detector1.stop()

options.filename = “xpto2”
detector1 = detector(options)

detector1.start()
time.sleep(x)
detector1.stop()

And so on. Of course this is in a loop for my parameter range. It worked
on
a previous version of GNURadio (3.7.1 if I recall correctly) and now it
stopped working.

The proposed solution was using detector1.wait() and detector1 = None
after
stopping the flowgraph.

However, I’ve run into some troubles. Everytime I instance the class the
USRP is “started” again, eventually throwing this error:

UHD Warning:
The control endpoint was left in a bad state.
Attempting endpoint re-enumeration…

And in most experiments the file sink doesn’t write anything into the
file
(even though it writes the file itself, so I believe the file pointer
isn’t
the problem). I never had this problem before and I didn’t change
anything
in the python source code itself.

Could it be anything in the top block itself that is causing the
problem,
or is there something I’m doing wrong?

Thanks in advance.

2

Hi Miguel,
On 01/03/2014 11:01 PM, Miguel Duarte wrote:

The proposed solution was using detector1.wait() and detector1 = None after
stopping the flowgraph.
If I remember correctly, I proposed this to kindly suggest that python
really garbage collects things, call swig del methods, calling C++
destructors, flushing files in turn.
Glad to hear that solved the “things not being written to files”
problem, if I understand correctly.

However, I’ve run into some troubles. Everytime I instance the class the USRP is
“started” again, eventually throwing this error:
Ok, the restarting is by design: You deconstruct the uhd_source every
time, so of course the USRP is reinitialized each time after.

UHD Warning:
The control endpoint was left in a bad state.
Attempting endpoint re-enumeration…

Hm this is a warning only, I guess if you don’t see an error afterwards,
re-enumeration was successful and everything should work as expected.

And in most experiments the file sink doesn’t write anything into the file (even
though it writes the file itself, so I believe the file pointer isn’t the
problem). I never had this problem before and I didn’t change anything in the
python source code itself.
So the file writing problem persists? Can you verify that data actually
reaches the file sink? Please really do the wait() call, it makes sure
that the remaining samples actually reach the sinks.

Could it be anything in the top block itself that is causing the problem, or is
there something I’m doing wrong?
Well, aside from not calling wait() I don’t think you’re doing anything
/wrong/, but it might be a better design choice not to reinstantiate the
whole top_block each time but to reuse your uhd_source, pause it, pause
the flowgraph, close the file_sink, open the next file, reconfigure the
flowgraph, and continue it.

Thanks in advance.
Hope this one actually helps,
Marcus

3

On 01/03/2014 11:01 PM, Miguel Duarte wrote:

The proposed solution was using detector1.wait() and detector1 = None
after stopping the flowgraph.

I very vaguely remember something like this… Try this: Put the whole
thing into an extra function, and assign the tb there, like:

def run_one_instance():
d = detector()
d.start()
time.sleep(x)
d.stop()
return

I think this does the garbage collection differently. Tell us what
happened!

MB

4

Marcus M.: It… kind of worked, in relation to the file sink
writing.
Worked in some cases but not in most (!?), it seemed up to chance
really. I
don’t know what to think of it.

Martin B.: That solution didn’t work, at least in my case. Thanks for
the advice though.

I’ve tried everything, and I’m feeling really dumb for not managing to
make
it work. I’ve switched to a more practical method, using lock() and
unlock().

But even destroying all blocks (including the file sink block) and
constructing them again, it doesn’t work. Also, I’ve switched order and
it
always works for the first time. There’s something I’m missing. (The
only
blocks I’m not destroying are the USRP blocks now, but I don’t think
that
could be it, even if the USRP was giving out weird data it would write
it
to file.) The thing is, since I’m not using any wxgui blocks right now
and
I never intended to, I don’t even know how I’m supposed to debug and
check
if there’s anything reaching the file sink.

I mean I’m doing some heavy duty stuff right now:

-Instance detector (with start() and lock() in init, but no
connections)
-Add blocks/connections
-Unlock/Write (it does)
-Lock
-Remove all blocks except USRP / Add them all again and connect them
-Unlock/Write (0B file)
-Lock

Can I extract and print in python the info going through a certain
block,
or something like that? Or do I have to delve into C++ territory?

Something so simple, yet something that is taking me so many hours. Eh.

Thanks guys.

2014/1/5 Martin B. [email protected]

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Miguel,

sorry to hear you have a hard time… :frowning:

On 08.01.2014 18:44, Miguel Duarte wrote:

Marcus M.: It… kind of worked, in relation to the file sink
writing. Worked in some cases but not in most (!?), it seemed up to
chance really. I don’t know what to think of it.
:confused: Me neither;

Martin B.: That solution didn’t work, at least in my case.
Thanks for the advice though.
I guess GNU Radio needs more SWIG experts, and someone who knows who
to coerce python to just do what I tell you…

I’ve tried everything, and I’m feeling really dumb for not managing
to make it work. I’ve switched to a more practical method, using
lock() and unlock().
Don’t feel dumb.

But even destroying all blocks (including the file sink block) and
constructing them again, it doesn’t work. Also, I’ve switched order
and it always works for the first time. There’s something I’m
missing. (The only blocks I’m not destroying are the USRP blocks
now, but I don’t think that could be it, even if the USRP was
giving out weird data it would write it to file.) The thing is,
since I’m not using any wxgui blocks right now and I never intended
to, I don’t even know how I’m supposed to debug and check if
there’s anything reaching the file sink.
Ok, I know this is not incredibly helpful if you’re dealing with very
much samples, but maybe try this:

    • replace file_sink by vector_sink_X
    • at the end of your flowgraph run, get a
      numpy.array(vector_sink.data())
    • using the numpy arrays .tofile() method, save it to a file

Can I extract and print in python the info going through a certain
block, or something like that? Or do I have to delve into C++
territory?
Can be done in python.
Just write a python block that a) copies the input to the output and
b) prints nitems_read() or something of the like.

Hope I could alleviate your situation a little,

Greetings,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSzZMsAAoJEAFxB7BbsDrLQhQIAJzSOiDJL8GQUIQk5HOKRB6o
C+t5IgoBz3mmsszoCT6NQ1MaH+O+NCIJQ8QiWY37NYNSLuLikSWMJ5ioY59gatAv
vP8BXRqxGYsQsC6iUvH/jcfDML33ggwAs0ZtVsD6BI0i/PDdVs6dWRq2kE6cqaZD
YySH7dnKMV/xdsd2pA+V3J3sX9Z9P/UAgQdFDmI9mfAZD5o4jO3aPs/x4GxeNNZJ
sc8+V3ljzMmull4xsdE325tVHstWrRB4lnF8h3wX/TiiLEvZZQhp5rFYKJkZxwwr
Lk/Rq6oqaLQzUonkE3nNNXKh6RggVnZittOe7DBzb46q9XKJJWKhpFHgflMlhtc=
=T0FS
-----END PGP SIGNATURE-----