From UBSan:
proto_trxd.c:65:18: runtime error: 128 is outside the range of representable values of type 'char'.
Fixes: OS#4507
Change-Id: I71f815fe794a00934ee0e876848af56f30a21bfe
The automatic dependency will only depend on the UHD library
package. The user will then fail to start osmo-trx-uhd due to
missing firmware. So let's include an explicit 'Requires' to the
uhd-firmware package to solve this.
Change-Id: I0ebfe669c21d3957a48d57bd7248244e3e924236
Right now, according to a few measurements taken on B210, we expect the
Tx Gain at UHD level to relate 1:1 with the slope in Tx output power
given a specific band.
If more fine-grained results are wanted or some device doesn't follow a
1:1 slope relationship, functions TxGain2TxPower and TxPower2TxGain need
to be adapted/improved.
Change-Id: I6f432465dce5c6ec1f1bc4653f6149efb18c3f43
All the Tx gain related APIs are left out of reach from radioInterface,
and in there we simply interact with radioDevice passing the attenuation
received from TRXC.
Prior gain logic is moved in base radiodevice class, with the idea that
the setTxGain() and related functions will be dropped over time in each
sublcass in favour of an specific implementation of the
SetPowerAttenuation API.
Change-Id: I4f8a1bcbed74aa9310306b97b0b1bfb02f7855e6
The table with nominal UHD Tx Gains and real transmit power is filled
with values measured experimentally. More information can be found in
OS#4583.
Related: OS#4583
Change-Id: If7ef5bf95ffe4afe5864c0f051853aa38b9639eb
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
Some of the example configs have loglevels set to info. This is too
verbose, lets make sure all loglevels are set to notice
Change-Id: Ief82b85d9ff0e0e94eaabd255ebea961396fff32
Remove OpenSUSE bug report link, set version to @VERSION@, make it build
with CentOS 8 etc.
Disable lms, usrp1 for CentOS 8.
Related: OS#4550
Change-Id: Ie27fcc4f9033f0049507d9dcc295541ac0744c73
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_READ symbol when
copy-pasting somewhere else.
Change-Id: I868baf575b77c448b3115701e70d439de89b0fb3
from a Debian8 build:
[ 256s] prbs-tool.c: In function 'apply_errors_prbs':
[ 256s] prbs-tool.c:190:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 256s] for (int i = 0; i < sizeof(pchan->prbs_u)-4; i++) {
[ 256s] ^
Change-Id: I8541fce50405525efffb12210a269e0ab8a687ab
The tool can now simulate:
* lost bursts on the TRX->BTS interface
* zeroed/overwritten bursts on the TRX->BTS interface
* errors in the TCH codec frames before passing them to the encoder
Change-Id: I0b52c2af6d973669ac233bf9868400e497496460
TODO: Ability to introduce errors in certain classes of the bits only.
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
Set an rssi offset of 28 in the example configs to make sure that the
power control loop gets RSSI values that match at least half way the
reality when the 1800 Mhz band is used. For other bands the value will
be different (See also related osmocom ticket)
Change-Id: I62725fe454f54e2c7cb7550dadb1e6fc94337d78
Related: OS#4468
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: If3d9465068b2c654b935fc3d9ab41d799d5e02e8
In current config files a base port for osmo-trx is set. Lets remove
this setting so that compiled-in default (which is the same value)
is used.
Change-Id: I105d1c51424836daa6893e83a81c83cc7ac6afd4
The log category DDEV ueses LOGL_INFO as debug level. This is too
verbose, lets use LOGL_NOTICE instead
Change-Id: I56d45ce5c3f55574491ffa6e4d902d6ba7499d46
Related: OS#2577
The out "isControl" parameter is only used by internal callers of
USRPDevice, and not used at all by any user of the generic API
(radioInterface*.cpp). Hence, we can get rid of it and keep it as a flag
for an internal API of USRPDevice.
Change-Id: I843384e24b76cdd28a95f9ee4e95e6157098e4a3
The out "RSSI" parameter is only filled by USRPDevice, and not used at
all by any user of the API (radioInterface*.cpp).
RSSI seems to be computed nowadays in the common path in
Transceiver::pullRadioVector().
Change-Id: I06c2ea5a9891d170bc468f952bbf2a7e64d95784
Under armv7l arch, size_t is actually an unsigned int and not a long
unsigned int, and compiler errors:
CommonLibs/debug.h:28:24: error: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 8 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
Change-Id: I7f6ded5a984570b5267916d6c84eb7d019db73a8
Using %lu for pthread_t was wrong on armv7l arch. Even worse, according
to pthread_self() man page, pthread_t cannot be assumed to be of a simple
type and hence printable:
"""
POSIX.1 allows an implementation wide freedom in choosing the type used
to represent a thread ID; for example, representation using either an
arithmetic type or a structure is permitted.
"""
Let's use gettid() instead. According to glibc documentation:
"""
The pid_t data type is a signed integer type which is capable of
representing a process ID. In the GNU C Library, this is an int.
"""
It may not be the same on other libc's though, so let's better cast to a
long int just in case.
Accordign to gettid() man, the libc function was only added recently
during glibc 2.30, however the system call has been around for quite
some time (linux 2.4.11). Let's accomodate use udner non-glibc or older
versions of it by having a direct syscall fallback.
Change-Id: I40265fd4c62e550014ba3ff3335ca053c5bc01f2
With current state multi-arfcn can be used (eg. I can place a call
between 2 phones using TRX1 and sustain for as long as wanted), but from
time to time (around every 20seconds), a burst of Tx packed dropped
events from LimeSuite appears.
LimeNet-micro coefficients have yet not been tested.
Related: OS#4362
Change-Id: I7e67d90a8126546eeeeba376f816ec5d158d4712
Right now the values are the same for all devices, but they will differ
in forthcoming commits once multi-arfcn support is added.
Change-Id: I262d3a71848fc3070473e29e42820848e7591d02
Add an enum containing each supported device type (LimeSDR-USB,
LimeSDR-Mini and LimeNet-Micro) plus "unknown", to leave some room for
yet-to-come devices to run with some generic parameters without
rebuilding osmo-trx.
Each device type is assigned a dev_desc structure, and all of them are
put in HashMap, similar to what's already done in UHDDevice.cpp.
Device type is infered from string provided by LMS_GetDeviceInfo(), as
it was already done before in several places. From now on, we only need
to parse the string once since we store the device type after first
during open time.
Later on, more fields will be moved to device-type specific structure,
such as Tx timing offset, clock rate, etc.
Change-Id: I7658615787c5bc41c365bab9c11733b701ac2ae5
Release is done in destructor, so let's move allocation to constructor
since there's really no need to have them in open() which is already
quite complex and large.
Change-Id: I8a4fd973590c4c165abd8f2837b2da8fc14a2066
channel number mangling based on multi-arfcn feature being enabled was
moved to generic radioDevice() to reuse code. Hence, the generic parent
constructor sets this->chans to 1 if multi-arfcn feature is requested.
However, LMSDevice constructor argument had same name as the class
instance attribute, taking preference. As a result, if multi-arfcn is
enabled in LMSDevice, the generic constructor first sets this->chans=1
but afterwards LMSDEvice constructor keeps calling .resize() with the
argument value "chans" instead of using this->chans.
Let's rename the argument in all radioDevice child class constructors to
avoid potential future bugs in all of them.
Change-Id: Id6c837e9133f22783dd92a81dfcc493e51bf2d21
multi-arfcn feature uses a hardcoded disposition of logical channels on
a physical channel. Logical channels in the phisical channel are
separated by MCBTS_SPACING Hz, that is 4 GSM ARFCNs.
As a result, multi-arfcn restricts the TRX ARFCN setup to the following:
ARFCN(TRX0)=N, ARFCN(TRX1)=N+1*4, ARFCN(TRX2)=N+2*4, ...
Let's make sure radioInterfaceMulti verifies the requested Rx/Tx
frequencies for each logical channel over TRXC match the restriction
explained above. It will check freq going to be set is indeed separated
by MCBTS_SPACING from already set channels, making sure the ARFCN series
is consistent.
Otherwise, before this patch, one could set in osmo-bsc:
ARFCN(TRX0)=N, ARFCN(TRX1)=N+2
and osmo-trx would silently ack the related Rx/TxTUNE TRXC commands, but
actually still transmit on ARFCN N+4 instead. As a result, in this
scenario TRX!=0 were unusable with multi-arfcn.
Related: OS#4207
Change-Id: I2f3d66a611d3a489b3e4d9431994f4ec77b4460f
Make sure old configs using "logging level lms <level>" are still accepted.
Initialization order of VTY componenets need to be resorted since newly
introduced command requires logging VTY node to be already setup
beforehand.
Change-Id: Ia195a74a62a8a3dd6267fb1359acaa5628208d8e
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
Harald Welte
Pau Espin
Philipp Maier
Oliver Smith
Eric Wild