# Having another Python gateway block problem **URL:** \ **Category:** GNU Radio\ **Created:** [December 19, 2011, 4:59pm UTC](https://www.ruby-forum.com/t/having-another-python-gateway-block-problem/215017 "2011-12-19T16:59:23Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [December 19, 2011, 4:59pm UTC](https://www.ruby-forum.com/t/having-another-python-gateway-block-problem/215017/1 "2011-12-19T16:59:23Z")
If I’m doing something dumb, I can’t find it. Happens all the time though. I’m using the python\_blocks branch 5cd66eef8ab8a81589dc08a134457d15b431434e . I made a really simple sync\_block that square-waves an input signal. I have a fancy block that does all kinds of things and I think it’s having the same sorts of trouble, but that thing’s all big. This cute little block demonstrates the problem nicely. Basically, what I’m seeing is that in QA tests with vector sinks, everything runs all peachy and everything lines up. All set. But when I run my sync\_blocks against a WX Scope, nothing lines up right. It’s much less obvious when the input signal is well behaved. I imagined it was just lagging by a few items, but when I mixed two non-harmonic waves, it was very clear that the gateway block just didn’t match up at all. I have attached the block, a grc connector xml, the QA I used to show that this doesn’t happen with vector sinks, the gnuradio companion diagram (png) and the gnuradio companion source file I’m using. (I hope attaching isn’t rude on this list… if it is, sorry in advance.) The GRC program also has an add\_const block in there (select with variable). Note that add\_cost lines up perfectly, like we expect but no amount of twiddling the connections (moving throttles, removing switches, etc) will get the square-waver to line up with the input signal. ---
**Author:** ![Paul\_Miller](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/57b2e6/32.png) [@Paul\_Miller](https://www.ruby-forum.com/u/Paul_Miller)\ **Post date:** [December 19, 2011, 7:55pm UTC](https://www.ruby-forum.com/t/having-another-python-gateway-block-problem/215017/2 "2011-12-19T19:55:04Z")
On 12/19/2011 07:58 AM, Paul Miller wrote: > everything runs all peachy and everything lines up. All set. > I’m using. (I hope attaching isn’t rude on this list if it is, > sorry in advance.) > > The GRC program also has an add\_const block in there (select with > variable). Note that add\_cost lines up perfectly, like we expect > but no amount of twiddling the connections (moving throttles, > removing switches, etc) will get the square-waver to line up with > the input signal. Are you positive that its not a problem with the gui sink itself. See this bug: [http://gnuradio.org/redmine/issues/464](http://gnuradio.org/redmine/issues/464) One way around it would be to feed both float signals into a float to complex. The wxgui sink block will not mess with the alignment of the real/imag channels in a complex stream. See if that makes a difference. -Josh ---
**Author:** ![Paul\_Miller](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/57b2e6/32.png) [@Paul\_Miller](https://www.ruby-forum.com/u/Paul_Miller)\ **Post date:** [December 20, 2011, 12:16am UTC](https://www.ruby-forum.com/t/having-another-python-gateway-block-problem/215017/3 "2011-12-20T00:16:42Z")
On Mon, Dec 19, 2011 at 10:54:02AM -0800, Josh B. wrote: > Are you positive that its not a problem with the gui sink itself. See > this bug: [http://gnuradio.org/redmine/issues/464](http://gnuradio.org/redmine/issues/464) > One way around it would be to feed both float signals into a float to Yeah, that’s the problem, thanks. The work around works, suggesting the bug is the problem. I never would have found that bug had I looked, since I’ve never seen it with other blocks. Does this bug depend on what’s feeding in? Did I just get lucky? – If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.