Polyphase Clock Sync

Timing synchronizer using polyphase filterbanks.

This block performs timing synchronization for PAM signals by minimizing the derivative of the filtered signal, which in turn maximizes the SNR and minimizes ISI.

This approach works by setting up two filterbanks; one filterbank contains the signal's pulse shaping matched filter (such as a root raised cosine filter), where each branch of the filterbank contains a different phase of the filter. The second filterbank contains the derivatives of the filters in the first filterbank. Thinking of this in the time domain, the first filterbank contains filters that have a sinc shape to them. We want to align the output signal to be sampled at exactly the peak of the sinc shape. The derivative of the sinc contains a zero at the maximum point of the sinc (sinc(0) = 1, sinc(0)' = 0). Furthermore, the region around the zero point is relatively linear. We make use of this fact to generate the error signal.

If the signal out of the derivative filters is d_i[n] for the ith filter, and the output of the matched filter is x_i[n], we calculate the error as: e[n] = (Re{x_i[n]} * Re{d_i[n]} + Im{x_i[n]} * Im{d_i[n]}) / 2.0 This equation averages the error in the real and imaginary parts. There are two reasons we multiply by the signal itself. First, if the symbol could be positive or negative going, but we want the error term to always tell us to go in the same direction depending on which side of the zero point we are on. The sign of x_i[n] adjusts the error term to do this. Second, the magnitude of x_i[n] scales the error term depending on the symbol's amplitude, so larger signals give us a stronger error term because we have more confidence in that symbol's value. Using the magnitude of x_i[n] instead of just the sign is especially good for signals with low SNR.

The error signal, e[n], gives us a value proportional to how far away from the zero point we are in the derivative signal. We want to drive this value to zero, so we set up a second order loop. We have two variables for this loop; d_k is the filter number in the filterbank we are on and d_rate is the rate which we travel through the filters in the steady state. That is, due to the natural clock differences between the transmitter and receiver, d_rate represents that difference and would traverse the filter phase paths to keep the receiver locked. Thinking of this as a second-order PLL, the d_rate is the frequency and d_k is the phase. So we update d_rate and d_k using the standard loop equations based on two error signals, d_alpha and d_beta. We have these two values set based on each other for a critically damped system, so in the block constructor, we just ask for "gain," which is d_alpha while d_beta is equal to (gain^2)/4.

Reference:

       f. j. harris and M. Rice, "Multirate Digital Filters for Symbol Timing Synchronization in Software Defined Radios", IEEE Selected Areas in Communications, Vol. 19, No. 12, Dec., 2001. [1]

Parameters

(R): Run-time adjustable

Samples/Symbol

The clock sync block needs to know the number of samples per symbol, because it defaults to return a single point representing the symbol. The sps can be any positive real number and does not need to be an integer.

Loop Bandwidth (R)

The loop bandwidth is used to set the gain of the inner control loop (see: [2]).

This should be set small (a value of around 2pi/100 is suggested in that blog post as the step size for the number of radians around the unit circle to move relative to the error).

Taps (R)

One of the most important parameters for this block is the taps of the filter.

One of the benefits of this algorithm is that you can put the matched filter in here as the taps, so you get both the matched filter and sample timing correction in one go. So create your normal matched filter. For a typical digital modulation, this is a root raised cosine filter.

The number of taps of this filter is based on how long you expect the channel to be; that is, how many symbols do you want to combine to get the current symbols energy back (there's probably a better way of stating that). It's usually 5 to 10 or so. That gives you your filter, but now we need to think about it as a filter with different phase profiles in each filter. So take this number of taps and multiply it by the number of filters. This is the number you would use to create your prototype filter. When you use this in the PFB filerbank, it segments these taps into the filterbanks in such a way that each bank now represents the filter at different phases, equally spaced at 2pi/N, where N is the number of filters.

Filter Size

The number of filters can also be set and defaults to 32. With 32 filters, you get a good enough resolution in the phase to produce very small, almost unnoticeable, ISI. Going to 64 filters can reduce this more, but after that there is very little gained for the extra complexity.

Initial Phase

The initial phase is another settable parameter and refers to the filter path the algorithm initially looks at (i.e., d_k starts at init_phase). This value defaults to zero, but it might be useful to start at a different phase offset, such as the mid-point of the filters.

Maximum Rate Deviation

The next parameter is the max_rate_devitation, which defaults to 1.5. This is how far we allow d_rate to swing, positive or negative, from 0. Constraining the rate can help keep the algorithm from walking too far away to lock during times when there is no signal.

Output SPS

The osps is the number of output samples per symbol. By default, the algorithm produces 1 sample per symbol, sampled at the exact sample value. This osps value was added to better work with equalizers, which do a better job of modelling the channel if they have 2 samps/sym.

Example Flowgraph

Insert description of flowgraph here, then show a screenshot of the flowgraph and the output if there is an interesting GUI. Currently we have no standard method of uploading the actual flowgraph to the wiki or git repo, unfortunately. The plan is to have an example flowgraph showing how the block might be used, for every block, and the flowgraphs will live in the git repo.

Source Files

C++ files

Complex input

Float input

Header files

Complex input

Float input

Public header files

Complex input

Float input

Block definition

[3]