discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] custom work function gets into an endless loop


From: Martin Braun
Subject: Re: [Discuss-gnuradio] custom work function gets into an endless loop
Date: Mon, 28 Sep 2015 09:39:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

On 27.09.2015 15:25, Kolya wrote:
> Hi,
> 
> I'm trying to build a custom block that takes in a stream of input samples
> and simply adds a postamble of 32bits every 352 bits. The package structure
> is illustrated below (payload_bits = msg_bits+postamble_bits):
> ---------------------------------------------------------------
> |   msg_bits = 352         |  postamble_bits = 32  |
> ---------------------------------------------------------------
> 
> For some reason the code below gets into an endless loop when I run it
> through a test and stimulate it with a non-repeating vector source. The
> debug printf statements show that the loop keeps iterating even without
> input.
> I derived from gr_block because the number of output samples is higher than

I'm guessing you mean gr::block? If so, that's the correct choice.

>       }
> #ifdef VERBOSE
>       printf(">>> offset= %d\n",out_offset);
>       printf(">>> consumed= %d\n",consumed);
> #endif

FYI, we have a great logging infrastructure for these kinds of things,
see http://gnuradio.org/doc/doxygen/page_logger.html.

>       this->consume_each(consumed);
>       return out_offset;
> }/
> 
> I also overrode the forecast function to account for the fact that fewer
> input samples are needed than output samples are produced:
> 
> /    void
>     bbframer_bb_impl::forecast (int noutput_items, gr_vector_int
> &ninput_items_required)
>     {
>         ninput_items_required[0] = ((noutput_items - 32) / 8); // 32 bit
> postamble
>     }/

There's several issues here. First, your math is broken; you want
ninput_items_required to always be a positive, non-zero number which
you're not checking. Say it's 0, then that means it's fine to call your
work function with no input. What you want is something like
'(noutput_items / 47) * 44.
Second, you don't necessarily need forecast. If your packet size is
always the same, I recommend using set_output_multiple and
relative_rate. Or you can even use tagged streams, check out crc32_bb
which does pretty much the same as your block, albeit at varying packet
lengths.

Cheers,
M





reply via email to

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