This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
dexter gerrit-no-reply at lists.osmocom.orgdexter has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/20980 ) Change subject: measurement: ignore lost FACCH/H uplink measurements ...................................................................... Patch Set 1: (3 comments) > Patch Set 1: > > My assumption was wrong, we already do send to BFIs in the current implementation: > > https://gerrit.osmocom.org/c/osmo-bts/+/20981 osmo-bts-trx/scheduler: fix comments related to FACCH/H and BFI > > so why would we end up with one measurement sample less then? I guess the problem is that one such BFI is ignored by the measurement logic as expected, while another one is not, because it holds a valid RSSI value? During the last call, I proposed to ignore the measurement samples carried by BFIs triggered by FACCH, but what if we take the opposite approach and ignore FACCH samples instead? In other words, you count speech frames as usual, including all BFIs, but do not take FACCH samples into account. This way there would be need to mess up with expected number of measurements, it would always be constant. And of course, this is only in speech mode. In signalling, we count FACCH frames as usual. What do you think? This might be the solution to the problem. I will give it a try. https://gerrit.osmocom.org/c/osmo-bts/+/20980/1//COMMIT_MSG Commit Message: https://gerrit.osmocom.org/c/osmo-bts/+/20980/1//COMMIT_MSG@9 PS1, Line 9: FACCH channel ist > It's not the 'channel' that is spread over 6 bursts, but a frame, right? […] I think "Block" is more right here. To my knowledge a frame is the 8 timeslots... https://gerrit.osmocom.org/c/osmo-bts/+/20980/1//COMMIT_MSG@11 PS1, Line 11: up with one uplink measurement sample less > Yes, and this is not a valid behavior. […] I think you mean a different bug. The BFI frames (blocks) that are handed up are ignored by measurement.c anyway since they are sent with RSSI=0 anyway. If you do the channel mapping drawings, you will see that there is indeed exactly one measurement value less when a FACCH is transmitted. (However, I think there are still bugs, but those affect the timing only.) https://gerrit.osmocom.org/c/osmo-bts/+/20980/1/src/common/measurement.c File src/common/measurement.c: https://gerrit.osmocom.org/c/osmo-bts/+/20980/1/src/common/measurement.c@670 PS1, Line 670: Lost %u UL measurements > This looks and sounds confusing: we're not loosing anything... Done -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/20980 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: Ibf693aede8fffa6432cdcdcf5d52910493a1104b Gerrit-Change-Number: 20980 Gerrit-PatchSet: 1 Gerrit-Owner: dexter <pmaier at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de> Gerrit-Comment-Date: Mon, 02 Nov 2020 15:06:23 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: fixeria <vyanitskiy at sysmocom.de> Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20201102/54fc9ac6/attachment.htm>