23 Jun
2014
23 Jun
'14
9:03 a.m.
Hi Holger,
On Sun, Jun 22, 2014 at 03:38:18PM +0200, Holger Hans Peter Freyther wrote:
Using only a single TRX with 10:
We have to disable the second TRX. Would you want to set a
different device id in the EEPROM for the sysmoBTS2050 to indicate
a single TRX board?
If it actually is a sysmoBTS 1100 (1 TRX, 10W) and doesn't even hae a
second TRX board installed, then I would do that, yes.
If it is a unit with 2 TRX boards that the user for whatever reason
wants to use with only one TRX, then that shouldn't be stored in the
EEPROM.
If yes we could have nominal power return 40 and
something like the
sysmobts-mgr could disable the power of the second trx on start?
I think this is an option, but only for the hypothetical option of a
sysmoBTS 1100, which we haven't built until now.
Another option would be to make it configurable inside
the bts
configuration file.
You can already do that today by using the 'nominal-tx-power' cofiguration
command at the TRX level. It should override whatever the system default is.
In this case the bts process would need to tell the
sysmobts-mgr to switch
off the second trx?
Right now there is no such safeguard, so somebody could run both TRX boards at
nominal power of 40dBm, overloading the PA. So yes, maybe check if
nominal-tx-power is > 37dBm and then either
* refuse to start the master if DC power of second TRX is still active, or
* switch off the second TRX
Both cases are not foolproof, as the user could always manually switch on the
secondary TRX and again overload the PA. Thermal management code should
prevent us from overheating, but that doesn't prevent the RF spectrum from
possibly looking quite awkward as you are moving out of the linear range of the
PA...
Reducing power in a dual-bts setup:
The current unfinished idea would be that in case the system
heats up too much we reduce the transmit power on the first
TRX. Is this enough?
In a real 2-TRX BTS, the second TRX is not constant/full power, as it is
only transmitting in active timeslots. Also, it might do downlink power
control. In this case, I would agree that primarily the first TRX power
should be reduced, as it is constant-full-power
Is this enough because in the long run we will manage
both TRX from
the first one?
I would think so. The first step would be an OML router inside
sysmoBTS-mgr, through which all OML messages pass (to both local and
remote TRX), and which then is able to control both of them.
Or shall we handle the heat inside OpenBSC to
temporarily reduce the
power? This way we would need to send information in case the system
returns to an acceptable temperature?
I wouldn't do that, it is too much effort for a clearly only temporary
solution.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)