In Transceiver::addRadioVector() we scale the I/Q samples by scaling
the output voltage of the DAC. A relative factor/divisor/ration in
the voltage domain cannot be used 1:1 in the power domain.
There exist two similar formulas:
a) X_dB = 10 * log10(X_lin / X_ref)
b) Y_db = 20 * log10(Y_lin / Y_ref)
both of them are correct, and according to [1]:
a) If you convert a quantity X that relates to power or energy,
=> the factor is 10.
b) If you convert a quantity Y that relates to amplitude,
=> the factor is 20.
Therefore we should be using 20 instead of 10. This change makes
osmo-trx apply per-lchan attenuation values correctly. Otherwise
it would double the values indicated in TRXD messages.
[1] https://dspillustrations.com/pages/posts/misc/decibel-conversion-factor-10-or-factor-20.html
Change-Id: I98bc00bd25df4913d45e55eb008d715aca76fc7c
Related: SYS#4918
Coverity warns us that a non-static class members:
- mRxLowerLoopThread, and
- mTxLowerLoopThread,
are not initialized in this constructor nor in any functions that
it calls. I don't think it's critical, because we do initialize
them in Transceiver::start(), but let's make them nullptr.
Change-Id: If9e06aa7965f17383ab6599c15945e8ce2703bbf
Fixes: CID#214952
Prior to this patch, osmo-trx relied totally on proper VTY configuration
being set in "rssi-offset" together with the RxGain set through TRXC in
order to provide correct Uplink RSSI measurements to bts-trx.
With this patch, RSSI is now by default calculated (in LMS and UHD
backends) based on the currently set RxGain, by providing empirically
discovered values. Still, for backward compatibility, the old
"rssi-offset" command will overwrite completely the per-default
calculated rssi offset.
A new optional parameter "relative" is added at the end of the
"rssi-offset" VTY command to flag the value as relative to the newly
per-default calculated value. This way specific setups (like adding a
LNA / RF fronted) can still be expressed while still keeping the
automatic per-default offset.
Related: OS#4468
Change-Id: I8ef78fd20c22c60d61bfb18d80a4a36df4fd6c20
Using the new libosmovty features allow for:
* Setting different cpu-affinity masks for each thread in the process,
both at startup through .cfg file as well as changing it at runtime.
* Unified VTY interface to change the scheduling policy of the process
inherited by all osmocom processes enabling the feature.
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
Change-Id: I3798603779b88ea37da03033cf7737a6e4751d6e
Since there's now a rate counter, we can drop log level for those events
which can be bursty and hence print lots of output in short periods of
time, which may affect performance. This way setting them to INFO it's
enough to avoid getting them in stderr unless explicitly configured by
the user (for instance to debug stuff), while still allowing a good
enough level to be enabled for other targets such as gsmtap.
Related: OS#4679
Change-Id: I000f7112e35ac68d3d922444f78468b1ea74cbba
They are left as INFO instead of DEBUG since they show possible
timing/performance issues in the setup.
Change-Id: I8aab10054ac89c29b871259fdbe59636723ddfb6
In pushRadioVector, like we did for driveTxPriorityQueue already, gaps
are possible in any channel for TRX!=0, since TRX0 is the only one
expected to be always transmitting.
Since we always need to transmit there, it makes no sense to check for
channel being not NONE.
Change-Id: I3b4b85b9100f69dfa113c54a4357120bd11ec86f
The queue was being accessed sequentially obtaining and releasing the
mutual exclusion zone twice. First in getStaleBurst() dropping all
FN<currTime, then in getCurrentBurst() trying to obtain FN=currTime.
However, since in between the mutex is released, it could happen that
for instance upper layer would introduce currTime-1 in the queue, which
would make then getCurrentBurst() detect that one instead of potential
currTime in the queue and return NULL.
By holding the mutex during the call to both functions we make sure the
state is kept during the whole transaction.
Related: OS#4487 (comment #7)
Change-Id: If1fd8d7fc5f21ee2894192ef1ac2a3cdda6bbb98
This ones together with rate counters already available in lower layers
allows to understand better the source of the problem with stalled tx
bursts.
Change-Id: Ia34f7e7d780ad1e12f24638a07f05fe91f2afea5
Coverity dixit:
"Non-static class member field "ctrs.tx_stale_bursts" is not initialized
in this constructor nor in any functions that it calls."
Fixes: CID#211258
Change-Id: I4643a0500e9cad09938c05fab2f358167f72ffa9
This allows checking if there's timing issues on the downlink side
between osmo-bts-trx and osmo-trx. This counter is useful to find
information about osmo-bts-trx 'fn-advance' setting, since this counter
basically counts if burstrs from it arrived too late to osmo-trx.
Change-Id: Id6df00da81f6d6884f4dddc5a2c4b354dca3af97
It allows the BTS to retrieve the nominal transmit output power value of
each TRX in order to compute attenuation later on and apply it through
SETPOWER or ADJPOWER TRXC commands.
Change-Id: I1d7efe56e008d8d60e23f9a85aa40809f7f84d9c
When the logging category TRXCLK is set to info osmo-trx prints a
logline that informs about the sending of clock indications. In practice
this those log lines are often used to identify that osmo-trx and
osmo-bts are running properly, so it would be helpful, even in
productive use, if there would be an information in the log that the
sending of clock indications has begun. However, the regular printing of
the clock indication log line would soon flood the log. So, lets have an
addional log line that logs only once when the transceiver starts and
quickly informs at loglevel NOTICE that clock indications are now sent.
Change-Id: I6aa88943b76c9a2bf7aed60d6a3d325c1f27820a
Related: OS#2577
There is no need to have n threads handle n ctrl sockets, since they all
will immediately respond to commands, so handle them from the existing
main osmo select loop.
Care must be taken to ensure that calls from within the command handler
do not block, or at least don't block too long, which currently is the
case.
Change-Id: I642a34451e1825eafecf71a902df916ccee7944c
Take the chance to clean up logging lines in this file:
* Use LOGCHAN in more places where chan is useful
* Replace inherited (old osmo-trx) categories such as WARNING with
osmocom ones.
Change-Id: Ic8c218f050f35d48046ccf1561fb0bfc505d4f63
BTS may have any timeslot disabled, or may have not yet sent initial
SETSLOT cmd to properly configure the timeslot.
Change-Id: Icf62e5d1200c7a440f255bb46023cdbf61532b7f
Since tn is declared as uint8_t, it's actually a char, and by default
c++'s ostream& operator<<(ostream&, unsigned char) tries to print chars
with its ASCII visible character instead of numeric value.
Change-Id: I534158e8e1719ad19a9cde7c747a8f8ad5a01a2b
We don't want to keep osmo-trx running in a started state once the BTS
controlling it becomes unavailable. If a socket towards the BTS fails,
it means the BTS is gone and the best thing to do is to stop the process
(alternatively we could go back to stopped state instead, and wait for
BTS to re-connect, fur so far this action is good enough).
Related: OS#4170
Change-Id: I2ccbe3c17b39fb792ea7810f840235c348054d66
pullRadioVector() should return true on idle frames because those
indications may be handled by upper layers (TRXDv1). Clarify return code
in function documentation.
Change-Id: If592ed1c04cf7e995f656b313f60edd4d40d1bfd
If osmo-trx is started and IP addr binding fails (ie because the IP
address is not assigned in the system), it will try to access a
heap-allocated Thread instance which was not initialized (because init()
function returned earlier).
Fixes: OS#4147
Change-Id: I19f9745cd026c0ff6581895a66bf91b40113b07d
This code is not needed anymore since we are setting SCHED_RR scheduler
with a real time priority in main thread during startup, so all threads
will inherit same rt priority, which should be enough to keep the
process working reliably even on high system loads (from non rt
processes).
osmo-trx was tested to be reliable during test with stress-ng as
explained in related ticket below.
Related: OS#2344
Change-Id: I3a88946dd71e9aeeaac9d19d396e2236c302b608
Previous commit started using IPPROTO_UDP without including required
include. Newer versions of libosmocore's osmocom/core/socket.h include
that header so the define is present, but older versions of libosmocore
(such as 0.12.0) don't, so let's include it explicitly (the correct
thing to do).
Fixes: b9d2515704
Change-Id: I67ddf550f3a7fc6a650e1e1d9bde0bbb28785104
TransceiverChannel naming was misleading there. It's simply a data type
used to pass 2 parameters through the void* of the thread entry
function, so let's clearly specify is a storage for thread params.
Furthermore, we don't need a full C++ class for that, let's simply use a
struct.
Change-Id: I6e3898a8a66520cc5b2a7df9b9ae01b0b272387f
The setting is negotiatied by osmo-bts-trx on each channel, so let's
keep and use state per channel instead of overwriting the state from
different channels.
Take the chance to change related log lines to also print the channel
number.
Change-Id: If9cf95e89d38d0155ab48b8c0977ca5f381c2aad
Doing so should make Coverity happy:
>>> CID 200212: Uninitialized members (UNINIT_CTOR)
>>> Non-static class member "mExtRACH" is not initialized in this constructor nor in any functions that it calls.
The current status is actually harmless since the field will be set
during init() time, and the variable is never used before init() is
called.
Fixes: Coverity CID#200212
Change-Id: I17286570a9a6db695a75147e5cbb18c9da7d0fe6
Vadim Yanitskiy
Sylvain Munaut
Vadim Yanitskiy
Harald Welte
Pau Espin
Eric Wild
Philipp Maier
Martin Hauke