[srslte-users] RSRP/SINR issues with pdsch_ue

Sina Khanifar sina at rsrf.com
Thu May 18 18:36:13 UTC 2017


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/20170518/05f2b1e8/attachment.html>


More information about the srslte-users mailing list