I have a simple flowgraph with two branches, with different delays that
are joined at the end. Imagine a topblock with A,B,C,D blocks. A is
connected to B and C. B and C are connected to D. A and D are sink and
source respectively. B and C produce packets (header and payload) from
the input coming from A. D packets header and payload. The latency is
different since B and C produce different sizes. A produces one sample
per packet (it is a kind of signaling). All blocks are gr_block.
So, A produces a sample. It is delivered to B and C. Both produce header
and payload using the sample produced by A. Finally, D joins together
both inputs.
I studied the delay between both branches and, since B is faster than C,
the delay is increasing. After few minutes the flowgraph hangs and the
difference of delaying is around 8000 packets. The flowgraph is in fact
running. No stop is called but there are not any sample flowing.
Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
So, A produces a sample. It is delivered to B and C. Both produce header
Could you give me some hint for solving it?
Thank you.
–
Pol H.
Pol,
It’s difficult to diagnose these problems. Are all blocks (A, B, C,
and D) that you discuss your own blocks or are some of them in GNU
Radio already? If you’ve made your own blocks to do this, have to done
anything with the forecast method that might be requiring samples from
both inputs? With B and C producing samples at different rates, you
can’t be guaranteed that they will have enough samples to enter the
work function. You have to make sure that your block that takes in
both streams knows what to do if it’s given fewer samples than
required (save state for reentry, basically).
All blocks are written by me. B and C produce 40 and 80 samples,
respectively. They have set_output_multiple to 40 and 80. Both forecast
have in0=noutput/40 and in0=noutput/80. A block does not have nor
set_output_multiple nor forecast. D block (2 inputs 1 output) has
set_output_multiple to 40+80 and its forecast is in0=(nouput/(40+80))*40
and in1=(noutput/(40+80))*80. All consumes are adjusted as their
respective forecasts.
All these blocks are encapsulated by a hier_block2 and then connected to
a null_sink (for testing).
Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
I wouldn’t use set_output_multiple for this, especially since you’re
already using forecast. For block D, you might want to not use
forecast and instead keep track of what’s coming in from both inputs
between calls to work. That should help keep things moving.
Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 30/07/2012 13:39, Tom R. escribi:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.