LTE 15MHz downsampling question

I have an fpga based digital down converter for LTE 5,10,15,20 MHz.

Due to this multiple bandwidths we have adopted a method whereby lte 15MHz
is processed as follows:

step 1: downsample the signal from 122.88 Msps to 30.72 Msps.
step 2: add two zeros after every sample.
step 3: downsample by 2
step 4: downsample by 2

ending up with the LTE 15MHz at chiprate of 23.04Msps. This works, no
problem.

Now I need to modify the system clock but faced the problem of not being
able to insert the two zeros after every sample in a convenient way.

So I thought of doing the following steps:
step1 : as above
step2 : downsample by 2
step3 : insert two zeros
step4 : as above ending up at chiprate of 23.04 Msps

According to my modeling, it seems ok but there is one anomaly: After step
2 the sampling rate becomes 15.36Msps (lte15 is 23.04). It does not
violate
sampling theorem since baseband extends from 0~6.75MHz.

Any thoughts please?

Kadhiem

On Thursday, January 31, 2013 11:58:02 AM UTC-8, kaz wrote:
> I have an fpga based digital down converter for LTE 5,10,15,20 MHz.
...
> 
> Now I need to modify the system clock but faced the problem of not being
> able to insert the two zeros after every sample in a convenient way.
> 
...
> Any thoughts please?
> 
> Kadhiem

It sounds as if you see the "insert two zeros" as an operation that is actually performed. (Otherwise, why would you need a convenient way to do it?) Does your implementation write zeros to ram, later read them and multiply by a coefficient and add the product (zero) to an accumulator in a filter calculation? If so, why? Are you required to use a library direct form FIR function that requires the zeros to be there instead of a poly-phase FIR implementation that would avoid the useless multiply-by-zeros?

Dale B. Dalrymple

the oversampling rate of your 15 MHz signal seems rather low, this may
become a problem.
For example: LTE20 utilizes 18 MHz, in 30.72 MSPS  is oversampled by 1.7 =>
everything is fine.
Now: LTE15 utilizes 13.5 MHz (in other words: 2 x 6.75 MHz: 900 subcarriers
with 15 kHz each), in 15.36 MHz, is oversampled by 1.13 => may require
longer filters in comparison.
Now I'm not really sure that I understood you correctly.

>On Thursday, January 31, 2013 11:58:02 AM UTC-8, kaz wrote:
>> I have an fpga based digital down converter for LTE 5,10,15,20 MHz.
>...
>>=20
>> Now I need to modify the system clock but faced the problem of not
being
>> able to insert the two zeros after every sample in a convenient way.
>>=20
>...
>> Any thoughts please?
>>=20
>> Kadhiem
>
>It sounds as if you see the "insert two zeros" as an operation that is
actu=
>ally performed. (Otherwise, why would you need a convenient way to do it?)
=
>Does your implementation write zeros to ram, later read them and multiply
b=
>y a coefficient and add the product (zero) to an accumulator in a filter
ca=
>lculation? If so, why? Are you required to use a library direct form FIR
fu=
>nction that requires the zeros to be there instead of a poly-phase FIR
impl=
>ementation that would avoid the useless multiply-by-zeros?
>
>Dale B. Dalrymple
>

The design is not according to standard solutions of zero insertion ideas
of upsampling. Yes I do physically have to insert two zeros and pass the
new stream into down 2.

In other words I exploit the decimate by 2 filters available already in the
chain and use for lte15 without extra cost. For this to work I have to
upsample lte15 by 3 by just zero insertion and pass it through decimate by
2 then another decimate by 2 implying 3/4 fractional downsampling.

Kadhiem
 

>the oversampling rate of your 15 MHz signal seems rather low, this may
>become a problem.
>For example: LTE20 utilizes 18 MHz, in 30.72 MSPS  is oversampled by 1.7
=>
>everything is fine.
>Now: LTE15 utilizes 13.5 MHz (in other words: 2 x 6.75 MHz: 900
subcarriers
>with 15 kHz each), in 15.36 MHz, is oversampled by 1.13 => may require
>longer filters in comparison.
>Now I'm not really sure that I understood you correctly.
>
>

Use a polyphase filter to resample the signal at whatever convenient rate
is necessary.

-Doug

>the oversampling rate of your 15 MHz signal seems rather low, this may
>become a problem.
>For example: LTE20 utilizes 18 MHz, in 30.72 MSPS  is oversampled by 1.7
=>
>everything is fine.
>Now: LTE15 utilizes 13.5 MHz (in other words: 2 x 6.75 MHz: 900
subcarriers
>with 15 kHz each), in 15.36 MHz, is oversampled by 1.13 => may require
>longer filters in comparison.
>Now I'm not really sure that I understood you correctly.
>
>

Well we downsample each of 5,10,15,20 MHz lte each received at 122.88Msps
to its chiprate of 7.68, 15.36, 23.04, 30.72 using a shared chain of 4
decimate by 2 filters followed by final channel filter:

lte 20 passes through dec1 and dec2 only(/4).
lte 10 passes through dec1,2,3 (/8).
lte 5  passes through dec1,2,3,4 (/16)
lte 15 is the odd fellow. In our legacy systems it is passed just like lte
5 but two zeros are added as I mentioned.

In case of non ofdm based signals e.g. cdma we cannot naturally go below
its chiprate as we will violate sampling rule. But for ofdm the bandwidth
occupied is relatively less and I don't see any reason why I can't go below
lte chiprate provided I don't violate sampling rule and don't introduce
extra aliasing of noise.

So let me reword my question: can I temporarily in my processing go below
23.04 to 15.36 sampling rate for lte 15MHz then back to its intended rate
of 23.04 or would this lead to some other issues. I can see frequency
domain and time domain very close in both cases according to my modelling.

Kadhiem

>>the oversampling rate of your 15 MHz signal seems rather low, this may
>>become a problem.
>>For example: LTE20 utilizes 18 MHz, in 30.72 MSPS  is oversampled by 1.7
>=>
>>everything is fine.
>>Now: LTE15 utilizes 13.5 MHz (in other words: 2 x 6.75 MHz: 900
>subcarriers
>>with 15 kHz each), in 15.36 MHz, is oversampled by 1.13 => may require
>>longer filters in comparison.
>>Now I'm not really sure that I understood you correctly.
>>
>>
>
>Use a polyphase filter to resample the signal at whatever convenient rate
>is necessary.
>
>-Doug
>

Unfortunately I can't. I already got a chain of filters in the system and
limited resource and can only think of using available chain. We are
dealing with multiple diversities and the size
of resource shoots up quickly.

Kadhiem

Kadhiem

kaz <37480@dsprelated> wrote:

(snip)

> Well we downsample each of 5,10,15,20 MHz lte each received at 122.88Msps
> to its chiprate of 7.68, 15.36, 23.04, 30.72 using a shared chain of 4
> decimate by 2 filters followed by final channel filter:
 
> lte 20 passes through dec1 and dec2 only(/4).
> lte 10 passes through dec1,2,3 (/8).
> lte 5  passes through dec1,2,3,4 (/16)
> lte 15 is the odd fellow. In our legacy systems it is passed just like lte
> 5 but two zeros are added as I mentioned.

My first thought when given the need to decimate by 2, 4, 8, or 16
would be two decimate by four and one decimate by two. That means
at most two will get you all four rates. 

That may or may not help with the other problem.

-- glen

>kaz <37480@dsprelated> wrote:
>
>(snip)
>
>> Well we downsample each of 5,10,15,20 MHz lte each received at
122.88Msps
>> to its chiprate of 7.68, 15.36, 23.04, 30.72 using a shared chain of 4
>> decimate by 2 filters followed by final channel filter:
> 
>> lte 20 passes through dec1 and dec2 only(/4).
>> lte 10 passes through dec1,2,3 (/8).
>> lte 5  passes through dec1,2,3,4 (/16)
>> lte 15 is the odd fellow. In our legacy systems it is passed just like
lte
>> 5 but two zeros are added as I mentioned.
>
>My first thought when given the need to decimate by 2, 4, 8, or 16
>would be two decimate by four and one decimate by two. That means
>at most two will get you all four rates. 
>
>That may or may not help with the other problem.
>
>-- glen
>

No it doesn't help. These are all options but the system is done years ago
and is at customer premises in thousands of units. We need to upgrade
remotely so we don't have much choices to redesign but we are adding extra
features. 

decimate by 4 in one step could be less efficient than 2 by 2 depending on
many considerations. 

Kadhiem

>> go below its chiprate 

I don't have any problems with that idea.
What you call "chiprate" has no physical meaning in LTE. It results from
using the standard FFT sizes (i.e. I can just as well use a 2049 bin FFT
instead of 2048 bins in LTE20. The required input rate becomes 2049 / 2048
* 30.72 MHz, and the result is indistinguishable).

If it's a receiver, watch out for adjacent channels that alias somewhere
along the way (for the wanted signal it seems OK but is the bandwidth of
the signal really as clear-cut?)

The quantization noise floor of your now-lower-rate processing may creep up
a little, in comparison.