On Wed, May 12, 2010 at 05:00:32PM +0200, Alberto Trentadue wrote: > Hello
> I've seen on the archives, and experienced myself, that GR does not > support having loops in the flow graph. Correct. > I would like to get some more insight on this limitation to > understand 1.the reasons for it and 2. how to workaround it in those > cases where a feedback loop is a key solution. The reasons are that we currently dynamically schedule all of the blocks, there is no guarantee that a block will produce the number of samples that we asked it too, and that we like doing things in larger chunks for performance reasons. I believe that the best way to work around this limitation would be to statically schedule portions of the graph. One way to do this is to add delay annotations to the edges (connections) between blocks, and feed that into a modified scheduling algorithm. We'd also need a way for blocks to promise to deliver the number of samples we ask for. Blocks that derive from gr_sync_block, gr_sync_interpolator and gr_sync_decimator have the appropriate behavior. We'd just need a way to communicate that to the scheduling mechanism. Will Plishker, a postdoc at the University of Maryland, was doing some work in this area. I haven't talked to him in a while, so I'm not sure of the status of that work. I've cc'd him on this message. > Naively, I try asking if it would be acceptable to detect the > presence of at least 1 sample delay in the loop and apply a kind of > initial condition (or simply a 0 initial value) to boot the > computations. Where in the code the loop detection is implemented? The loop detection is implemented in gr_flowgraph.cc in the topological sort code. The actual check occurs on line 460. > Thanks in advance > alberto Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
