<p><a href="https://gerrit.osmocom.org/11083">View Change</a></p><p>4 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn">File bts/BTS_Tests.ttcn:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@58">Patch Set #2, Line 58:</a> <code style="font-family:monospace,monospace">mp_tolerance_ms_power_level</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">If I recall correctly, what I read is that the value should match only if the MS supports it, and if […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">Yes, it is correct that a MS that doesn't support the given power level will return a different (supported) one.  However, the BTS/BSC will know the power capabilities of the phone, and we are testing with a known phone.  So I'm saying we know the setup well enough to not ever ask for a power level not supported by the device.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@58">Patch Set #2, Line 58:</a> <code style="font-family:monospace,monospace">mp_tolerance_ms_power_level</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Yes, I get power level 0 sometimes (using mp_ms_power_level_exp=7 and mp_tolerance_ms_power_level=0) […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">is that sometimes in between, or is that only the first message ever sent by the phone?  Maybe it's just the initial state that's somehow broken? Or the power control loop needs a few iterations until it arrives at the intended value? In this case we could simply exclude the first N messages from matching.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@59">Patch Set #2, Line 59:</a> </p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><pre style="font-family: monospace,monospace; white-space: pre-wrap;">mp_tolerance_ms_actual_ta := 0;<br>       integer mp_tolerance_timing_offset_256syms<br></pre></blockquote></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Regarding this comment, now I understood that only the 2 tolerance ones are to be merged, not the ex […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">the 256syms can of course be non-multiple of 256.  But you can specify the tolerance in units of 1/256th (e.g. 512 for two symbols), and then you can compute the TA tolerance as 512/256=2 and the toa256 tolerance is 512.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@62">Patch Set #2, Line 62:</a> <code style="font-family:monospace,monospace">mp_ms_power_level_exp</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">As I said, I'll test it a bit more and come back with some descirption or change.</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">there is of course the power control loop, and we may have bugs in the power control loop implementation.  Also, there are differences in how the different BTS models / PHY implementations handle this.  The BSC may also instruct the BTS to bypass BTS-side power control loop, whihc AFAIK is broken / not implemented.</p><p style="white-space: pre-wrap; word-wrap: break-word;">I'm not arguing that your observations / results are wrong.  I'm just arguing that somehow our code is broken / incomplete and we shouldn't adjust this by increasing the test tolerance, but by looking for the actual issue.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/11083">change 11083</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/11083"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-ttcn3-hacks </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: Icf1d2216d29c1ebf68c672e6ca06c54a7457304b </div>
<div style="display:none"> Gerrit-Change-Number: 11083 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: Pau Espin Pedrol <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Harald Welte <laforge@gnumonks.org> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder (1000002) </div>
<div style="display:none"> Gerrit-Reviewer: Pau Espin Pedrol <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Wed, 26 Sep 2018 19:59:14 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-HasLabels: No </div>