Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

[Andy Walls]

>                              From: 
> John Malsbury
>                           Subject: 
> Re: [Discuss-gnuradio] Rectangular
> Pulse Shape w/ PFB Clock Sync
>                              Date: 
> Thu, 29 Sep 2016 09:19:20 -0700
> 
> ______________________________________________________________________
> Neil,
> 
> 
> Yes. It does lock and track with those taps.  But with about 0.2-0.3
> dB of added implementation loss. 
> 
> 
> -John

You may want to experiment with different Timing Error Detectors (TEDs),
aside from Gardner's, in your original flowgraph, to see if you can do
better.

This MatLab documentation page has a nice picture of where the TED sits
in a clock recovery block, and also has the math for some popular TEDs:
http://www.mathworks.com/help/comm/ref/comm.symbolsynchronizer-class.html


FWIW, I found this thesis paper, which has a short discussion of the
popular TEDs and measuring performance of TEDs:
http://www.ece.usu.edu/grad/reports_theses_disseratations/2010/Bage_Jayaraj_Nagendra/thesis.pdf

In that thesis, the author develops a Minimum Signal Error Rate TED
(MSERTED), that has as its objective criteria to minimize the the log of
the probability of error, log(Pe).  Similar to the PFB clock sync block,
MSERTED uses a derivative of the matched filter.  MSERTED's output
includes, as a multiplier, the output of the derivative matched filter,
which would have many 0's for a square pulse filter.  You would have to
use the Rx RC filter that Neil suggested, if you wanted to try MSERTED.

Regards,
Andy


>         
>         On Wed, Sep 28, 2016 at 6:41 PM, Neil Schafer <address@hidden>
>         wrote:
>                 I haven’t tried it myself, but wouldn’t using a raised
>                 cosine or Gaussian filter for your taps still provide
>                 some pulse shaping for the PFB clock sync to track?
>                 You’re essentially leap-frogging the RRC matched
>                 filters at transmitter and receiver, and placing the
>                 entire burden at the receiver, but at the decision
>                 point of the clock synch the end result should be the
>                 same.
>                 
>                  
>                 
>                 Neil
>                 
>