On Wed, Jul 10, 2013 at 1:25 AM, Johnathan Corgan <johnat...@corganlabs.com> wrote: > On 07/09/2013 05:06 PM, Tommy Tracy II wrote: > >> I am working on a GNU Radio Router block that will serve as a >> communication block between multiple flow graphs. My router will receive >> information via TCP, and then send it to several other blocks to be >> processed. After those blocks have completed their processing, my >> original idea was to take that data and return it to the router to be >> sent back to a different node. This would introduce a cycle in the flow >> graph. Is there any way to disable cycle prevention? > > There is no way to disable cycle prevention; the GNU Radio scheduler > algorithm requires streaming ports to be a directed acyclic graph. > > However, this applies to streaming ports only. It's possible (though > probably lower in performance) for you to encapsulate data into async > messages and use message ports connected in an arbitrary topology. > > -- > Johnathan Corgan > Corgan Labs - SDR Training and Development Services > http://corganlabs.com
The thing is, you don't want your streaming ports to have cycles. It's not a fundamental limitation of GNU Radio; it's just not the right thing to do. The streaming ports are for streams of data, which tend to have strong temporal relationships with each other. Cycles in data streams are (generally; I'm sure there are a few exceptions) usually very time-specific. Think of a PLL: if you have more than 1 sample delay in your loop, it falls apart as an algorithm (I have a paper on this somewhere that shows the math behind how delay effects the locking performance). We don't do cycles because we transfer large (ideally) chunks of data between blocks. If you're processing 8191 items in one work function and try to feed that back, you're now that many samples delayed in time. Then next call could be a different number. So not only do you have this delay, you have a varying time delay. Doesn't make sense for these kinds of streams. And if we set N=1 for all calls to work, you're going to maximize the scheduler overhead, which is also bad. What you're talking about sounds like a job for the message passing interface, as Johnathan recommended. You're not time dependent from what I gather from your email, so the async message interface will work well. That's basically what it's meant for. You would post messages when ready. The blocks that are receiving blocks would simply block until a message is posted to them and then wake up and process it. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
