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 <[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 > -- *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
