discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Custom Blocks and Number of Items Per Port


From: Martin Braun (CEL)
Subject: Re: [Discuss-gnuradio] Custom Blocks and Number of Items Per Port
Date: Fri, 3 Aug 2012 19:56:53 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Aug 03, 2012 at 01:38:38PM -0400, Alexander Olihovik wrote:
> There are a few cases when input_items[0] doesn't equal input_items[1]. If 
> say,
> len(input_items[0]) = 1000 and len(input_items[1]) = 1500, and I returned the
> smaller of the two values, 1000, what would happen to the other 500 samples on
> port 1? Would they be buffered somewhere and then used the next time the work
> function is called?

Yep. The case where the len(input_items) are different is what you
should normally prepare for.

Are you *certain* you can't use a gr_sync_{block,decimator,interpolator}?
That would make stuff much easier for you, I guess. For a start, you
wouldn't even need to check input_items.

MB

> 
> 
> On Wed, Aug 1, 2012 at 8:40 PM, Tom Rondeau <address@hidden> wrote:
> 
> 
>     On Wed, Aug 1, 2012 at 3:46 PM, Alexander Olihovik <address@hidden>
>     wrote:
>     > Hi all!
>     > I'm writing a custom sink block in Python with multiple input ports of
>     all
>     > the same data type.
>     > I've been reading Josh's block coding guide, but I'm confused at one
>     point:
>     > The value returned by a block should be the number of items produced by
>     that
>     > block.
>     > Is this to say that if I have multiple ports, I may return the value of
>     > input_items[0]?
>     > Or is it correct to say that I must return the sum of all 
> input_items[i],
>     i
>     > = range(number of input ports)?
>     >
>     >
>     > I would like to create a synchronous block where all ports consume and
>     > produce an equal number of items every time the work function is called.
>     > However, it appears that there are times when input_items[0] !=
>     > input_items[1] != ... != input_items[numPorts-1]
>     > If I were to return input_items[0], I would assume that this would not
>     yield
>     > the results I expect!
>     >
>     > Any help is greatly appreciated!
>     >
>     > From,
>     > Alex
> 
> 
>     If you have a block with multiple input items and you want to produce
>     the same number every time, noutput_items will tell you how much you
>     are capable of producing on every output stream. When you 'return
>     noutput_items', you are saying that you have produced that many items
>     on EVERY stream.
> 
>     There is another way that specifies the same thing. Each block
>     consumes some number of samples on every input stream and produces
>     some number of samples on every output stream. You can individually
>     specify "produce(i, N_i)" and "consume(o, N_o)" on each input and
>     output stream, respectively. In this case i is the input stream and
>     N_i is the number of items consumed on that input stream and o is the
>     output stream and N_o is the number of items consumed on that output
>     stream. When specifying your own 'produce' values, though, make sure
>     to return WORKED_CALLED_PRODUCE, to tell the scheduler that you have
>     done this yourself. But it sounds like you want to produce the same
>     amount on every stream, so you should be fine just using 'return
>     nouput_items'.
> 
>     Tom
> 
> 
> 
> 
> --
> Alex Olihovik
> University of Virginia 2013
> BS Electrical Engineering
> BS Computer Engineering
> address@hidden

> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstra├če 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-W├╝rttemberg and
National Laboratory of the Helmholtz Association

Attachment: pgpYvB49yubxn.pgp
Description: PGP signature


reply via email to

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