discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Radio web API


From: Kevin Reid
Subject: Re: GNU Radio web API
Date: Wed, 24 Jun 2020 20:34:51 -0700

On Wed, Jun 24, 2020 at 8:04 AM Steven Gillies <stevengillies@outlook.com> wrote:
I am trying to build a web API to start and stop flowgraphs remotely and autonomously.

I am having trouble gracefully shutting down one flowgraph and moving on to the next.

My preferred way implement the services is by running top_block.start() from my main thread and allowing it to start its own thread. To shut it down I then call top_block.stop() followed by top_block.wait(). The threads appear to shut down gracefully but when I try to run another flowgraph (either the same flowgraph again or a different one) I start to get errors.

The two error types I get are either;
  1. that the second flowgraph cannot find the USRP device because it is being held by the first ($ uhd_find_devices also returns 'No Devices Found' until I exit the main thread at which point it finds my B210 again), or
  2. that a socket that the second wants to bind to is in use by the first
In my experience (I wrote ShinySDR, which is also a web remote control system), the cause of these problems is that references to the old blocks still exist. There is unfortunately no standard way to tell a block to free the resources it is using, other than ensuring it is "deleted" by dropping all references to it. Therefore, you need to ensure that your Python code does not have any variables or attributes referring to the old top block or the individual blocks, before you construct the new blocks.

That said, you may want to try the alternative of keeping the UHD, socket, etc. blocks around and reusing them, and only changing what they're connected to. (That's what ShinySDR currently does, though with different blocks.) Basically, use disconnect() as well as connect() to change your flow graph's connectivity while it's stopped so that it suits the new purpose. You might encounter some misbehavior here too, though; this is not a frequently used and well-tested part of GNU Radio's capabilities.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]