Bug #3823

osmo-bts-oc2g claims BTS can transmit 40dBm. In reality, it's 25dBm

Added by laforge 18 days ago. Updated 9 days ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Spec Reference:


See the OC-2G product sheet at - the trasmit power is 25 dBm.

Right now the osmo-bts-oc2g code "thinks" it's 40dBm and it tries to ramp the BTS up to that power. This is very confusing for the user looking at the logs or VTY output - and it also is unclear what the PHY will actually do if you ask it to transmit at much higher power than it can physically accomplish.

Related issues

Related to OsmoBTS - Feature #3748: Integrate existing code and patches for OC-2G hardware and phy from oc2g-next branch of nrw_noaNew2019-01-08


#1 Updated by laforge 18 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

#2 Updated by laforge 18 days ago

related patch has been pushed to

#3 Updated by laforge 18 days ago

roh please test the proposed patch. Manwhile, with existing osmo-bts-oc2g code, you could always add a vty option "nominal-tx-power 25" at the "trx 0" config node. This should make the current code behave exactly like the proposed patch.

#4 Updated by laforge 18 days ago

  • Related to Feature #3748: Integrate existing code and patches for OC-2G hardware and phy from oc2g-next branch of nrw_noa added

#5 Updated by laforge 10 days ago

  • Assignee changed from roh to dexter

re-assigning to dexter for further analysis

#6 Updated by dexter 9 days ago

I have applied change Ia6b3476ab2f9279f8905b8c7cfd07ef7b0a939ed, i could not notice any changes in the behavior after applying the patch.

The origin of the problem seems to be missing calibration data. Osmo-bts-oc2g even complains at startup about missing calibration data.

<0006> l1_if.c:1438 Band support GSM900<0006> calib_file.c:136 Failed to open '/mnt/rom/factory/calib/calib_rx0.conf' for calibration data.

The calibration data is stored inside the BTS on a separate block device rom under /dev/mtdblock8. This block device can be mounted using:

mount -t jffs2 /dev/mtdblock8 /mnt/rom/factory/

After that osmo-bts-oc2g finds the calibration data and the output levels of the TRX appear normal.

It is a problem that from osmo-bts-oc2g continues its operation without calibration data. An uncalibrated TRX will output odd signal levels. The signal levels we observed were very low, presumably what we could measure was just leakage through the PA that did not even start up. However, osmo-bts-oc2g must at least report to the BSC that something went wrong. I have now integrated some OML alarms, so in case the calibration is missing we would see that as OML alarm in the BSC log:

The following related patches are currently in review: oc2g: remove unused define constant FACTORY_ROM_PATH lc15: remove unused define constant FACTORY_ROM_PATH oml: make oml_tx_failure_event_rep() public oc2g: generate failure event report in case of bad calibration oc2g: change log level for calibration file errors to ERROR

At the moment osmo-bts-oc2g is not stopped when the error occurs, however it would make sense to stop osmo-bts-oc2g completely. The problem I see is the wired way how the calibration loading is implemented. Apparently it is tolerable if some calibration data is missing. At least the code is written in a wired recursive way that does multiple attempts to read alternative calibration files. I do not get the idea behind this. See also calib_file_send() in calib_file.c. It would be good to know the reason behind this, if loading just one file is enough to make the TRX properly operational we should add some logic/flags that make sure that osmo-bts-oc2g was able to load at least one file.

#7 Updated by dexter 9 days ago

  • % Done changed from 50 to 80

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)