Cellular Network Infrastructure » Radio Access Network » OsmoBTS

The preparatory builds to create the binaries to test are complete.
However, to be able to run osmo-bts-trx on the gsm-tester, our APU
probably needs to be upgraded to Debian 8, mostly for UHD.

Waiting a day for a reply to my mail (intern@sysmocom); at some point
I will simply kick off the upgrade and hope for the best.

Note that currently the jenkins builds for the gsm-tester as well as all the
hardware are internal to sysmocom, so this issue might be in the wrong scope.

neels wrote:

Note that currently the jenkins builds for the gsm-tester as well as all the
hardware are internal to sysmocom, so this issue might be in the wrong scope.

Well, in the light of #1850, the scope is spot on

The gsm-tester APU has been upgraded to Debian 8 in order to accomodate osmo-bts-trx.
This caused some fallout concerning the general setup and other BTS models:

In line with the APU upgrade, the jenkins jobs to build the binaries are now also built on
the Debian8 build slave (on sysmocom's internal jenkins). To facilitate that, various
packages and the sysmo SDK had to be installed on this build slave.

The Debian8 gsm-tester APU now uses systemd scripts (found in the osmo-gsm-tester.git) to
run ofono and the gsm-tester daemon.

The jenkins-bts-sysmo.sh script building the sysmoBTS binaries for the gsm-tester was
reviewed -- it now uses the firmware headers provided by the SDK instead of manually
provided firmware headers, among other things.

All bts-model specific builds for the gsm-tester now succeed.

The openbsc build for the gsm-tester still fails, but this seems to be due to a
broken openbsc build in general. Now investigating.

(The openbsc build breakage was not specific to osmo-gsm-tester, fixed by a revert in libosmocore.
https://lists.osmocom.org/pipermail/openbsc/2016-December/009906.html )

The gsm-tester build job successfully gathers binaries and launches a gsm-tester run on the APU again.
ofono communication is also working, though in need of a tweaked systemd service file that announces
the dbus org.ofono service. This file apparently came from 'make install' in the ofono source tree??

# cat /lib/systemd/system/ofono.service 
[Unit]
Description=Telephony service
After=syslog.target

[Service]
Type=dbus
BusName=org.ofono
ExecStart=/usr/local/sbin/ofonod -n
StandardError=null

[Install]
WantedBy=multi-user.target

Completely deleted the debian7 build slave; the build job to transfer the most
recent gsm-tester python code to the APU was still run on it. Moved to Debian8.

It seems the remote gsm-tester daemon restart isn't working yet.

Also, the octphy bts fails to start, cause not yet investigated.

octphy was missing libortp, but now is failing with:

l1_oml.c:1227 Rx APP-INFO.resp (name='octsdr_gsm', desc='Software Define Radio', ver='02.05.00-B818', ver_hdr='02.07.00-B1039')
l1_oml.c:1232 Invalid header-file / dsp-firmware combination, exiting...

Upgraded the octbts DSP firmware to 02.07.00, and the octbts runs successfully now.
This is actually the first time I see an osmo-gsm-tester result light up blue,
meaning full-on success in jenkins!

So, in summary:

• The APU has been upgraded to Debian8, to prepare for osmo-bts-trx.
• All build jobs are now built by the Debian8 build slave.
• All "previous" BTS models are back to successful tests on the upgraded APU:
  • nanoBTS
  • sysmoBTS
  • octBTS
• The osmo-bts-trx binaries are built by new jenkins build jobs and already transferred to the APU.
• STILL TODO: configure the gsm-tester python to actually run the osmo-bts-trx in a test scenario.

osmo-bts-trx is added to the gsm-tester py, but still on a branch.
The point being that the APU reports that no UHD device is connected,
though last time I checked I believe to have seen a B210 (?) plugged into it.

# uhd_find_devices 
linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.005-0-unknown

No UHD Devices Found

libuhd-dev and uhd-host as well as the firmwares are installed,
as described at https://osmocom.org/projects/osmotrx/wiki/OsmoTRX#Dependencies

FTR, osmo-trx says:

ALERT 140551759832896 19:36:06.9 UHDDevice.cpp:776:open: No UHD devices found with address ''
ALERT 140551759832896 19:36:06.9 osmo-trx.cpp:530:main: Failed to create radio device

In fact no BS210 was connected to the gsmtester prototype.

I connected one temporarily to test.

Startup worked:

• osmo-trx starts without problems
• osmo-bts-trx starts and connects with the osmo-nitb

Modem registering with the osmo-bts-trx times out, does not work.

A core file for osmo-trx is found, osmo-bts-trx ends with error.

20161205102906    INFO         procnurse.py:137: "NITB[0x7f077b434c10]:ProcessNurse[osmo-nitb]" Starting process "osmo-nitb" 
20161205102906    INFO         procnurse.py:148: "NITB[0x7f077b434c10]:ProcessNurse[osmo-nitb]" Started process "osmo-nitb" with PID 26020
20161205102910    INFO         procnurse.py:137: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-trx]" Starting process "osmo-trx" 
20161205102910    INFO         procnurse.py:148: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-trx]" Started process "osmo-trx" with PID 26021
20161205102914    INFO         procnurse.py:137: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-bts-trx]" Starting process "osmo-bts-trx" 
20161205102914    INFO         procnurse.py:148: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-bts-trx]" Started process "osmo-bts-trx" with PID 26032 
20161205102921    INFO            runner.py:133: "OsmoTrxBTS[0x7f077b434bd0]" Performing test scenario post-start setup
20161205102921    INFO          scenario.py:246: "OsmoTrxBTS[0x7f077b434bd0]" Checking number of BTSes connected to NITB
20161205102921    INFO          scenario.py:256: "OsmoTrxBTS[0x7f077b434bd0]" Found 1 BTS connected to NITB
20161205102921    INFO  resource_manager.py:201: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd10]" allocated Modem None
20161205102921    INFO  resource_manager.py:201: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd10]" allocated Modem None
20161205102921    INFO          scenario.py:239: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd10]" prepare HLR for NITB with subscriber data
20161205102921    INFO          scenario.py:226: "OsmoTrxBTS[0x7f077b434bd0]" Add subscriber IMSI 901700000007801 (modem /wavecom_0, ext 7801, algo comp128v1, ki D620F48487B1B782DA55DF6717F08FF9)
20161205102922    INFO          scenario.py:226: "OsmoTrxBTS[0x7f077b434bd0]" Add subscriber IMSI 901700000007802 (modem /wavecom_1, ext 7802, algo comp128v1, ki 47FDB2D55CE6A10A85ABDAD034A5B7B3)
20161205102922    INFO            runner.py:159: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd10]" Setting up test case
20161205102945    INFO              case.py:102: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd10]" Waiting for modem to register with network (with 120 seconds timeout)
20161205103148   ERROR              case.py:108: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd10]" Timeout when waiting for modems to register with network!
20161205103148   ERROR            runner.py:164: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd10]" Setting up test case failed!
20161205103148    INFO  resource_manager.py:201: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd50]" allocated Modem None
20161205103148    INFO  resource_manager.py:201: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd50]" allocated Modem None
20161205103148    INFO          scenario.py:239: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd50]" prepare HLR for NITB with subscriber data
20161205103148    INFO          scenario.py:226: "OsmoTrxBTS[0x7f077b434bd0]" Add subscriber IMSI 901700000007803 (modem /wavecom_2, ext 7803, algo comp128v1, ki ABBED4C91417DF710F60675B6EE2C8D2)
20161205103148    INFO          scenario.py:226: "OsmoTrxBTS[0x7f077b434bd0]" Add subscriber IMSI 901700000007804 (modem /wavecom_3, ext 7804, algo comp128v1, ki 8BA541179156F2BF0918CA3CFF9351B0)
20161205103148    INFO            runner.py:159: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd50]" Setting up test case
20161205103209    INFO              case.py:102: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd50]" Waiting for modem to register with network (with 120 seconds timeout)
20161205103410   ERROR              case.py:108: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd50]" Timeout when waiting for modems to register with network!
20161205103410   ERROR            runner.py:164: "OsmoTrxBTS[0x7f077b434bd0]:SendMOSmsTestCase[0x7f077c0bdd50]" Setting up test case failed!
20161205103410    INFO         procnurse.py:112: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-trx]" Found core file /var/tmp/osmo-gsm-tester/tmp.DE0ZLpRaLs/20161205102906-StandardTestScenario-osmoTrxBTS/tmp.DE0ZLpRaLs-osmo-bts-trx/core
20161205103410    INFO         procnurse.py:125: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-trx]" Renamed core file to /var/tmp/osmo-gsm-tester/tmp.DE0ZLpRaLs/20161205102906-StandardTestScenario-osmoTrxBTS/tmp.DE0ZLpRaLs-osmo-bts-trx/osmo-trx-core-26021
20161205103410   ERROR            netres.py: 99: Process "osmo-trx" exited unexpected!
20161205103410   ERROR          scenario.py:270: "OsmoTrxBTS[0x7f077b434bd0]" test scenario resource "BTS" exited unexpected with "-4"!
20161205103410   ERROR            runner.py:184: "OsmoTrxBTS[0x7f077b434bd0]" Calling tick on test scenario failed!
20161205103410    INFO            runner.py:273: "OsmoTrxBTS[0x7f077b434bd0]" Preparing to remove test scenario because state is "failure" 
20161205103410    INFO            runner.py:112: "OsmoTrxBTS[0x7f077b434bd0]" Stopping test scenario
20161205103410    INFO            netres.py: 88: "NITB[0x7f077b434c10]" Stopping process "osmo-nitb" 
20161205103410    INFO         procnurse.py:164: "NITB[0x7f077b434c10]:ProcessNurse[osmo-nitb]" Trying to stop process "osmo-nitb" 
20161205103410    INFO         procnurse.py:171: "NITB[0x7f077b434c10]:ProcessNurse[osmo-nitb]" Sending SIGTERM to 26020 ("osmo-nitb") 
20161205103410    INFO         procnurse.py:174: "NITB[0x7f077b434c10]:ProcessNurse[osmo-nitb]" Wainting for process "osmo-nitb" 
20161205103410    INFO         procnurse.py:177: "NITB[0x7f077b434c10]:ProcessNurse[osmo-nitb]" Process "osmo-nitb" has terminated
20161205103410    INFO            netres.py: 88: "OsmoTrxBTS[0x7f077b434bd0]" Stopping process "osmo-trx" 
20161205103410    INFO         procnurse.py:164: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-trx]" Trying to stop process "osmo-trx" 
20161205103410   ERROR         procnurse.py:180: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-trx]" Process 26021 ("osmo-trx") already returned with rc -4
20161205103410    INFO            netres.py: 88: "OsmoTrxBTS[0x7f077b434bd0]" Stopping process "osmo-bts-trx" 
20161205103410    INFO         procnurse.py:164: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-bts-trx]" Trying to stop process "osmo-bts-trx" 
20161205103410    INFO         procnurse.py:171: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-bts-trx]" Sending SIGTERM to 26032 ("osmo-bts-trx")
20161205103410    INFO         procnurse.py:174: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-bts-trx]" Wainting for process "osmo-bts-trx" 
20161205103410    INFO         procnurse.py:177: "OsmoTrxBTS[0x7f077b434bd0]:ProcessNurse[osmo-bts-trx]" Process "osmo-bts-trx" has terminated
20161205103410    INFO            runner.py:115: "OsmoTrxBTS[0x7f077b434bd0]" Removed test scenario from test runner 
20161205103410    INFO            runner.py:278: "tmp.DE0ZLpRaLs" Tearing down test session
20161205103410    INFO            runner.py: 92: "tmp.DE0ZLpRaLs" Cleaning up test session
20161205103410    INFO           session.py:188: "tmp.DE0ZLpRaLs" Tearing down test session
20161205103410    INFO           session.py:190: "OsmoTrxBTS[0x7f077b434bd0]" Tearing down test scenario
20161205103410    INFO          scenario.py:278: "OsmoTrxBTS[0x7f077b434bd0]" Tearing down test scenario dependencies
20161205103410    INFO          scenario.py:288: "OsmoTrxBTS[0x7f077b434bd0]" Tearing down NITB
20161205103410    INFO              nitb.py:303: "NITB[0x7f077b434c10]" Tearing down NITB

The core file is renamed from "core", which leaves some doubt whether it
really comes from osmo-trx. But osmo-trx also ends with rc=-4, so it's
pretty clearly osmo-bts-trx:

root@apu-roh:/var/tmp/osmo-gsm-tester/tmp.DE0ZLpRaLs/20161205102906-StandardTestScenario-osmoTrxBTS/tmp.DE0ZLpRaLs-osmo-bts-trx# LD_LIBRARY_PATH="$PWD/lib" gdb bin/osmo-trx osmo-trx-core-26021
[...]
Core was generated by `/var/tmp/osmo-gsm-tester/tmp.DE0ZLpRaLs/20161205102906-StandardTestScenario-osm'.
Program terminated with signal SIGILL, Illegal instruction.
#0  _mm_shuffle_ps (__mask=34, __B=..., __A=...) at /usr/lib/gcc/x86_64-linux-gnu/4.9/include/xmmintrin.h:743
743      return (__m128) __builtin_ia32_shufps ((__v4sf)__A, (__v4sf)__B, __mask);
(gdb) bt
#0  _mm_shuffle_ps (__mask=34, __B=..., __A=...) at /usr/lib/gcc/x86_64-linux-gnu/4.9/include/xmmintrin.h:743
#1  sse_conv_real4 (x=0xdb4e58, h=0xd5bfd0, y=0xd95020, len=41) at convolve.c:60
#2  0x0000000000446434 in convolve_real (x=0xdb4e70, x_len=41, h=0xd5bfd0, h_len=4, y=0xd95020, y_len=41, start=0, len=41, step=1, offset=0) at convolve.c:564
#3  0x000000000043dc10 in convolve (x=x@entry=0xd83500, h=h@entry=0xd8e9c0, y=0xd5b170, y@entry=0x0, spanType=spanType@entry=START_ONLY, start=start@entry=0, len=41, len@entry=0, step=1, offset=0)
    at sigProcLib.cpp:476
#4  0x000000000043edf9 in modulateBurstBasic (sps=1, guard_len=<optimized out>, bits=...) at sigProcLib.cpp:1180
#5  modulateBurst (wBurst=..., guardPeriodLength=<optimized out>, sps=1, emptyPulse=<optimized out>) at sigProcLib.cpp:1196
#6  0x000000000044241b in generateRACHSequence (sps=<optimized out>) at sigProcLib.cpp:1629
#7  sigProcLibSetup () at sigProcLib.cpp:2128
#8  0x000000000041ca04 in Transceiver::init (this=this@entry=0xd95b60, filler=1, rtsc=0, rach_delay=0, edge=<optimized out>) at Transceiver.cpp:181
#9  0x000000000040f4db in makeTransceiver (config=config@entry=0x7ffdf146aa10, radio=radio@entry=0xd82970) at osmo-trx.cpp:287
#10 0x000000000040b991 in main (argc=<optimized out>, argv=<optimized out>) at osmo-trx.cpp:540
(gdb) 

Next up: verify that libraries and UHD versions match...

At least libc and libsqlite3 had mismatching versions between build slave and APU.
Upgrading however did not have a visible effect, still getting a core dump from osmo-trx.

root@apu-roh:~# osmo-trx
linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.005-0-unknown

opening configuration table from path :memory:
Config Settings
   Log Level............... NOTICE
   Device args............. 
   TRX Base Port........... 5700
   TRX Address............. 127.0.0.1
   Channels................ 1
   Tx Samples-per-Symbol... 4
   Rx Samples-per-Symbol... 1
   EDGE support............ Disabled
   Reference............... Internal
   C0 Filler Table......... Disabled
   Multi-Carrier........... Disabled
   Diversity............... Disabled
   Tuning offset........... 0
   RSSI to dBm offset...... 0
   Swap channels........... 0

-- Detected Device: B210
-- Operating over USB 2.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.000000 MHz... 
-- Actually got clock rate 16.000000 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Asking for clock rate 26.000000 MHz... 
-- Actually got clock rate 26.000000 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting B210 4/1 Tx/Rx SPS
Illegal instruction

hmm.

#1869 blocks this because jenkins wants to build a new osmo-trx for every gsm-tester run.

We could technically instruct jenkins to build directly on the APU, hoping that the
CPU feature in question is not used, but that would be extra effort, complicating
the build and completely obsolete work when #1869 is fixed.

The osmo-trx binary now runs on the gsm-tester main unit. Next up is to get the modems to see the network... (probably fix invocation to use external clock)

We're having problems getting the B210's network seen by the modems.

At first there was absolutely no network visible to the modems from the osmo-bts-trx.

I tested on my desk with antennae over the air, using an APU and the exact binaries used on the main unit, in which case the network is visible immediately (actually used a smartphone, not a modem). I also tested the B210 plugged into the gsm-tester main unit with antennae instead of the RF cabling, and the smartphone (not modem) again saw the network immediately and was able to subscribe.

So we can rule out that the binary or the gsm tester setup are the cause. The --without-sse build works fine, so does the configuration.

Next, mschramm helped me by removing RF attenuators from the RF cabling.

When attaching the B210, I used the RF cables previously attached to the octphy board, which might have been wrong; apologies.

We ended up removing all attenuators from the RF path B210 <--> modems: the only attenuation in that path are now the duplexer's attenuation and the resistor in the quad modem board.

The result is that only one of the modems (/sierra_1) is able to see the B210 network and registers successfully. But the others (/sierra_2, /gobi_{0,3}) do still not even see a GSM network to register on. It's not related to the modem type, since one sierra sees the network and the other doesn't. I suspect that the B210's network is for some reason still just slightly above the noise floor, and the other modems are this tiny bit less sensitive than the B210, and/or other slight attenuation differences.

I will highlight the following in tomorrow's meeting: the B210's RF path now has hardly any attenuation, so it might be destructive to connect e.g. a sysmoBTS to that path. I will ask all to leave RF connections in the setup to mschramm/hwelte from now on, to not repeat my mistake or worse.

BTW, in the osmo-gsm-tester, we can still see the public production phone networks, despite the direct RF cabling.

In summary, all works in principle, all we need apparently is a better RF connection?

i just did some measurements with a B210 board:

osmo-trx is started with -x (external 10MHz)
osmo-bts-trx gets a config via -c <see snippet next block>

phy 0
 osmotrx rts-advance 10
 instance 0
  osmotrx rx-gain 25
  osmotrx tx-attenuation 25

this results in the following output tx levels (measured directly on the B210, no extra atten.)

tx-attenuation 50 -> -42.0dBm
tx-attenuation 25 -> -16.7dBm
tx-attenuation 10 ->  -2.1dBm
tx-attenuation 0  ->   7.1dBm

i did the manual tests with the att. setting 25 -> -16.7dBm and had another 13dBm of external attenuation as well as a 1-3dBm antenna. that worked for (short) distances in the office, but was definitively much less power than all/most the other tested bts.

where can i find the config used in the testbed? tx-attenuation also takes "oml" instead of a number. i did not test that yet.

all these measurements were done on arfcn 870 with gps clocksource and edge disabled.

please perform the measurements for "tx-attenuation 0" on the band edges and center for all four bands.

https://de.wikipedia.org/wiki/Global_System_for_Mobile_Communications#Verwendete_Frequenzen

• 128, 189, 251 (850)
• 0, 86, 1023 (E-GSM 900)
• 512, 698, 885 (1800)
• 512, 661, 810 (1900)

neels wrote:

We ended up removing all attenuators from the RF path B210 <--> modems: the only attenuation in that path are now the duplexer's attenuation and the resistor in the quad modem board.

small correction: still 10dB attn on B210's Rx plug (of course plus all intended splitter/combiner losses).

I will ask all to leave RF connections in the setup to mschramm/hwelte from now on, to not repeat my mistake or worse.

Appreciated! ,)

Despite B2x0 datasheet which states Tx power 'up to 100mW' (20dBm), with these modulations we get max. 7dBm (5mW) - see roh's measurements. Let's repeat this w/ a GSM900 -ARFCN.

roh wrote:

where can i find the config used in the testbed?

the template for the osmo-bts-trx.cfg is at http://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/templates/osmo-bts-trx.cfg.tmpl

It does not sepecify any tx-attenuation. From how I understand the code, this should result in a 0dB reduction, but the code is far from obvious in that regard. Please do some testing about that, too (i.e. what power do you get when no tx-attenuation is used after osmo-trx and osmo-bts-trx are re-started).

tx-attenuation also takes "oml" instead of a number. i did not test that yet.

This is the mode in which the A-bis OML attenuation (max_power_red) is mapped to the tx-attenuation, which seems to make most sense to me in all default cases, as it reflects what the spec says.

roh wrote:

osmotrx tx-attenuation 25

Excellent! This is the single line of configuration that would have saved us a lot of hardware plugging. I certainly learnt something about osmo-bts-trx now. I think mschramm even mentioned this parameter to me once and I was stupid enough to not try it. I remembered a conversation about this parameter that should rather be controlled via OML; and I assumed 'oml' to be the default setting and to work as intended. Turns out tweaking this parameter is exactly what solves the problem of not seeing the network from the B210.

I tried around a bit. With the current setup where there is very little physical attenuation (as described above):

• 'tx-attenuation 43' is the highest value that still has both sierra modems registering successfully and where I can send SMS back and forth.
• More than 43 stops working
• less than 43 (tried 25, 40, 42, 43) work very well. (The /sierra_1 is always first to register and still works with higher tx-attenuation, so it seems to have better sensitivity than the /sierra_2)
• 'tx-attenuation oml' also works very well. The modems are extremely fast to register.

So it seems that 'oml' is not the default value but should be.

Next step: re-add the physical attenuator elements in the RF path for the B210 and see what values work with that.

(related: maybe start to control the variable attenuators in the RF paths from the test scripts?)

(btw, all four modems register with the osmo-bts-trx successfully with 'tx-attenuation oml': 2x sierra, 1x Gobi, 1x EC20)

please submit a fix to osmo-bts-trx where the oml mode is made the default in case no other config is specified. Please also make sure that example config files for osmo-bts-trx are "correct".

all measurements done with ~13-14dB of external att. arfcn870 for comparison to previous values

band    arfcn  level   settings
1800    870    -31.6   tx-att 25
1800    870    -8.1    tx-att 0
850     128    -1.8    tx-att 0
850     189    -1.8    tx-att 0
850     251    -1.8    tx-att 0
900       0    -1.9    tx-att 0
900      86    -1.9    tx-att 0
900    1023    -1.9    tx-att 0
1800    512    -8.1    tx-att 0
1800    698    -8.1    tx-att 0
1800    885    -8.1    tx-att 0
1900    512    -7.8    tx-att 0
1900    661    -7.7    tx-att 0
1900    810    -7.6    tx-att 0

as indicated, please create wiki page in the OsmoBTS wiki abut the USRB B2x0 (if it doesn't exist) and document the expected signal levels. Please already compensate for your 13dB attenuator so the values reflect what a normal user would see directly at the B2x0 output jack.

i have added a hardware specific subpage under https://osmocom.org/projects/osmotrx/wiki/USRP