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: Alexander Olihovik
Subject: Re: [Discuss-gnuradio] Custom Blocks and Number of Items Per Port
Date: Mon, 6 Aug 2012 09:44:53 -0400

Will the unconsumed items on ports with a larger number of samples sent to them be buffered up automatically, or do I need to do that myself?
i.e. If port 0 has 100 items, and port 1 has 300 items, and I consume 100 items from each port, what happens to the remaining 200 items on port 1? Are they buffered automatically or dropped?

On Fri, Aug 3, 2012 at 6:10 PM, Josh Blum <address@hidden> wrote:


On 08/03/2012 02:16 PM, Alexander Olihovik wrote:
> Ideally, I'd like to have 10000 items on each port every time work() is
> called, since my sink will be sending 10k snapshots of data to another
> algorithm.
> Right now, since I don't have that many items on each port, I'm looking for
> the minimum number of items on all ports, saving that number of items from
> each stream to a numpy array, and then calling consume() for that number of
> items. Multiple calls to work() will eventually fill up the array. Is this
> not a good way of doing this?
>

That will work. There is more than 1 way to crack the egg.

I believe that you can overload forecast to make the scheduler to the
work for you. To enable that call set_auto_consume(False)

-josh

> On Fri, Aug 3, 2012 at 3:12 PM, Martin Braun (CEL) <address@hidden>wrote:
>
>> On Fri, Aug 03, 2012 at 02:23:39PM -0400, Alexander Olihovik wrote:
>>> It seems as if the gr_sync_block is close to what Josh Blum refers to as
>> an
>>> Arbitrary Ratio Block in his Blocks Coding Guide.
>>
>> Read the guide again :)
>> that's not at all what it is.
>>
>> This might also help:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsCoreConcepts
>>
>> ...not quite finished, though.
>>
>>> Do you think if I were to use the forecast() function and make all
>>> ninput_items_required[i] to be the same set amount, I would always have
>> the
>>> same number of input_items[i] on each port every time the work()
>> function is
>>> called? Is it this simple?
>>
>> There should be no reason at all for wanting to have the same number of
>> input_items at every port. Leave that to the scheduler. Just consume
>> whatever items you need every time work() is called.
>>
>> MB
>>
>>
>>>
>>>
>>> On Fri, Aug 3, 2012 at 1:56 PM, Martin Braun (CEL) <address@hidden
>>>
>>> wrote:
>>>
>>>
>>>     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
>>>
>>>     _______________________________________________
>>>     Discuss-gnuradio mailing list
>>>     address@hidden
>>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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



--
Alex Olihovik
University of Virginia 2013
BS Electrical Engineering
BS Computer Engineering
address@hidden


reply via email to

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