Commit
a1affd5e0c6e2faa05d2823f9434c68858bd98d1
by Pau Espin Pedrol
bts: TC_pcu_{rts_req,time_ind}: process FNs in port queue after time out
Since we sometimes run short on counted FNs, but we validate that there were no FN gaps, it means we are simply late counting the generated RTS.req from IUT. Let's try to get a more accurate count by trying to process RTS.req in the port queue after the timeframe of the test finishes. In the end, we want to count the RTS.req transmitted by the IUT, not the ones we can receive in time.
Commit
9ca4ba8f888deab8e1e89e8b5ac1e339587dd726
by Pau Espin Pedrol
bts: TC_pcu_{rts_req,time_ind}: Relax expectancies on rx primitive count
Even with latest changes I can still sometimes run into up to 6 FNs less than the currently minimum expected. That's usually 1-2 primitives less, which in the number of >100 we are receiving over 5 seconds, seems like a plausible drift.
Commit
daef91787dcc9f6c161bd024310b7e0898166cc0
by laforge
gbproxy: Fix several tests on titan 11
Rework altsteps to avoid race condition showing up under titan 11.1.0. It's not really clear whether the previous implementation is actually expected/permitted by TTCN-3, where an altstep variable is initialized multiple times with different values through activate(). In any case, the new implementation is much cleaner, only requiring 1 altstep instead of N.
Commit
95f8532dc6f7372ec7f9f14682c656549764ea74
by Pau Espin Pedrol
bts: TC_tx_power_ramp_adm_state_change: Fix Tguard too low sometimes triggering
One can see with the following failing output below that the Tguard is too low: """ 13:36:12.459089 5684 BTS_Tests.ttcn:2836 Reached full power, wating a bit more until success 13:36:12.459097 5684 BTS_Tests.ttcn:2837 Start timer T: 2 s 13:36:14.358525 5684 Misc_Helpers.ttcn:35 setverdict(fail): pass -> fail reason: ""BTS_Tests.ttcn:729 : Tguard timeout"", new component reason: ""BTS_Tests.ttcn:729 : Tguard timeout"" """
