On Tue, Sep 17, 2013 at 11:08 AM, alyafawi <im_yaf...@yahoo.com> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
