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) > <martin.br...@kit.edu>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) <martin.br...@kit.edu >>> >>> 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 <t...@trondeau.com> >> wrote: >>> > >>> > >>> > On Wed, Aug 1, 2012 at 3:46 PM, Alexander Olihovik < >>> ano...@virginia.edu> >>> > 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 >>> > ano...@virginia.edu >>> >>> >>> > _______________________________________________ >>> > Discuss-gnuradio mailing list >>> > Discuss-gnuradio@gnu.org >>> > 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 >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> >>> >>> >>> -- >>> Alex Olihovik >>> University of Virginia 2013 >>> BS Electrical Engineering >>> BS Computer Engineering >>> ano...@virginia.edu >> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
