On 08/06/2012 09:44 AM, Alexander Olihovik wrote: > 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? >
nothing is dropped, its all held in the otput buffer of the upstream block until all downstream readers have read. -j > On Fri, Aug 3, 2012 at 6:10 PM, Josh Blum <[email protected]> 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) <[email protected] >>> 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) < >> [email protected] >>>>> >>>>> 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 <[email protected]> >>>> wrote: >>>>> > >>>>> > >>>>> > On Wed, Aug 1, 2012 at 3:46 PM, Alexander Olihovik < >>>>> [email protected]> >>>>> > 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 >>>>> > [email protected] >>>>> >>>>> >>>>> > _______________________________________________ >>>>> > Discuss-gnuradio mailing list >>>>> > [email protected] >>>>> > 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 >>>>> [email protected] >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Alex Olihovik >>>>> University of Virginia 2013 >>>>> BS Electrical Engineering >>>>> BS Computer Engineering >>>>> [email protected] >>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
