I did generalize and simplify the problem presented to make it simpler. The real calculation of the arbitrary-length sequence is made inside the block. The block is actually a sync block. Some (not all) of the items it outputs are tagged. Tags are determined by the calculation ran on the sequence. If I understand correctly, the fact that I need to tag items from the past means that the approach of storing them in a memory buffer of the block isn't going to solve my problem: I'll be able to find out what is the max value, but I won't be able to tag the item if it was consumed by a former call to work() - can't tag past items.
The solution presented in peak_detector2_fb was the inspiration to my solution, and my questions in the original post arise from it (how do I increase the maximum possible number of items, specifically in Python, how do I handle the error if it indeed occurs, and a theoretical question - why do I need to use output_multiple and the scheduler doesn't feed my block with more items if it has more ready as an input because the last call to work() didn't consume any). On Tue, Oct 17, 2017 at 6:02 AM Kevin Reid <[email protected]> wrote: > On Sun, Oct 15, 2017 at 10:59 PM, Gilad Beeri (ApolloShield) < > [email protected]> wrote: > >> I'm writing a Python block that, in general, does the following: >> Input: a stream of numbers (assume integers for the sake of discussion). >> Output: a stream of numbers >> > … > >> Note: The sequences can be of arbitrary lengths. >> > > If you need to look at an arbitrary length of samples, it would likely be > best for your block to store the samples it receives in a buffer it > manages, not try to convince GNU Radio to store them for you. > > More narrowly, if the only _sample_ you want to output is the max value > (you talked about "tagging the max value" but your example output sequences > also didn't contain any "untagged" samples, so I'm not sure if that's what > you actually meant), you should be able to just track the max-so-far value > and not even need an unbounded buffer. > > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
