Hi All:
My previous report of lock-up issues with both the standard Repeat
block, and a new OOT block that I wrote to allow variable interpolation
can be ignored.
The issue that generated my report was my use of a dual-input time sink.
I was feeding a base [0,1] signal into one input, and the interpolated
signal into the other. For some reason that caused the sink to lock up.
Using two separate time sinks, both old and new Repeat blocks run fine.
My new variable interpolation block works well!
Thanks to Marcus M. and Francisco A. for their assistance and
detailed explanation. I learned a lot through this process.
Kevin
On Sun, Aug 2, 2015 at 10:46 AM, Kevin McQuiggin [email protected]
wrote:
new variable interpolation block works well!
Thanks to Marcus M. and Francisco A. for their assistance and
detailed explanation. I learned a lot through this process.
Kevin
Kevin,
Yes, the qtgui sinks can only accept streams coming in at the same
sample
rate, and the repeat block would change that. Glad you figured it out. I
really thought that I had added that warning to the manual page, but I
don’t see it in the published manual. I need to check on this and make
sure
a warning about this is made in the docs.
Tom
Kevin,
Yes, the qtgui sinks can only accept streams coming in at the same sample rate,
and the repeat block would change that. Glad you figured it out. I really thought
that I had added that warning to the manual page, but I don’t see it in the
published manual. I need to check on this and make sure a warning about this is
made in the docs.
Tom
Hi Tom:
Thanks for the information, that explains what I was seeing last night!
Kevin
(Are you sure you meant to thank me? Hahaha… I only mentioned the
underlined parameters! 
)
Sometimes I still find myself looking for the cause of a stopped
flowgraph,
to finally find I connected two streams with different sample rates to
the
same GUI sink.
2015-08-02 14:25 GMT-03:00 Tom R. [email protected]:
the qtgui sinks can only accept streams coming in at the same sample rate
From the user’s point of view, these GUI blocks actually *do *accept
streams with different sample rates, according to Gnuradio’s
idiosyncratic
“sample rate gnosticism” of blocks (correct me if I’m wrong). It is left
to
the user to know how each block consumes and generate samples. I found
helpful to think GUI blocks to consume from “one stream of tuples of n
samples” instead from “samples from n streams” (is this true for all
multiple-input blocks?).
I never looked into the code to really understand how the scheduler
deals
with this situations, but I imagine two buffers’ lengths diverging
proportional to the sample rate mismatch leading to the filling of the
fastest. I’m looking forward to GRCON15 to learn more in-depth some of
these things.
2015-08-02 17:53 GMT-03:00 Kevin McQuiggin [email protected]:
Hi Kevin,
I’m really happy about this! Hope you like the brave new C++ world 
Now, curious as I am, (and a little ashamed for not replying earlier,)
could you share your code with us?
Best regards,
Marcus