Re: [Discuss-gnuradio] Help using simple_framer and simple_correlator

[Eric Blossom]

On Thu, Dec 01, 2005 at 01:59:23PM -0500, address@hidden wrote:
> On Wed, 30 Nov 2005 15:15:17 -0800, Eric Blossom wrote:
> > You might want to consider looking at the .h file too...
> 
> Yep, looking at .h helped but raised a question.  In the
> gr_simple_correlator.h
> 
> inline int slice (float x)
>   {
>     return x >= d_avg ? 1 : 0;
>   }
> 
> which makes more sense to compare to the average, but in .cc you also have
> 
> inline static int slice (float x)
> {
>   return x >= 0 ? 1 : 0;
> }
> 
> Which one is used in the call
> 
> decision = slice (in[n]);
> 
> in the general_work?

Thanks for pointing out the old code.  I've removed it in CVS.
The one that's used is the one that's a method.  

> Thanks on the explanation of the bit counter.  From the call to it, I get
> that it counts how many bits in the stream match the GRSF_SYNC code.

Actually, it counts the number of bits that *don't match* the code.
That is, the Hamming distance between the current contents of the
shift register and the SYNC code.  Note the xor operator (^).  If the
shift register exactly matches the SYNC code, the xor returns 0, which
has 0 bits set.

> I still don't get how the oversampled data gets used.  I would think that
> d_shift_reg would get the average value of the input over the oversampled
> period.  I don't see how the code does that.

There are 8 separate shift registers, one for each of the oversampled
alignments.  Note how in the ST_LOOKING state, the decision is
shifted into d_shift_reg[d_osi], and d_osi is updated at the bottom of
the loop.  This means that each subsequent decision goes into a
different shift register.  d_osi is always in the range [0, 7].

You might want to try drawing this out by hand and simulating on paper.

Eric