Hi Michael, Thank you very much for your response. This clears up things for me.
One other question regarding this is: If the block takes in 4095 samples, returns 3854 onto its output is this still considered a sync (1:1) block or would it be a general block? I am leaning towards thinking that any block that does not return the same number of samples as it took in in each call of work would be a general block since the ratio of input to output is not 1:1. Thanks Anil On Thu, Nov 16, 2017 at 7:48 AM, Michael Dickens <michael.dick...@ettus.com> wrote: > Hi Anil - In the case where your block gets 4095 items, it can't process > all of those items. Your block performs seven 512-length FFTs, consumes > 7x512 == 3584 items, and generates 3584 items, leaving 511 unprocessed. The > code that calls your block's "::work" method will handle making sure that > the input and output streams are updated correctly, and that those > unprocessed 511 items are the next in the input data stream. > > When doing streaming, you can, to some degree, control the amount of input > and output items via special functions / methods such as > "set_output_multiple". You can also set the input / output types to be a > vector of a specific length, e.g., that of your FFT == 512. Using either > "set_output_multiple" or a vector will guarantee that the number of input > and/or output items meets the criteria you require for this specific block > (for it to be a multiple of the FFT size, 512 items in this case). > > Hope this helps! - MLD > > ps> I'm pretty sure there are presentations on the internet freely > available that cover the concepts of how GR works under the hood -- > probably in basic detail, not getting bogged down by too many cases / > specifics. I'd encourage you to see what you can find in that regard; GRCon > and people's blogs are always good places to learn about how GR works. > > On Wed, Nov 15, 2017, at 09:56 PM, Anil Kumar Yerrapragada wrote: > > Hi all > > > I am experimenting with my own python block. I started by simply > interrogating each variable to see their types and shapes. > > > I connected a vector source that just generates increasing numbers (0, 1, > 2, 3, 4, 5 and so on upto a big number). > > > I noticed that the length of (input_items[0]) seems to oscillate between > 4096 and 4095 in successive work calls. I also noticed that in each work > call, a NEW set of samples appear. (attached file) > > > Here are my questions: > > > If I were just doing something really simple like squaring each element, > in each work call I'd just square every element in the vector > input_items[0]. No problem. > > > Suppose I need to do an FFT. (I know it can be done with stream to vector > followed by FFT) But suppose I wanted to make it work with streams. > > > In each work call, I’d divide the input_items[0] vector into chunks of > size = FFT size and take the FFT of each chunk. Again no problem. Since > 4096 will divide perfectly by a power of 2 FFT size. > > > But what about the case when I have 4095? If I do FFT = 512, I will get 7 > chunks of 512 and I will be left over with 511. Would I have to save those > 511 elements and use them in the next work call when input_items[0] gets > new elements? > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
