Re: [Discuss-gnuradio] loopback dropping final bits

[Eric Blossom]

On Thu, Mar 29, 2007 at 06:27:24PM -0700, Dan Halperin wrote:
> Eric Blossom wrote:
> > On Thu, Mar 29, 2007 at 05:16:45PM -0700, Dan Halperin wrote:
> >   
> >> Since this block initially starts with 0 inputs and is not filled with
> >> other data following the run of the program, the last <10 samples are
> >> left in the flow graph. This could well be the problem with the last
> >> bits of the last packet always being dropped/corrupted, because if you
> >> were using queues and enqueued a message followed by a close_queue
> >> packet, they could well get shipped through the pipeline together.
> >>
> >> This is where my expertise runs out; what's the right fix? Is it
> >> block-specific (either pre-pend 0s or detect the end of data and append
> >> 0s), or more general?
> >>
> >> -Dan
> >>     
> >
> > Try applying this patch.  It has the effect of preloading ntaps()-1
> > zero's into the block's input stream.
> >
> > Eric
> >
> >
> > --- gr_clock_recovery_mm_ff.cc      2006-12-20 10:40:57.000000000 -0800
> > +++ /tmp/gr_clock_recovery_mm_ff.cc 2007-03-29 17:59:42.000000000 -0700
> > @@ -61,6 +61,8 @@
> >    set_omega(omega);                        // also sets min and max omega
> >    set_relative_rate (1.0 / omega);
> >  
> > +  set_history(d_interp->ntaps());
> > +
> >    if (DEBUG_CR_MM_FF)
> >      d_logfile = fopen("cr_mm_ff.dat", "wb");
> >  }
> >   
> 
> No; this appears to at least shift and likely corrupt the bits [I got
> abba cdbc efde 01f0 2312 4534 6756 8878 instead of bbaa ddcc ffee 1100
> 3322 5544 7766 9988].

You know, the short format you're using isn't really helping seeing
what's going on...  See attached files for a suggestion.  Or print
the output in binary.

> If I add an extra 0 byte at the end, these bits
> come through, but then the last 5 of that next byte do not. Maybe the
> flow graph needs to do something like:
> 
>     At a disruption of continuity of the input (EOF, USRP goes into TX
> mode, etc),
>     append enough 0 samples to clear the pipeline, reinitialize all (or
> selected...) flow graph blocks
>     to their virgin state, and then continue.
> 
> The counter-argument is that when receiving symbols from a stream (like
> off the USRP), this won't be a problem since the source is continuous -
> even if it flips into TX mode, if all samples of the data are there, the
> symbols will be recovered when the pipeline restarts. Maybe that means
> file sources violate some GNU Radio invariant...

Finite sources such as the gr.file_source are the corner case.  I'm
not sure I want to mess with the underlying code over this.  On the
other hand, we may see more of this when we embed flow graphs in
mblocks, and if so, we'll need to revisit the "flush" and "reset"
options.

I'm open for discussion and patches that address this.

Eric

hexbytes
Description: Text document

hexbytes.fmt
Description: Text document