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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
