[srslte-users] RSRP/SINR issues with pdsch_ue

Sina Khanifar sina at rsrf.com
Wed May 31 03:44:37 UTC 2017


I bought the B200 and did more testing, both at home and in our office
(i.e. two unique signal environments).

My tabulated results are here
<https://www.dropbox.com/s/d8cblch03mpzos4/srsLTE%20Signal%20Testing%20Results.xlsx?dl=0>
in
XLS format.

A few notes from the results with the B200:
- SINR is more accurate compared to the BladeRF.
- RSRP seems to be of similar accuracy to the BladeRF.
- RSRQ seems to be of similar accuracy to the BladeRF.
- The RSRP ratings seemed to jump up and down by about 10dB in three of the
readings I took. I'm not sure what would cause this, perhaps this is an
internal automatic gain control stepping up and down? Strangely this jump
seemed to also affect SINR, which should be a relative measurement, and
thus not affected if it is an AGC issue.

Overall:
- Difference between measured and actual RSRP: 96.8dB to 131.6dB (34.8dB
range) for BladeRF, and 54.5dB to 89.1dB (34.6dB range) for B200.
- Both ranges are too large to use srsLTE as a signal strength meter.
- Difference between measured and actual RSRQ: -5.1dB to 0.6dB (5.5dB
range) for BladeRF, and -2.4db to 4.1dB (6.5dB range) for B200.
- Both ranges are too large to use srsLTE as an RSRQ meter.
- Difference between measured and actual SINR: -4.1dB to 31dB (35dB range)
for BladeRF, and -8dB to 12dB (20dB range) for B200.
- BladeRF cannot be used for SINR measurements, but B200 is more in line
with measured numbers.

Of course the ranges don't give a very accurate picture of what is going
on, there are one or two outliers that are skewing the results. And while I
can't rule out an issue with my test devices, they are all Samsung units,
and the discrepancies between measured and actual values aren't limited to
just one or more of the units, so I think there must be some sort of issue
coming from srsLTE's end.

Happy to work with you if there is hope of fixing whatever is causing the
issues.


On Thu, May 18, 2017 at 11:36 AM, Sina Khanifar <sina at rsrf.com> wrote:

> I went through and did some more testing, this time in a different signal
> environment, but still with the BladeRF.
>
> The results showed the same incomsistency, but the most interesting result
> was when testing with T-Mobile with a nearby femtocell running on the AWS-1
> band. The UE-measured RSRP was -58.5dBm, but the bladerF measured value was
> fixed at 38.3 dBm, which was a large (20dB) offset from the correct value.
> srsLTE's SINR was also maxed out at 9dB (while the UE measured 30dB). It
> seems like the bladeRF doesn't handle stronger RSRP values well.
>
> My tabulated results are here
> <https://www.dropbox.com/s/poiho9c9o3k0vuv/bladeRF%20Signal%20Testing%20Results.xlsx?dl=0>
> .
>
> I've also purchased an Ettus B200 and will test will that device next.
>>
> *Sina Khanifar |* RSRF.com <https://www.rsrf.com> | (949) 878-8202 |
> LinkedIn <http://www.linkedin.com/in/sinakhanifar>
>
> On Wed, May 10, 2017 at 11:57 AM, Sina Khanifar <sina at rsrf.com> wrote:
>
>> 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 at 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/20170530/991813c5/attachment-0001.html>


More information about the srslte-users mailing list