On Thu, Dec 01, 2005 at 01:59:23PM -0500, [EMAIL PROTECTED] 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
