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
The memory leak was reported by ASan:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f23b488e459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x558e83e39e3c in ChannelizerBase::initFilters() /osmo-trx/Transceiver52M/ChannelizerBase.cpp:84
#2 0x558e83e3a8a0 in ChannelizerBase::init() /osmo-trx/Transceiver52M/ChannelizerBase.cpp:188
#3 0x558e83e2d263 in RadioInterfaceMulti::init(int) /osmo-trx/Transceiver52M/radioInterfaceMulti.cpp:197
#4 0x558e83de76d2 in makeRadioInterface(trx_ctx*, RadioDevice*, int) /osmo-trx/Transceiver52M/osmo-trx.cpp:115
#5 0x558e83dea663 in trx_start /osmo-trx/Transceiver52M/osmo-trx.cpp:600
#6 0x558e83dead6f in main /osmo-trx/Transceiver52M/osmo-trx.cpp:695
#7 0x7f23b2576151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
Change-Id: Ibc4c7edeb9bba517db08fce152d863e6cc0c7bbb
The leak was reported by ASan.
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7fd9c9c29f41 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x55bd63ae2364 in RadioInterfaceMulti::init(int) /git/osmo-trx/Transceiver52M/radioInterfaceMulti.cpp:209
#2 0x55bd63a9c6d2 in makeRadioInterface(trx_ctx*, RadioDevice*, int) /git/osmo-trx/Transceiver52M/osmo-trx.cpp:115
#3 0x55bd63a9f663 in trx_start /git/osmo-trx/Transceiver52M/osmo-trx.cpp:600
#4 0x55bd63a9fd6f in main /git/osmo-trx/Transceiver52M/osmo-trx.cpp:695
#5 0x7fd9c7910151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
Change-Id: Ia4f9d4e47caa86ada98054763573e652d281992c
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I3a3ff56cb2d740a33731ecfdf76aa32606872883
Fixes: OS#4865
Otherwise these logging lines end up in the automatically generated
XML VTY reference (stdout), so this breaks further XML processing.
Change-Id: I8e0fd728d406e2452c9c0ddad5bce5f6b17fab42
Related: SYS#4937, SYS#4910
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
Neither VTY nor CTRL API is used in device specific code, excluding
the 'uhd' where osmo_cpu_sched_vty_apply_localthread() is called.
Change-Id: I568b443da4b96c005734d749faa22b9c7440f951
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
The commandline option --vty-ref-xml is needed to enable automatic
generation of the VTY reference manual.
Change-Id: I34dd36183e013ab005f39b235c4ab561590befb7
Related: SYS#4937, OS#1601
This patch fixes MS failing to even see the network, and only RACHs of 1
zeroed byte being seen in GSMTAP.
The issue seems to only appear on some specific machines; others have
been running fine for weeks without this memset being an issue.
Fixes: 7a52e42ee0
Change-Id: I98ad885a5d71e7775973a4d881c0f1cd665ea711
In the multi-ARFCN mode, if the Tx/Rx antenna names are explicitly
set in 'chan N' sections of the configuration file:
trx
...
multi-arfcn disable
chan 0
tx-path TX/RX
rx-path RX2
chan 1
tx-path TX/RX
rx-path RX2
chan 2
tx-path TX/RX
rx-path RX2
osmo-trx would crash, because radioDevice::set_antennas() would
attempt to configure antenna names for all N physical channels,
while USRP devices usually have 2 or even 1 available.
The easiest approach is to remove both 'tx-path'/'rx-path' from
all 'chan N' sections excluding 'chan 0', so it would work fine.
This makes sense, because in the multi-ARFCN mode we actually
use only one physical channel.
However, let's still make sure that explicit configuration of the
Tx/Rx antenna names would not crash osmo-trx and skip N > 0 in
radioDevice::set_antennas().
Change-Id: I09f316f181cbbc2214e8913b73f7c1fcea4e8c05
Related: OS#4636
We cannot use C99 or higher features in C code!
Last lines of build log:
[ 265s] for (unsigned int i = 0; i < decoded_region->num_chans; i++)
[ 265s] ^
[ 265s] ipc-driver-test.c:473:3: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile
your code
[ 265s] Makefile:580: recipe for target 'ipc_driver_test-ipc-driver-test.o' failed
[ 265s] make[5]: *** [ipc_driver_test-ipc-driver-test.o] Error 1
Change-Id: I80c9cbd77f1cdf323ad2b492de7e9a177840c383
There is no point in checking basic stuff ten thousand times per second
since the sizes never change, so it's enough to enable the
checks/assertions for unoptimized (debug) builds.
This significantly decreases branch mispredictions.
Change-Id: Iebd9e91b3c7f37f2dc646d3017c45139977e4d15
This adds a IPC backend that uses shared memory interface
to communicate with (proprietary) devices.
Requires config file option
dev-args ipc_msock=/path/to/socket
to specify the master socket the ipc backend should connect to.
If UHD is avaialble the ipc-driver-test tool can be used to test the
backend with a uhd device, this was so far only tested with a b2xx.
Change-Id: Ice63d3499026293ade8aad675ff7a883bcdd5756
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
Currently configuring 3 channels in multi-ARFCN mode makes the
process crash during the Rx/Tx antenna configuration due to
uncaught UHD specific LookupError/IndexError exceptions:
terminate called after throwing an instance of 'uhd::index_error'
what(): LookupError: IndexError: multi_usrp:
TX channel 2 out of range for configured TX frontends
Let's catch them and terminate gracefully.
Change-Id: If66305f2787c6292375e4bfbd60c1d3d764cffd4
Related: OS#4636
Vadim Yanitskiy
Sylvain Munaut
Vadim Yanitskiy
Pau Espin
Harald Welte
Philipp Maier
Eric Wild