On Thu, Mar 29, 2007 at 08:04:22AM -0400, Greg Troxel wrote: > Eric Blossom <[EMAIL PROTECTED]> writes: > > > On Wed, Mar 28, 2007 at 09:39:14PM -0700, Dan Halperin wrote: > >> Same loopback code I emailed about earlier; this time I attached the > >> complete file (modulo some cleanup). > >> > >> Here's my input file (in stupid x86 short ordering..): > >> > >> $ hexdump input.txt > >> 0000000 bbaa ddcc ffee 1100 3322 5544 7766 9988 > >> > >> and then after going through loopback.py and being packed back to bytes: > >> > >> $ hexdump output.txt > >> 0000000 bbaa ddcc ffee 1100 3322 5544 7766 8088 > >> > > > > Regarding losing the last few symbols, try > > > > ... > > graph.wait() > > time.sleep(1) > > I wonder if there is data somewhere in the flowgraph that's less than > the amount needed for the next block to run. Perhaps there should > be some sort of drain operation, or query for this (that adds over > components), so one can find out what's going on.
It should drain completely, unless some block is specifying an output_multiple that cannot be specified. Probably the easiest way to debug this it to enable logging in gr_single_threaded_scheduler.cc. Do do that, change the ENABLE_LOGGING define on line 37 to a 1. This will create ascii file(s) named sst-N.log in the current directory. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
