[srslte-users] RSRP/SINR issues with pdsch_ue

Ismael Gomez ismael.gomez at softwareradiosystems.com
Wed May 10 18:16:31 UTC 2017


Let us know how it works. When you try with the B200, pull the latest next
branch from github. I've just pushed a fix for that RSSI sensor.

I've also been reading how this RSSI sensor estimates the power and I'm
afraid isn't the most optimal solution. That sensor estimates the power
throughput all the RF bandwidth which means that very likely will see power
from neighbour cells which then invalidates the gain compensation. Maybe
calibrating for each bw/band is the only way to go.

On Wed, 10 May 2017 at 19:41 Sina Khanifar <sina at rsrf.com> wrote:

> Thanks Ismael. I'll switch to a B200, and will also test in some differing
> signal conditions to see if the RSRQ numbers stay within a +/- 2dB range.
>
> On Wed, May 10, 2017 at 10:38 AM, Ismael Gomez <
> ismael.gomez at softwareradiosystems.com> wrote:
>
>> Ok there is no RSSI sensor on that board (or if there is, we don't use
>> it) so you'll have to calibrate it manually for each band and bandwidth.
>>
>> Regarding the RSRQ I think the results you are obtaining are correct.
>> Think that you are comparing two completely different RF frontends (the
>> handset and the blade). The handset has been specifically designed for
>> certain bands (RF filters, LNA, etc.) whereas the blade is a general
>> purpose broadband frontend so you can expect +-2 dB signal quality when
>> comparing them.
>>
>>
>> On Wed, 10 May 2017 at 19:34 Sina Khanifar <sina at rsrf.com> wrote:
>>
>>> No, I'm using a Nuand bladeRF x40.
>>>>>>
>>> On Wed, May 10, 2017 at 10:26 AM, Ismael Gomez <
>>> ismael.gomez at softwareradiosystems.com> wrote:
>>>
>>>> Are you using B200/B210?
>>>>
>>>> On Wed, 10 May 2017 at 19:13 Sina Khanifar <sina at rsrf.com> wrote:
>>>>
>>>>> Hi Ismael,
>>>>>
>>>>> Thanks for the reply.
>>>>>
>>>>> > That's because the frequency response of the RF frontend is not flat
>>>>> throughout all the frequencies. That's why we use the RSSI on-chip sensor
>>>>> to compute the rf_gain_offset automatically. Have you tried that?
>>>>>
>>>>> The pdsch_ue script doesn't have the rf_gain_offset variable, but I
>>>>> switched over to testing with cell_measurement.c where that variable is
>>>>> included. Unfortunately I'm seeing similar results.
>>>>>
>>>>> Here is a summary of results using cell_measurement:
>>>>> https://www.dropbox.com/s/xxejcc0pc5u0zl3/srslte-measurements.png?dl=0
>>>>>
>>>>> As you can see, the RSRP varies from the handset measured values. For
>>>>> consistency all the handsets I am testing with are from the same vendor.
>>>>>
>>>>> > The way SINR is computed is vendor-specific so it's difficult to
>>>>> compare across devices. You can try looking at RSRQ and compare that value.
>>>>> RSRQ is a standarized equivalent metric of the SINR.
>>>>>
>>>>> If you look at the screenshot in the Dropbox link, I was actually
>>>>> seeing a similar inconsistency with the RSRQ values.
>>>>>
>>>>> Thanks again for the help,
>>>>>
>>>>> Sina.
>>>>>
>>>>> On Wed, May 10, 2017 at 4:55 AM, Ismael Gomez <
>>>>> ismael.gomez at softwareradiosystems.com> wrote:
>>>>>
>>>>>> Hi Sina,
>>>>>>
>>>>>> On Tue, 9 May 2017 at 21:38 Sina Khanifar <sina at rsrf.com> wrote:
>>>>>>
>>>>>>> Similar to the recent thread around issues with the cell_measurement
>>>>>>> thread, I'm seeing problems with the pdsch_ue example script. I've tried
>>>>>>> changing the RSRP and SINR calculations to make them better match real UE
>>>>>>> measurements. For example, I am currently using:
>>>>>>>
>>>>>>>
>>>>>> rsrp = 12*log10(rsrp/rf_gain_offset) where rf_gain_offset is set via
>>>>>>> an arg to 2e9
>>>>>>> sinr = 20*log10(sinr/noise/5)
>>>>>>>
>>>>>>> I've experimented with various values here, but continue to have
>>>>>>> issues. In particular:
>>>>>>>
>>>>>>> * The RSRP gain offset appears to vary both with frequency and the
>>>>>>> carrier signal's bandwidth. srs-lte shows higher rsrp at higher
>>>>>>> frequencies, and higher rsrp at higher bandwidths.
>>>>>>>
>>>>>>
>>>>>> That's because the frequency response of the RF frontend is not flat
>>>>>> throughout all the frequencies. That's why we use the RSSI on-chip sensor
>>>>>> to compute the rf_gain_offset automatically. Have you tried that?
>>>>>>
>>>>>>
>>>>>>> * The SINR in the default code is never negative, whereas it is
>>>>>>> often negative as measured by test UEs. It also generally doesn't match up
>>>>>>> to the UE measurements, hence my 20*log10(sinr/noise/5) adjustment. This
>>>>>>> alternative equation is still not very accurate, but at least generates
>>>>>>> some negative values.
>>>>>>>
>>>>>>
>>>>>> The way SINR is computed is vendor-specific so it's difficult to
>>>>>> compare across devices. You can try looking at RSRQ and compare that value.
>>>>>> RSRQ is a standarized equivalent metric of the SINR.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Any thoughts on what might be causing these two issues?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>>>>>>>> _______________________________________________
>>>>>>> srslte-users mailing list
>>>>>>> srslte-users at lists.softwareradiosystems.com
>>>>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>>>>>
>>>>>>
>>>>>>>>>>
>>>>
>>>>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.softwareradiosystems.com/pipermail/srslte-users/attachments/20170510/2996635e/attachment.html>


More information about the srslte-users mailing list