Dear Tom, I will give it a try. I will keep you in touch.
Thanks for your answer. Pol Henarejos Research Engineer, MSc pol.henare...@cttc.es Centre Tecnològic 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 Rondeau escribió: > On Mon, Jul 30, 2012 at 4:18 AM, Pol Henarejos <pol.henare...@cttc.es> wrote: >> Dear Tom, >> >> 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). >> >> Thanks for your help. >> >> Pol Henarejos > > Pol, > > 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. > > Tom > > >> El 29/07/2012 16:01, Tom Rondeau escribió: >>> On Thu, Jul 19, 2012 at 4:54 AM, Pol Henarejos <pol.henare...@cttc.es> >>> wrote: >>>> Dear list, >>>> >>>> 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. >>>> >>>> I use gnuradio master branch. >>>> >>>> Could you give me some hint for solving it? >>>> >>>> Thank you. >>>> >>>> -- >>>> >>>> Pol Henarejos >>> >>> >>> 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). >>> >>> Tom >>> >>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
