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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
