discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Channel Model Block; 'epsilon'


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Channel Model Block; 'epsilon'
Date: Wed, 28 Dec 2011 22:23:18 -0500

On Mon, Dec 26, 2011 at 7:42 AM, Uzair Baig <address@hidden> wrote:
I am confused about the channel model block:

It needs the following parameters:

Creates a channel model that includes:
- AWGN noise power in terms of noise voltage
- A frequency offest in the channel in ratio
- A timing offset ratio to model clock difference (epsilon)
- Multipath taps

The 'epsilon' in particular is confusing. I have referred, it represents the inverse of the fractional interpolation ration. Now, firstly I need to know,
whether this parameter will cause delay between the Tx and Rx path ? I have tried working my way with the frac_interp_ff block and recognize, that
it doesn't return the same number of samples to me? For a value of 1, the number of samples input are more than the number of samples output!

It does a sample rate change to model the difference in the clock sampling rates between real systems. For a value of 1, there is no rate change. Are you sure you're getting a different number of samples out than you put in for this block? That's not how it's supposed to work. 

It's simulating how when the transmitter sends a sample at time T, the receiver will sample it at time T+delta(t), where delta(t) is a function of time (if this were just T+delta, you can simulate that by setting just the initial phase of the fractional interpolator).
 

Doesnt the interpolation mean an increase in the number of samples?
Yes, technically. The block is really constructed as a gr_block, which allows it to have any rate change required.  Perhaps calling it fractional interpolator was a bit of a misnomer, but it probably fit the original, intended use better. But it can behave as a decimator, too (although that is technically incorrect since decimate really means to reduce by 10). Maybe a better name would have been "fractional_rate_changer" or something.
 
Secondly, I have connected this channel model to polyphase filter banks for clock recovery. I don't get a correct output if I increase epsilon? And another thing, can you please share as to what does each parameter filter bank imply? ( I have read the documentation, but, cannot make much sense of it).

Regards,

UB

Well, you're not the first to have trouble with that block. I wrote the documentation for those PFB blocks, and they are about as detailed as you get in GNU Radio right now. Seems like I spent more time discussing the theory of their operation rather than how to actually use the damn things.

First, I've done exactly what you're doing and haven't had a problem, so the issue must be in the parameters you are using. What setting are you using for epsilon? Remember, this is supposed to simulate a timing offset between two clocks, so we're talking the difference in the parts per million. Tens of ppm at the most extreme. I've used the PFB clock recovery block to recovery a bit stream where the clocks were off by as much as 10%. If you're ever working with a clock that is that bad, just throw it away :)

Second, the parameters of the PFB have to be set right. I will assume that the 'sps' (samples per symbol) is pretty obvious. The loop bandwidth is used to set the gain of the inner control loop (see: http://gnuradio.squarespace.com/blog/2011/8/13/control-loop-gain-values.html). 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).

The filter size is the number of banks in the filterbank. This defaults to 32, and you probably don't need any better (for single-precision floating point numbers, you won't get much of a gain beyond this). The init_phase is which bank to start off with. This really doesn't matter as it's the algorithms job to find and track this. The max_deviation caps how fast the algorithm can move. The default of 1.5 is generous, but keeps the algorithm from going too crazy when given bogus input.

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 modeling the channel if they have 2 samps/sym.

That leaves 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.

The algorithm works by finding the phase that minimizes the derivative of this filter and tracks any changes, so the filter itself is centered on the symbol itself and the filtering operation takes this and the energy of this symbol present in the surrounding symbols together. The ISI is minimized at this point; it's value is at most related to the half of the maximum possible phase difference between two banks in the filterbank.

I'm going to take what I wrote here and add it to the documentation for the file. I hope it clears some things up for everyone.

Tom


reply via email to

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