Changes

bts: limit stderr logging to ERROR to avoid long write() to ext4 fs

Commit c3ab9ec33f37c6837fb8bcb0fa0bbd2e98781fb7 already decreased
verbosity to NOTICE, but that's not enough since we still get plenty of
logging and hence plenty of long write()s during test execution.

Let's try decreasing to ERROR and see if that's enough for now to
stabilize the tests.

Change-Id: I41982fd83a9f46609464afb6b7242240063d4d91

hnbgw: expected-results.xml: Add missing TC_sccp_cr_limit

Change-Id: I4138cff311f82358f040290f3af483df8facc4cf

bts: as_rsl_meas_res(): tolerate bad RxQual in early reports

Bit errors are expected during early stage of channel establishment.
Ignore bad RxQual in the very first reports (4 * 0.480s = 1.92s).

This reduces probability of sporadic failures.

Change-Id: Ie8acb15b66cd92092ec49bc8caeaf0ad4d471f1d
Related: OS#6933

bts: as_rsl_meas_res(): do not expect dummy UL SACCH

We're now populating the UL SACCH cache before establishing a
decicated channel in f_est_dchan(), so this special case is
no longer needed and can be safely removed.

Change-Id: I6eeee2876a76d41ab453af4c7724173fea773b83
Related: I4781fe7539e64e77d594e84f905646c127f46b64
Related: OS#6933

bts: f_verify_ramp_up(): fix RxLev / dBm mixup

Comparing RxLev and dBm values is comparing apples to oranges.  It's
just a lucky coincidence that fake_trx is using RF path loss value of
110 dB, which is also the offset between RxLev and dBm.

* Add `mp_rf_path_loss` matching the default value (110 dB) in fake_trx.
* Add `f_bts_max_rx_level_dbm()` calculating the expected Rx power level.
* Apply `rxlev2dbm()` on `l1_dl.dl_info.rx_level` whenever needed.
* Clarify the units in verdict / logging messages.

Change-Id: I818d18d6e0711247b73ee1f336133e2ed3f6e2cb
Related: OS#6939

bts: fix TC_rsl_ms_pwr_dyn_ass_updown: simulate a good C/I value

Now that we populate the UL SACCH cache in advance, trxcon is sending
ms-pwr-lvl 7 in the first UL SACCH block (as expected).  This suddenly
makes the testcase fail, because now the MS power loop is perfectly
happy about the received input values and does not order any changes
to the current MS power level anymore, contrary to our expectations.

Why? Short answer: because of C/I (curr 6, avg 6) being outside of
the good range (thresh 13..17).  The MS power loop intentionally
avoids reducing Tx power because that would potentially degrade the
link quality (C/I) even further.  Solution: let's order fake_trx.py
to simulate a C/I value that is within the thresholds.

This alone does not fix the testcase yet, another fix follows.

Change-Id: I8926fc925e930bc2703210931b613988161a72da
Related: c246f207 ("bts: f_est_dchan(): populate UL SACCH cache")
Related: OS#6945

bts: fix TC_rsl_ms_pwr_dyn_ass_updown: adjust the timers

This testcase predates major changes to the MS power control logic
in osmo-bts and was passing thanks to a coincidence (broken UL SACCH
cache in trxcon).  Specifically, the MS power loop is now using
P_Con_INTERVAL=4 by default.  This means that the power control
decision is intentionally delayed and a change may occur only once
in a period of 4 SACCH blocks (N=4 is ~1.92s).

Adjust the timer values to take this into account.  Take a chance
to move comments in-place and expand them with more details.

This patch makes TC_rsl_ms_pwr_dyn_ass_updown pass again.

Change-Id: I36d87c12f49ec13003b708d768285aa6840e81eb
Related: OS#6945

bts: TC_rsl_ms_pwr_dyn_ass_updown: misc improvements

Change-Id: Iae3fa5f09d68bd472f7236bf882f5b168d87384a
Related: OS#6945