The input lengths will be correct, and you can read and/or consume up to
that much for each corresponding input. The output lengths are the maximum
amount you can write to each output. The work() return value is the usual
way to say how much you wrote to every output. For a sync block, it usually
d
Hi Jeff,
Thanks for the pointers!
I did not realize that I could only process the minimum length of the two
input buffers.
Dumb mistake on my part...
I just changed that and everything works fine.
BTW, just to confirm:
Is the minimum of the length of all input buffers to be trusted, even if it
The scheduler is allowed to make available more input items than forecast
asks for, so you need to compute the number you can use. This will not
necessarily be len(input_items[0]). I used the logic from your forecast and
it seems like it worked.
Also, unlike in C, "i" is left at the last value in
Hi Jeff,
I can confirm that the same behavior happens in 3.8
I attach the 3.8 graph
Achilleas
test_input_buffers_38.grc
Description: Binary data
Peak Detector 2 had a couple of fixes that may relate to this, included in
3.8.3.0. Can you replicate this with a simpler flowgraph that is built for
3.8? This one did not load well into GRC 3.8.
On Thu, Mar 25, 2021 at 9:37 PM Achilleas Anastasopoulos
wrote:
> HI all,
>
> I am trying to debug a
HI all,
I am trying to debug a grc flowgraph containing an Embedded Python
BASIC_BLOCK.
The python block has two inputs and one output.
The block makes sure (through FORECAST()) that both inputs have the SAME
sample requirements.
Also, the block ALWAYS uses CONSUME_EACH() so that both input buffer
