# Solved! Repeat Block/New Repeat Block **URL:** \ **Category:** GNU Radio\ **Created:** [August 2, 2015, 4:47pm UTC](https://www.ruby-forum.com/t/solved-repeat-block-new-repeat-block/242849 "2015-08-02T16:47:48Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\ **Post date:** [August 2, 2015, 4:47pm UTC](https://www.ruby-forum.com/t/solved-repeat-block-new-repeat-block/242849/1 "2015-08-02T16:47:48Z")
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 ---
**Author:** ![Kevin\_McQuiggin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/d6d6ee/32.png) [@Kevin\_McQuiggin](https://www.ruby-forum.com/u/Kevin_McQuiggin)\ **Post date:** [August 2, 2015, 7:26pm UTC](https://www.ruby-forum.com/t/solved-repeat-block-new-repeat-block/242849/2 "2015-08-02T19:26:41Z")
On Sun, Aug 2, 2015 at 10:46 AM, Kevin McQuiggin [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![Kevin\_McQuiggin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/d6d6ee/32.png) [@Kevin\_McQuiggin](https://www.ruby-forum.com/u/Kevin_McQuiggin)\ **Post date:** [August 2, 2015, 10:54pm UTC](https://www.ruby-forum.com/t/solved-repeat-block-new-repeat-block/242849/3 "2015-08-02T22:54:42Z")
> 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 ---
**Author:** ![Kevin\_McQuiggin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/d6d6ee/32.png) [@Kevin\_McQuiggin](https://www.ruby-forum.com/u/Kevin_McQuiggin)\ **Post date:** [August 3, 2015, 2:47am UTC](https://www.ruby-forum.com/t/solved-repeat-block-new-repeat-block/242849/4 "2015-08-03T02:47:49Z")
🙂 (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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > 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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![Kevin\_McQuiggin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/d6d6ee/32.png) [@Kevin\_McQuiggin](https://www.ruby-forum.com/u/Kevin_McQuiggin)\ **Post date:** [August 3, 2015, 9:47am UTC](https://www.ruby-forum.com/t/solved-repeat-block-new-repeat-block/242849/5 "2015-08-03T09:47:17Z")
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