Bug #3823
closedosmo-bts-oc2g claims BTS can transmit 40dBm. In reality, it's 25dBm
80%
Description
See the OC-2G product sheet at http://nuranwireless.com/wp-content/uploads/2018/02/OC-2G_single-sheet_v0.4_web.pdf - 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
Updated by laforge about 5 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
Updated by laforge about 5 years ago
related patch has been pushed to https://gerrit.osmocom.org/#/c/osmo-bts/+/13135
Updated by laforge about 5 years 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.
Updated by laforge about 5 years ago
- Related to Feature #3748: Integrate existing code and patches for OC-2G hardware and phy from oc2g-next branch of nrw_noa added
Updated by laforge about 5 years ago
- Assignee changed from roh to dexter
re-assigning to dexter for further analysis
Updated by dexter about 5 years 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:
https://gerrit.osmocom.org/#/c/osmo-bts/+/13262 oc2g: remove unused define constant FACTORY_ROM_PATH
https://gerrit.osmocom.org/#/c/osmo-bts/+/13263 lc15: remove unused define constant FACTORY_ROM_PATH
https://gerrit.osmocom.org/#/c/osmo-bts/+/13264 oml: make oml_tx_failure_event_rep() public
https://gerrit.osmocom.org/#/c/osmo-bts/+/13265 oc2g: generate failure event report in case of bad calibration
https://gerrit.osmocom.org/#/c/osmo-bts/+/13266 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.
Updated by dexter about 5 years ago
The following two patches are still in review:
https://gerrit.osmocom.org/#/c/osmo-bts/+/13265 oc2g: generate failure event report in case of bad calibration
https://gerrit.osmocom.org/#/c/osmo-bts/+/13266 oc2g: change log level for calibration file errors to ERROR
However, the mounting of the partition with the calibration data should now be fixed in nightly, so a test with a fresh firmware makes sense.
