Hello
I’ve seen on the archives, and experienced myself, that GR does not
support having loops in the flow graph.
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.
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?
Thanks in advance
alberto
Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 €
al mese.Gratis la Sim Tiscali Mobile con 25 euro di traffico! L’offerta
è valida solo se attivi entro il
13/05/10http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw
On Wed, May 12, 2010 at 05:00:32PM +0200, Alberto T. 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