After upgrading our CI environment to use Debian 12 with GCC 12, the
byteswap code fails the build with the following. I've talked to Eric
about this and he recommended to just remove the code as practically
nobody will use osmo-trx with a big endian system.
USRPDevice.cpp:591:30: error: 'data' is used uninitialized [-Werror=uninitialized]
591 | *wordPtr = host_to_usrp_u32(*wordPtr);
| ~~~~~~~~~~~~~~~~^~~~~~~~~~
Related: OS#6057
Change-Id: I806d8c1432cb20efca1830a2752a4cbc70384b54
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
All radioDevice subclasses except USRPDevice have already been reworked
to use the new SetPowerAttenuation() methods, hence we can drop the
compatibility layer that was added to transition from the old API to the
new one, and move those functions to USRPDevice.
This way we simplify the parent abstract class with methods not needed
by most devices and not used anymore by external users of those classes.
Change-Id: Ice005cd0a07c49b6e212c06f1228ef93c24db727
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
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
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
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
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
This file is only used by USRP1, so let's move it there and avoid
processing it in Makefiles if build for USRP1 is not requested at
configure time.
Change-Id: Ibb40ba487581e76d2ae3e8a420d631670f876cf0
Since in next commit osmo-trx-lms starts using smpl_buf.cpp, it seems
some automake step doesn't like including a cpp file twice from a
different directory, since race conditions can occur building it.
Instead we define the dependency by first building a static lib and then
using it on each libdevice.la (one per device type).
We already do the similar under arch/ subdir, where we have a common/
subdir and then one subdir and lib per architecture.
Change-Id: I465ad0f6d5569bb3006d711c8fd0df14391fcf35
It's really not used, so let's drop unused code and simplify work for
new to come device drivers implementation.
Change-Id: I0d18f9c2584771e2f7b3d5c6b016e764e02855ff
There appears to have been some logic to operate a USRP1 in
transmit-only GSM mode. This is achieved using the skipRx member
of the transceiver object. However, there's nobody that ever
initializes it properly, and hence the feature is not possible to
use anyway.
I don't think this has any valid use case, so let's remove it.
Change-Id: I616193f1e9aaefbf4ceb26761657811093f28b6f
The DMAIN category got too overloaded. Let's have the code in
Transceive52M/device/* use the new DDEV category.
Also, in some cases the log levels have been adjusted to ensure
that enabling INFO level should not result in a complete overflow
of messages during normal operation.
Change-Id: I844fe4a75bf277cd3cc5bd8fa06e06ad97b2ea95
There might be some configuration that's not supported by osmo-bts-usrp1,
and we should reject that properly.
Change-Id: Ic7308ce0c57439fe97668bd31801c4bf76b797ad
Closes: OS#3348
It's not good style to have the derived classes initialize members
inherited from the base class using "this->foo = bar". Rather, let's
make the base class have a constructor, and call that constructor to
initialize the members of the base class.
While doing this
* rename 'offset' to 'lo_offset' to avoid confusion with timestamp offset
* move 'InterfaceType' into the base class
* move 'chans' into the base class
* move 'rx_sps' into the base class
* mark base class members as 'protected'
Change-Id: Ib885675a7612a392aa7f75fca81269ddcff2f6ab
This way code of radioInterface is independent of the device and doesn't
need to be rebuild for each device.
Change-Id: Id104e1edef02f863b6465ced5b4241050dc188f9
Eric Wild
Oliver Smith
Vadim Yanitskiy
Pau Espin
Martin Hauke
Harald Welte