|
From: | George Edwards |
Subject: | Re: How can you force the Scheduler to deliver appropriate vector size input |
Date: | Wed, 26 Oct 2022 09:04:39 -0600 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |