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/UmTRX@lists.osmocom.org/.
Alexander Chemeris alexander.chemeris at gmail.comOn Mon, Jul 8, 2013 at 11:12 PM, Andreas Eversberg <andreas at eversberg.eu> wrote: >>>>> i see no problem with that reject. i think it makes sense to reject TSC, >>>>> if it does not match the TSC of first TRX. since trx manager interface >>>>> seems to be designed to handle each TRX individually (even might be >>>>> possible to run on different transceivers for one BTS), i would think it >>>>> is a good idea to set TSC for every TRX. >>>>> >>>>> >>>> We can easily move to separate TSC settings be removing the static >>>> identifier. The only issue then is that OpenBTS will no longer work. >>>> Perhaps the larger limitation is that we can't set TSC dynamically >>>> after POWERON. This is because the midamble correlation sequence is >>>> regenerated and is not thread safe. >>>> >>>> >>> There could be two command sets - one for OpenBTS compatibility, one >>> for more advanced systems. >>> >>> >> i think that is not requited. TSC at openbsc is a global setting. by the >> specs, it can be set for every timeslot individualy. i think it would be >> good to keep it global, so the transceiver remains compatible to >> openbsc. i can remove the TSC command from osmo-bts. alternatively, as >> stated above, setting the same TSC, which is already running at TRX 0 >> could be just acknowledged, different TSC rejected. >> > once TSC is set, it cannot be changed, even after poweroff. i must > restart transceiver before every new start of osmo-bts. before osmo-bts > start provisioning transceiver, it sends poweroff to all trx. also if > bsc fails, transceiver is turned off and provisioned after bsc link is > restored. with the single trx version of transceiver it worked all the > time. i think there should be a solution for that problem. And this leads us to the question that POWEROFF in the umtrx_dual_test is not implemented at all. Thomas, could you please rebase the umtrx_dual_test onto the recent "fairwaves/master" branch? The DriveLoop/Transceiver split breaks a number of patches and it would be better if you do it yourself. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru