Re: [Discuss-gnuradio] Process for relinquishing driver control in a flowgraph before starting a new one

[Dave NotTelling]

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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio