On Tue, 2009-03-24 at 11:59 -0400, Dan Tarr wrote: > Thanks again for any help on this, I'm basically hitting my head against a > brick wall.
What is happening is that the data coming out of the demodulator no longer has the same byte boundaries as the data going into the modulator. Your output files are bit-shifted. In your script using the quadrature demodulator, just take out the channel model. It will work (I've verified this.) The channel model contains a block (the fractional interpolator) that can delay outputting samples during startup, that is, it might eat a few bits on the input before it starts outputting samples. So, when you have the channel model in place, the slicer bits are missing the first four bits, and the repacker is placing the next four bits at the start of the byte. So that will get your artificial example working, but also understand that during "real" reception, your receiver will need to handle arbitrary bit offsets like this. Generally, in data transmission systems, this is handled by having a frame sync word or flag, which, when detected, indicates the next bit is the start of the data boundary. By the way, I debugged this by attaching file sinks to each of the blocks in your flowgraph and viewing them using Octave, where it became obvious what was happening. Johnathan _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio