Change in osmo-bts[master]: l1sap: merge MEAS IND into PRIM PH DATA / PRIM TCH

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/.

laforge gerrit-no-reply at lists.osmocom.org
Wed Dec 18 12:12:21 UTC 2019


laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/15918 )

Change subject: l1sap: merge MEAS IND into PRIM PH DATA / PRIM TCH
......................................................................


Patch Set 1:

(3 comments)

https://gerrit.osmocom.org/c/osmo-bts/+/15918/1/src/common/l1sap.c 
File src/common/l1sap.c:

https://gerrit.osmocom.org/c/osmo-bts/+/15918/1/src/common/l1sap.c@74 
PS1, Line 74: static bool tch_data_meas_present = true;
> AFAIU You don't need to do any switching, simply have an API bool bts_model_tch_data_meas_present()  […]
we do already have the BTS_FEAT_* constants and the gsm_bts_set_feature() API.  That would be the most logical way for me to deal with this.

Adding a single call to gsm_bts_set_feature() in all existing backends is also certainly not requiring a full re-test with all hardware.


https://gerrit.osmocom.org/c/osmo-bts/+/15918/1/src/common/scheduler.c 
File src/common/scheduler.c:

https://gerrit.osmocom.org/c/osmo-bts/+/15918/1/src/common/scheduler.c@760 
PS1, Line 760: l1sap->u.tch.
> I am also a bit confused about the is_sub struct member. […]
I believe I explained this elsewhere here in gerrit or in redmine.  is_sub must at the very least be set for all SACCH  frames, and is set on other frames depending on the codec that's being used.  It controls which frames count into RXLEV/QUAL "SUB".


https://gerrit.osmocom.org/c/osmo-bts/+/15918/1/src/osmo-bts-trx/scheduler_trx.c 
File src/osmo-bts-trx/scheduler_trx.c:

https://gerrit.osmocom.org/c/osmo-bts/+/15918/1/src/osmo-bts-trx/scheduler_trx.c@a205 
PS1, Line 205: /* FIXME: use actual values for BER etc */
> The problem here is that we can not use actual values for BER. […]
the best would be if those values simply wouldn't count.

Let's say you normally expect 23 values every measurement interval.  Then you compute the average by dividing by 23.  But if only 20 valid measurements were received and 3 were in bad frames, then the average should simply be computed by dividing by 20, and not by 23.  At this point you don't need to "invent" any values.



-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/15918
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I710d0b7cf193afa8515807836ee69b8b7db84a84
Gerrit-Change-Number: 15918
Gerrit-PatchSet: 1
Gerrit-Owner: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: fixeria <axilirator at gmail.com>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: laforge <laforge at osmocom.org>
Gerrit-Comment-Date: Wed, 18 Dec 2019 12:12:21 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: dexter <pmaier at sysmocom.de>
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Comment-In-Reply-To: fixeria <axilirator at gmail.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20191218/80622543/attachment.htm>


More information about the gerrit-log mailing list