Tim,
One thing I have found with the Python stuff is that you need to set
the flow graph variable to None for resource to be released. moo =
myGraph(); moo.start(); time.sleep(10); moo.stop(); moo.wait(); moo = None;
moo = myGraph(); moo.start() .....
-Dave
On Thu, Jul 7, 2016 at 6:14 PM, Tim Castiglia <cas...@rpi.edu> wrote:
> First I should give some context on my project. What we are trying to
> build is a python server that utilizes gnuradio's blocks to get information
> from hardware and send it outbound, as well as receiving requests from
> clients to the server about configuration of flowgraph. More specifically,
> right now, I have:
>
> Oscom Source -->Log Power FFT --> Vector Probe
>
> For simplicity, I am using the RTL-SDR for testing purposes. In the
> future, we will be using our own device driver created within the SoapySDR
> framework, hence why we are using the oscom block.
>
> The problem starts with the fact that this may not be the only flowgraph
> we utilize. The hardware we are using may start pumping out FFT values
> instead of IQ values. Which means we would need a flowgraph that looks more
> like:
>
> Oscom Source --> Vector Probe
> (Ignore the fact that this is not possible with the oscom block currently,
> we will cross that bridge in the future)
>
> So I need to be able to stop my current running flowgraph, and start a new
> one. This is where I run into trouble. I can stop my flowgraph perfectly
> fine with:
>
> flowgraph.stop()
> flowgraph.wait()
> time.sleep(5)
>
> But I would like to keep the variable the same in my python code even when
> I change the flowgraph. So I try:
>
> flowgraph = newFlowgraphConstructor()
>
> But this causes a python error at the flowgraph.stop() line: "variable
> mentioned before instantiated"
>
> To get around this, I made a resetFlowgraph function:
> def resetFlowgraph():
> flowgraph = newFlowgraphConstructor()
> flowgraph.start()
>
> and call things in this order:
> flowgraph.stop()
> flowgraph.wait()
> time.sleep(5)
> resetFlowgraph()
>
> The flowgraph starts successfully, but fails to "claim" the RTL-SDR from
> the old flowgraph. I have also tried the same with only my device plugged
> in, and a similar problem occurs. Is there a way to force the flowgraph to
> relinquish its hold on the hardware? Our python server code needs to
> continue running, so I need to be able to do this restart without ending
> the program (The idea is to have the server always be running and not be
> manned most of the time).
>
> Here's some pseudo code to give you an idea of how the code is structured:
>
> #First I have a premade object generated from gnuradio-companion
> #I import that object into my server code
> import flowgraphInit from flowgraph
> #I can also import my other flowgraph
> import newFlowgraphConstructor from flowgraph2
>
> #At global level
> flowgraph = flowgraphInit()
> flowgraph.start()
>
> class ClientSocketConnection
> ...#init and other functions
> def onMessage(payload):
> #Parse message
> #If we need to change to a different flowgraph
> flowgraph.stop()
> flowgraph.wait()
> time.sleep(5)
> resetFlowgraph()
>
> def resetFlowgraph():
> flowgraph = newFlowgraphConstructor()
> flowgraph.start()
>
> def main():
> #create socket factory so we can allow many connections
> #So there is only one flowgraph, but many people can see it and
> potentially change it
>
> (I have seen this question asked before here
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-01/msg00411.html
> but there was no solution in the thread)
>
> Any help is appreciated!
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
