[srslte-users] RSRP/SINR issues with pdsch_ue

Ismael Gomez ismael.gomez at softwareradiosystems.com
Wed May 10 17:38:27 UTC 2017


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/34b33631/attachment.html>


More information about the srslte-users mailing list