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

[Tim Castiglia]

I found a workaround that's not so pretty, but it works. Setting the flowgraph to None does not work for me because it makes my other python threads that are running throw errors. The problem turns out is more of a low level hardware problem, or at least that's the case for when I use my specific hardware driver.

The file descriptor my hardware was open on was closed, but an error occurred when restarting the flowgraph in closing and reopening the file descriptor. I cannot track down what exactly is causing the error, but instead of fixing it, I just took out the close(fileDescriptor) line in my code. This doesn't harm the system because the same file descriptor is use anyway when the flowgraph is restarted.

I also realized that having a global flowgraph will be difficult to change within python, so I made a wrapper class that holds the flowgraph as a member variable, and made the class global instead. On top of this, when I restart the flowgraph, I change the wrappers flowgraph, and then set a member variable flowgraph in the socket class to be equal to the wrapper's flowgraph. This might be overkill, but it works.

#I import that object into my server code

import flowgraphInit from flowgraph

#I can also import my other flowgraph

import newFlowgraphConstructor from flowgraph2

class wrapper():

    __init__(self):

        self.flowgraph = flowgraph

#At global level
flowgraph = flowgraphInit()
flowgraph.start()

wr = wrapper()

class ClientSocketConnection

    __init__(self):

        self.flowgraph = wr.flowgraph

    #other functions
    def onMessage(payload):
        #Parse message
        #If we need to change to a different flowgraph
        wr.flowgraph.stop()
        wr.flowgraph.wait()
        time.sleep(5)
        self.resetFlowgraph()

    def resetFlowgraph(self):
        wr.flowgraph = newFlowgraphConstructor()
        wr.flowgraph.start()

        self.flowgraph = wr.flowgraph

def main():

    #create socket factory so we can allow many connections

  

On Fri, Jul 8, 2016 at 10:35 AM, Dave NotTelling <address@hidden> wrote:

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