discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Re: gr_pfb_clock_sync_ccf.cc question related to work


From: Tom Rondeau
Subject: [Discuss-gnuradio] Re: gr_pfb_clock_sync_ccf.cc question related to work function
Date: Fri, 26 Nov 2010 10:10:07 -0500

On Thu, Nov 25, 2010 at 3:38 PM, John Andrews <address@hidden> wrote:
> Thanks for replying Tom. Happy Thanksgiving to you.
>
> Although I understand the idea behind this time sync method I still
> have a question regarding your code. You increment the count variable
> by samples per symbol value. The error control loop works at one
> sample per symbol and updates the pointer to the correct subfilter.
>
> By updating the count variable by d_sps aren't we losing information
> as we are dropping d_sps - 1 samples on every iteration of for-loop in
> work function.
>
> Thanks


You're correct that we are dropping the samples, but we aren't loosing
information. At this point, we've done all we want from the samples,
so we decimate to 1 sample per symbol. Since this is the stage before
the detection/decision block, we only need the one sample.

Tom



> On Tuesday, November 23, 2010, Tom Rondeau <address@hidden> wrote:
>> On Mon, Nov 22, 2010 at 6:01 AM, John Andrews <address@hidden> wrote:
>>> I got it. The polyphase filter is implemented by having a single stage
>>> filter and choosing the right taps from the set of 'nfilts' taps rather than
>>> having nfilts filter stages. This of course is computationally more
>>> efficient.
>>
>>
>> Hi John,
>> Thanks for the question. And the answer. You had me worried for a
>> second that I had missed something in the implementation. I was pretty
>> sure I had this correct when fred and I were talking about all of this
>> stuff last summer.
>>
>> As you've surmised, the implementation pretty much follows figure
>> 13.21 in fred's book. Although he was looking at it being designed in
>> an FPGA where he had to load the registers with the coefficients;
>> instead, I just keep the bank of filter coefficients, each with their
>> own symbol phase, and select the path into the bank based on the error
>> estimate. So we select the appropriate filter path to go through and
>> run that one stage.
>>
>> It's a "neat trick" as fred likes to say.
>>
>> And yes, literalnet, I understand that we're still actually loading
>> the coefficients into registers. I'm only talking about how the C++
>> code was implemented conceptually as opposed to an FPGA design.
>>
>> Tom
>>
>>
>>
>>> On Sat, Nov 20, 2010 at 9:47 PM, John Andrews <address@hidden> wrote:
>>>>
>>>> Hi,
>>>> I was trying to understand the code of the new clock sync block
>>>> gr_pfb_clock_sync_ccf.cc and although I understand most of it there is one
>>>> particular thing that confuses me. This is what I understood so far
>>>>
>>>> 1. There are two filter banks present. A) For RRC filtering B) the
>>>> differential filter bank
>>>> 2. These filters are implemented as polyphase filters thus, each of these
>>>> filters has nfilts=32 sub-filters
>>>> 3. The theory behind this block is found in section 13.3.2 of fred harris'
>>>> book on multi-rate filters so I understand the concept behind this block
>>>> pretty well.
>>>>
>>>> What confuses me is the coding.
>>>> In line 265 of gr_pfb_clock_sync_ccf.cc
>>>>
>>>> out[i] = d_filters[d_filtnum]->filter(&in[count]);
>>>>
>>>> the input to the block is passed only to one sub-filter of each filter
>>>> bank. Why? Looking at the section in harris' book i thought it was an input
>>>> to all the sub-filters and we choose one of the outputs as the sync'd
>>>> sample.
>>>>
>>>> Thanks
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]