[srslte-users] RSRP/SINR issues with pdsch_ue

Sina Khanifar sina at rsrf.com
Wed May 10 18:57:53 UTC 2017


Looking at the data a bit more, I'm not sure it's actually an issue with
frequency calibration. If you look at the data I sent over, the biggest
deltas in RSRP are at 731.5MHz and 751MHz. But there is another reading at
a nearby frequencies (e.g. 739MHz) where the delta is very small.

The only other difference between those readings is the bandwidth. But
there doesn't seem to be much correlation between the bandwidth and the
RSRP delta from measured either. There are larger deltas at 1900MHz,
2.3GHz, and 750MHz, and also larger deltas at 5MHz, 10MHz and 20MHz
bandwidths. But there are also normal readings at all six frequencies and
bandwidths.

That makes me suspect that something else might be causing the issue.

On Wed, May 10, 2017 at 11:16 AM, Ismael Gomez <ismael.gomez@
softwareradiosystems.com> wrote:

> 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/396014fb/attachment-0001.html>


More information about the srslte-users mailing list