Crash of UmTRX transceiver with dual TRX

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.com
Mon Jul 8 19:54:04 UTC 2013


On 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




More information about the UmTRX mailing list