# GNU Radio loop bandwidth normalization

From GNU Radio documentation, the control_loop block proposes loop bandwidth values in the range $$[\frac{2\pi}{200}, \frac{2\pi}{100}]$$ in radians per sample.

Some blocks, like the new timing symbol sync block recommends a value around $$2\pi\cdot 0.040$$. Given sample rate $$R_{sample}$$ and symbol rate $$R_{symbol}$$, the symbol rate can be expressed in radians per sample as

$$2\pi\frac{ R_{symbol}}{R_{sample}} = \frac{2\pi}{N}$$

where $$N$$ is the oversampling ratio is samples per symbol. From literature, the loop bandwidth around a few percentages of the symbol rate (say 3% for example) is recommended.

I have a problem in relating the recommended control_loop values to the values suggested in the literature. Suppose for example the signal is oversampled by a factor of $$N = 100$$ samples per symbol.

A loop bandwidth value of say $$\frac{2\pi}{100}$$ will be equivalent to 100% of the symbol rate, which doesn't seem to be logical. The same loop bandwidth will be equivalent to 3% for an oversampling factor of $$N = 3$$.

I think that the ratio between the loop bandwidth and the symbol rate depends on $$N$$. For example, in the figure below, I don't think a loop bandwidth of $$\frac{2\pi}{100}$$ would mean the same thing to the FLL and the PFB ($$N = 4\,\text{sps}$$) as it will to the Costas loop ($$N = 1\,\text{sps}$$).

• Why don't the recommended values in control_loop take N into account?
• How can the loop bandwidth in GNU Radio synchronization be configured as a percentage of the symbol rate?

"How can the loop bandwidth in GNU Radio synchronization be configured as a percentage of the symbol rate?"

The tracking loop in the symbol synchronizer block operates at the symbol rate, estimating timing error and making a correction once per symbol. So the sample rate of the error signal from the TED is at approximately 1 sample/symbol. (I say approximately, because technically the block is continually estimating symbol clock error and adjusting its estimate of the symbol clock period, but its objective, nominal operating rate is 1 error sample/symbol.)

This means that in terms of normalized digital radian frequency, $$\omega T_s$$, for the loop filter, the symbol frequency corresponds to $$2\pi$$ radians/symbol.

The loop bandwidth parameter of the symbol synchronizer block is expected in units of the normalized digital radian frequency. So when one specifies $$\dfrac{2\pi}{200}$$ for $$\omega_n T_s$$, one is specifying an approximate one-sided loop filter bandwidth of $$2\pi \cdot 0.5\%$$ radians/symbol, a one-sided filter bandwidth that is $$0.5\%$$ of the symbol frequency.

To express the loop bandwidth input of the symbol synchronizer block as a percentage of the symbol frequency, just use

$$\mbox{(one-sided) loop bandwidth} = \omega_n T_s = 2\pi \cdot n\%$$

• Just to be sure, can we still assume that the sample rate of the tracking loop is around (nominally) 1 sample/symbol even in the case the output sample per symbol is not 1? I mean, in some cases, I tend to use output SPS as 2 when there is an equalizer, as shown in the diagram. – Moses Browne Mwakyanjala Dec 2 '18 at 20:36
• Yes. Having the symbol synchronizer block set to 2 or 3 or higher output samples per symbol does not affect the internal error estimation and correction. That still happens at 1 sample/symbol. – Andy Walls Dec 2 '18 at 21:01
• I should mention, that you must properly specify the expected TED gain for your chosen TED and conditioned input signal, otherwise the loop bandwidth you specify won't actually be correct. This is also true for the Polyphase Clock Sync block, but it has no way to specify the TED gain and treats it as $1.0$. The Polyphase Clock Sync block also defaults to an extremely overdamped loop. – Andy Walls Dec 2 '18 at 21:17
• See slide 12 of gnuradio.org/wp-content/uploads/2017/12/… , and note that $K_{pd}$ is the TED gain. The loop filter gain terms, $\alpha$ and $\beta$, won't get set properly, if the TED gain is incorrect. – Andy Walls Dec 2 '18 at 21:21