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/.
fixeria gerrit-no-reply at lists.osmocom.orgfixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmocom-bb/+/18262 ) Change subject: trx_toolkit/transceiver.py: add frequency hopping support ...................................................................... Patch Set 1: (4 comments) This change is ready for review. https://gerrit.osmocom.org/c/osmocom-bb/+/18262/1//COMMIT_MSG Commit Message: https://gerrit.osmocom.org/c/osmocom-bb/+/18262/1//COMMIT_MSG@16 PS1, Line 16: b) The L1 maintains several Transceivers (two or more), so each > It can still probably work with 1, but of course the same 1 is always selected :P It does not make any sense (basically no hopping), but of course we can allow it. https://gerrit.osmocom.org/c/osmocom-bb/+/18262/1//COMMIT_MSG@32 PS1, Line 32: CMD SETFH <HSN> <MAIO> <RXF1> <TXF1> > wouldn't it make more sense to submit ARFCNs here instead of Rx+Tx frequency pairs? It would if there was a clear distinction between transceivers in fake_trx.py, i.e. which one is an MS and which is a BTS. Right now every transceiver is an abstract entity that emits and receives bursts. So when you convert an ARFCN to a pair of Downlink/Uplink frequencies, you don't know whether it maps as Rx/Tx or Tx/Rx for a given transceiver. Of course, we could assume that this is an MS specific feature, and Downlink/Uplink always correspond to Rx/Tx, but what if some day we would need to implement _and test_ variant a) for the BTS side? Also, by sending frequency values in kHz (rather than ARFCNs) we can avoid inconsistency with the existing RXTUNE / TXTUNE commands. https://gerrit.osmocom.org/c/osmocom-bb/+/18262/1/src/target/trx_toolkit/fake_pm.py File src/target/trx_toolkit/fake_pm.py: https://gerrit.osmocom.org/c/osmocom-bb/+/18262/1/src/target/trx_toolkit/fake_pm.py@76 PS1, Line 76: continue > probably print something here saying it's missing. Not really needed. This measurement capability was implemented for BCCH scan (L1CTL_PM_REQ or so), which we don't use in our TTCN-3 test cases. And moreover, BCCH shall not use hopping, so not critical. https://gerrit.osmocom.org/c/osmocom-bb/+/18262/1/src/target/trx_toolkit/transceiver.py File src/target/trx_toolkit/transceiver.py: https://gerrit.osmocom.org/c/osmocom-bb/+/18262/1/src/target/trx_toolkit/transceiver.py@192 PS1, Line 192: if self.fh is None: > Are you sure these 2 conditions are correct? Yes. In the case when frequency hopping is not in use, both Rx and Tx frequencies must be configured (not None). If either of both frequencies is not set (None), and frequency hopping is not in configured, then a Transceiver is not ready to be powered on. -- To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/18262 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmocom-bb Gerrit-Branch: master Gerrit-Change-Id: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd Gerrit-Change-Number: 18262 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <axilirator at gmail.com> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <axilirator at gmail.com> Gerrit-CC: pespin <pespin at sysmocom.de> Gerrit-Comment-Date: Fri, 15 May 2020 14:30:30 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin at sysmocom.de> Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200515/b4934803/attachment.htm>