Hi!
Four builds ago, from build 585 onwards, we are seeing massive regressions in the BTS_Tests.ttcn test suite on osmo-bts master: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_resul...
I think this matches roughly when the TRXDv1 protocol changes were merged, it would be great if anyone making changes to osmo-bts or the test suite around July 21/22nd could investigate what's happening here.
Tests against osmo-bts-latest are doing fine, so I think we can exclude a bug in the test suite.
Thanks + Regards, Harald
Hi Harald,
I did a quick investigation, and it seems I found the problem:
https://git.osmocom.org/osmo-ttcn3-hacks/tree/bts/BTS_Tests.ttcn#n425
Since [1] we additionally filter Access Bursts by the link quality C/I in L1SAP, and since [2] we do provide the actual C/I values for osmo-bts-trx, as was received from the transceiver.
[1] https://gerrit.osmocom.org/r/I893ec9c6c2ebad71ea68b2dc5f9f5094dfc43b78 [2] https://gerrit.osmocom.org/r/I8d86dec7ebc039cbfd038c4342ff328b11281865
The default minimum C/I for Access Bursts in OsmoBTS is 50 cB or 5 dB, while the TTCN-3 test cases configure fake_trx.py to send 0 cB, so of course such Access Bursts are getting dropped, as expected. I'll send a fix soon.
For Normal Bursts, the minimum C/I value is -5 cB, so they pass without problems.
With best regards, Vadim Yanitskiy.