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 <anas...@umich.edu> wrote: > 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 buffers are > cleared by the same amount of samples. > > I observe the following behavior: > > During normal operation (high SNR) the lengths of the two input buffers > are the same. > However, after some tinkering (I decrease the SNR using a QT Range and > then increase it again) the two input buffers have different lengths! > > Is this even possible? > Can the scheduler do that? > > I first suspected that the peak detector which is present in the flowgraph > and feeds the first input of the python block is chewing up samples when > it does not find a peak so my two streams become unsynchronized. However I > verified that the peak detector is a sync_block so this is impossible > either... > > Do you have any idea as to why this is happening? > > I attach the grc code (this is tested in 3.7 and 3.8). > > thanks in advance for any help, > Achilleas > > > >
