Project

General

Profile

Actions

Bug #4468

open

"RSSI offset" default of 0 is not useful

Added by laforge about 4 years ago. Updated over 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/21/2020
Due date:
% Done:

80%

Spec Reference:

Description

The "rssi offset" value that can be configured via the VTY and command line arguments is initialized to a default of 0.

This does not work out at all, at the very least it's proven to be bogus on the popular USRP B2xx hardware in DCS 1800 (See #4467). I would acually be surprised if it's correct on any hardware at all.

In an ideal world, every GPSDR vendor would ship every unit together with a proper calibration table over frequency, so that a power level as seen in the I/Q samples can be translated into an absolute value in dBm.

However, the world is far from ideal, and the best we can do is try to measure this offset for the few commonly used devices we have available (B200, B210, N200, LimeSDR-mini, LimeSDR USB) and then use that value instead of '0'.

We may need a value per band (particularly on LMS where different bands go thorugh different RF paths), and it will of course also change depending on how the hardware receive gains/LNAs are configured. Also, it will drift over frequency within the band, and it will of course have a spread across different units of a given device type.

However, I guess anything is better than "0" at this point.


Files

osmo-trx-calib.gnumeric osmo-trx-calib.gnumeric 7.96 KB laforge, 03/22/2020 06:35 PM

Related issues

Related to OsmoBTS - Bug #4467: bad voice quality in current osmo-bts-trx masterClosed03/20/2020

Actions
Related to OsmoTRX - Bug #3949: osmo-trx-lms: improve runtime gain setting (missing calibration)New04/23/2019

Actions
Related to OsmoTRX - Feature #4583: generate tx-power correlation table values for different sdr boardsResolvedpespin06/05/2020

Actions
Actions #1

Updated by laforge about 4 years ago

  • Related to Bug #4467: bad voice quality in current osmo-bts-trx master added
Actions #2

Updated by laforge about 4 years ago

  • Related to Bug #3949: osmo-trx-lms: improve runtime gain setting (missing calibration) added
Actions #3

Updated by laforge about 4 years ago

I've done some initial measurements on a B210 at ARFCN 871, using my Racal 6113 BTS tester.

Using the default RxGain value of 38 (half of the maximum value 76), a RSSI offset of 28 renders correct RxLev vlaues.

It needs to be determined how much this is influenced by frequency, gain, and spread across B2xx units.

Actions #4

Updated by laforge about 4 years ago

I took some more measurements with two different B210 units and one LimeSDR-USB at different sides of the 900 MHz and 1800 MHz bands.

  • USRP spread between B210 units is < 1 dB, i.e. neglectible
  • rssi-offset for B210 in 1800 MHz should be "rxGain - 11"
  • rssi-offset for B210 in 900 MHz should be "rxGain - 7.5"
  • rssi-offset for LimeSDR-USB in 1800MHz should be "rxGain - 17" (assuming LNAW)
  • rssi-offset for LimeSDR-USB in 900MHz should be "rxGain - 6" (assuming LNAL)

Attaching detailed measurements as gnumeric spreadsheet.

So the best approach would probably be to dynamically adjust the rssi-offset every time the RxGain is being set.

The question is a bit how to do this properly in a way that
  1. we have sane defaults
  2. the user can still add an additinonal offset to express e.g. that he's added an external LNA / RF frontend
  3. we remain backwards-compatible with previous config file / command line argument semantics
So what about:
  • if the existing rssi-offset is given via command line or vty, behavior remains as is
  • we introduce a new vty command rssi-offset mode (absolute|relative)
    • absolute is the old behavior, where the user-provided value is used as-is, irrespective of gain
    • relative is the new behavior, where the user-provided value (default:0) is applied relative to the device+band specific default values (see my maasurements for 900+1800 above)
Actions #5

Updated by laforge almost 4 years ago

  • Related to Feature #4583: generate tx-power correlation table values for different sdr boards added
Actions #6

Updated by laforge almost 4 years ago

pespin, would be great to get this wrapped up

Actions #7

Updated by pespin over 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 20 to 80

I submitted a patch implementing what was described in this ticket:
https://gerrit.osmocom.org/c/osmo-trx/+/20639

Actions #8

Updated by pespin over 3 years ago

  • Assignee changed from pespin to Hoernchen

Patch implementing the described approach have been merged.

Still, it's still unclear what's the best way to implement that in osmo-trx-ipc. Either we retrieve the rssiOffset from the IPC Driver or we expected the received bursts from it to always be rssiOffset=0. I'd welcome some feedback from Hoernchen on this topic.

Actions #9

Updated by laforge over 3 years ago

On Wed, Oct 14, 2020 at 11:28:29AM +0000, pespin [REDMINE] wrote:

Still, it's still unclear what's the best way to implement that in osmo-trx-ipc. Either we retrieve the rssiOffset from the IPC Driver or we expected the received bursts from it to always be rssiOffset=0. I'd welcome some feedback from Hoernchen on this topic.

the radio heads which are the current target for osmo-trx-ipc all have calibrated radios,
unlike a GP-SDR device.

So IMHO all that is needed to know is a single value defining the
fixed relationship of 'how many dBm (absolute received power level)
corresponds to full scale of your I/Q samples, i.e. the highest value you can receive from
the ADC'.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)