Hi.
I'd like to get back to the status of this one. Are there any patches
available somewhere which I could try? Do we have a ticket to track this
or shall I make one?
On 04/12/2016 02:04 AM, Tom Tsou wrote:
Harald,
Thank you for the thorough log analysis which is greatly helpful.
On Sat, Apr 9, 2016 at 3:25 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
Looking at the got log, the above function call
of
oml_mo_tx_sw_act_rep() for the baseband transceiver was always sent
unconditionally from within check_tranceiver_availability() even in
Jolly's original osmo-bts-trx code from February 2013, see commit
acc71ffb4b61b3354bbb2fa14981e4e6a46946e6. THe code even states that iti
s a HACK and it should only be done once we receive CLOCK indications
from osmo-trx. However, even that is wrong, as CLOCK is already
received in Frame 11, too soon to make that a criterion.
I noticed the behavior
surrounding check_transceiver_availability()
seemed suspect, but I wasn't sure about related effects. Indeed, if I
restrict sections of check_transceiver_availability() containing
oml_mo_tx_sw_act_rep() to running once, I am able to reach a
functional OML setup (sometimes to the point of TCH channel
establishment).
Related is the question of when osmo-trx should send CLOCK
indications. Right now a CLOCK indications is sent with arrival of
commands on the control interface. After starting, CLOCK indications
are sent at an one second interval (216 frames). The indications sent
from the control interface are why osmo-bts is receiving CLOCK so
early.
Solution:
* OML initialization (the most complex part of Abis) needs to be
more properly handled. No part of the code should do something like
dynamically sending software activation reports at runtime. In
osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which
apparently can happen even after start), a software activation report
is sent to the BSC. This is wrong. The software is only activated
once during boot, and it is activated not before the parent MOs for
BTS and Site Manager are enabled.
I can confirm that the sending of SW
activation reports is currently
broken and prevents usable operation with osmo-bts-trx. To start, I'll
look into a better approach to the 'transceiver_available' state and
limiting SW activation messages. Hopefully that can at least get us to
a usable state with osmo-bts-trx.
Unrelated to that, osmo-bts-trx desparately needs
to avoid the use of
global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance
has private data store for implementation-specific state. global
variables have always been discouraged.
Agreed and noted.
-TT
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte