Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8

[Marcus Müller]

Hey,

thanks for the extensive answer! So, yeah, I think finding a way to come up with a graphical way to program C++ is a bigger problem than fixing the GNU Radio scheduler :) you're certainly invited to help on enabling loopbacks; there's no "real" reason it's forbidden by the scheduler. Essentially, the fact that the scheduler won't allow you to do it is for causality reasons:
At the point where the feedback merges into the "forward" stream, if you for example have an "Add" block, then that block can't do anything until there's input items on both inputs. But there can't be any input from the feedback stream if there's no output of the "Add" block. You can work around that, logically, by having a block in the feedback chain that produces a few samples without input, or make an "Add" equivalent that doesn't need input on both input streams to start, but it's not a general guarantee these flow graphs can run.
Historically, it really could not work (as far as I remember the previous single-threaded scheduler), but the hard "impossible" should have changed to a "possible with some complications and a lot of ugly corner cases".

Best regards,
Marcus

On 09/19/2017 02:53 PM, Federico 'Larroca' La Rocca wrote:

Hi,

so your idea is to use GNU Radio Companion to design blocks that internally has a loopback?

Actually, my idea was to use the companion to design blocks in c++. They may have loops or not.

That would kind of break the semantics of GRC being a tool for designing GNU Raio flow graphs

You are very right on this "confusion" issue, of which I haven't thought.

, but I'd still be open to that idea, if you could explain in which way that would differ from it simply being a unified "control loop" block that only is parameterizable (in which case you wouldn't benefit from the graphical representation of it being multiple blocks with feedback, because it's not what's happening, more confusing than clarifying).

So, I don't really think that we can find a sufficiently general approach here that would justify letting users do something that GNU Radio itself can't. I'd much rather fix the scheduler than spend time on emulating a fix by having restricted feedback ability that only allows a very limited set of blocks to work in the feedback branch.

What do you think?

I'm not sure what you mean by "unified control loop", but after some thought I agree with your last comment.

So, let me know how we can contribute to making loops possible in the scheduler. Not sure how much manpower we may get though, specially in the middle of the semester, but we'll do our best.

Best

Federico

 

Best regards,

Marcus