Re: [Discuss-gnuradio] having another Python gateway block problem

[Josh Blum]

On 12/19/2011 07:58 AM, Paul Miller wrote:
> 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.
> 
> 

Are you positive that its not a problem with the gui sink itself. See
this bug: 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