Good morning Marcus, Thanks for your response and sharing your thoughts.
My understanding is that things should work exactly as you say. My flowgraph has two custom built OOT blocks. Based on my signal processing algorithms, one takes in vectors of size 200 and the other 448. The one that takes input vectors of size 200 works beautifully and the input is either 200 or integer multiples of 200. The OOT block that was designed to take a vector of size 448 which I specified in its input signature and the stream-to-vector block which connects to its input was specified to have a vector of 448 items, however, the OOT signal processing fails. I inserted a print statement in the code and found the reason for the failure was due to the number of input items being 496 or multiples of 496 and not 448 or multiples of 448 which the signal processing algorithm expects. Thanks again for sharing your thoughts, I appreciate it. George On Wed, Oct 26, 2022, 5:16 AM Marcus Müller <muel...@kit.edu> wrote: > Hi George, > > I can't really follow. A block in GNU Radio has a *fixed* output item > size. So, the Stream > To Vector block *can* only produce items of size (448*sizeof(entry in the > vector)). That > can't change! > > Same with your block: it has an io_signature (you set it in the > constructor), which fixes > its input size. There's nothing that could change that; unless GNU Radio > really has a > *fatal* bug. > > So please tell us how exactly you notice / observe this change in input > vector length! > > Best regards, > Marcus > > On 26.10.22 03:24, George Edwards wrote: > > Hello GNURadio Community, > > > > I designed an OOT block to accept vectors of size 448 samples. In the > flowgraph, my block > > is preceded a Stream-to-Vector block with the vector size set to 448 > samples. My OOT block > > expects vector data that are of length 448 or multiple of 448 samples > for signal > > processing. I dumped the output of my block to a file and noticed that > the first 1000 > > values were correct and the rest garbage. I put a print statement in the > code to see the > > length of the input samples that the Scheduler provided on each > iteration. I found out > > that the inputs were 496 and multiples of 496 (obviously not integer > multiple of my > > vector length of 448 samples). Is there a way to force the Scheduler to > deliver input data > > samples that are the exactly 448 and multiple of 448 samples (which I > thought I would be > > getting by setting the vector size parameter to 448)? > > > > I am aware that the alternative may be to pad the data entering the > Stream-to-Vector block > > which precedes my OOT Block with 48 dummy samples and in my signal > processing remove them. > > > > I will appreciate any response that leads to me keeping the vector size > at 448 and having > > the Scheduler provide input data that are of size 448 or integer > multiples of 448. > > > > Regards, > > George >
