Re: [Discuss-gnuradio] multiple asynchronous channels in parallel

[Tom Rondeau]

On Tue, Sep 17, 2013 at 11:08 AM, alyafawi <address@hidden> wrote:
> Yes, I am using my own module that searches for messages. The flow graph
> structure contains usrp source -> LPF -> my own module.
>
> I am controlling them using nitems_items_required[0] = noutput_items *
> (message length)

So you are defining this in the forecast function?

What is the item size (input and output) that you specify with the
io_signatures in the constructor?

> and I call consume_each after each round with the proper number of processed
> samples.

You've asked the scheduler to provide noutput_items number of messages
worth of input data. So you have to make sure you're consuming the
message length in number of input items each time through.

Basically, it sounds like you're doing things right. When I say
"book-keeping" I mean to make sure that the number of items in and out
for each block are consumed and produced correctly by understanding
the item size and what you've processed. As I said, it sounds like you
understand things, but just work through the math again to double
check. What might be happening is that you're not consuming or
producing the right number of items, which is going to throw off your
read/write pointers in the buffers, possibly writing someplace you're
not supposed to, which is causing the segfault.

> The single channel version of the code is quite stable. Now, I just capture
> a wider band, and canalize using the filter offset.
>
> empty channels will consume samples faster than channels containing
> messages, so the scheduler is handling the read/write pointers to avoid
> writing on memory requested by other branches?

Well, 'faster' is an ambiguous term in an SDR GPP. The blocks are
probably completing their work faster, but the scheduler is still
moving stuff in proportion to everything else. So empty channels may
have that path finish faster than others, but it would just be waiting
until their is more data made available to it. Since you're coming in
through the same radio front end and passing it through filters of
(presumably) equal length, all those samples get there at the same
time. And all of your branches are processing faster than real-time or
you'd start experience overflows from the radio.

On the other hand, the addition of the blocks will change how the
scheduler moves data around, so that could be a different effect
that's causing issues than them being different rates.

Probably best to debug this offline without a USRP in the path, which
can help stabilize things and make runs more consistent.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13