It may happen that an UL SACCH block is received by the BTS before a DL SACCH block is generated and delivered to the testcase. In this case, the Timing Advance control loop may update the initial TA value that was set during RSL CHANnel ACTIVation.
By default, trxcon transmits UL SACCH blocks with TA=0, which is exactly what triggers the TA control loop in this situation.
To avoid this, we explicitly signal the expected TA value to trxcon by pre-populating the UL SACCH cache. This is done by sending a DATA.req containing a measurement report in advance, before establishing DCCH, so that subsequent UL SACCH blocks carry the correct TA and do not activate the control loop.
Additionally, take the opportunity to add missing f_L1CTL_PARAM(). This compensates for the artificial delay introduced by f_trxc_fake_toffs256(), further reducing the risk of triggering the TA control loop.
bts: limit stderr logging to NOTICE to avoid long write() to ext4 fs
stderr being redirected to a file in the ext4 filesystem sometimes ends up in write() syscall taking >500ms, which means the entire osmo-bts process stalls during that time and we miss clock updates up to a threshold which makes osmo-bts process exit with an error.
Let's decrease logging verbosity to NOTICE for now with the aim to not run into those stalls during normal operation, while we can re-eanble this manually when debugging the write() issue.
