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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
