discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Flowgraph stopped after few minutes


From: Pol Henarejos
Subject: Re: [Discuss-gnuradio] Flowgraph stopped after few minutes
Date: Wed, 01 Aug 2012 09:20:19 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0

Dear Tom,

I will give it a try. I will keep you in touch.

Thanks for your answer.


Pol Henarejos
Research Engineer, MSc
address@hidden

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 <address@hidden> 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 <address@hidden> 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
>>>
>>

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]