Age | Commit message (Collapse) | Author | Files | Lines |
|
They are too smart, they keep the timestamps.
Change-Id: Idb4b8f03eb5ffdfd6d3fdbc137b20e3ddc4cfa65
|
|
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
|
|
Change-Id: I1dc6610d7adfa1a52f3d41ad04544806c2be2c39
|
|
Change-Id: Ida1a3583749a004e2a6c92cfed0b6806a5b83c78
|
|
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
|
|
Avoid entering the logRxBurst() function and running a long loop even if
not used.
Change-Id: I67408bc8643d5d97355f277c4a2007064a83ae90
|
|
They are left as INFO instead of DEBUG since they show possible
timing/performance issues in the setup.
Change-Id: I8aab10054ac89c29b871259fdbe59636723ddfb6
|
|
This way i most usual rate_ctr related internal logging is disabled by default
(notice), and it can b eeasily enabled by switching the category to info
or debug.
Change-Id: Id6c36432da7e7ce673c585bcae6772a695028ec5
|
|
Change-Id: I1b5a63e6cc09ac02305c31ea7e94aff53ac0e5c2
|
|
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
|
|
Change-Id: I3854f284e6d6a561b3816b467985f59e690a282b
|
|
Fixes: Coverity CID#211258
Change-Id: Ic00cc5939ca46407cb5bf8b6fcbcf3dc677041a2
|
|
Related: OS#4487
Change-Id: Ibb2c492b3c67cbab11fbb936ae3a090fb5756aa8
|
|
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
|
|
It was notcied due to sometimes causing deadlock at shutdown time.
Fixes: 92ba59dacffe79f4c987154bc63c6eacd8c3605f
Change-Id: I49bea4b0ae469794b5c80ee8fa4f275914a5194c
|
|
Per-ARFCN CTRL threads managing CTRL socket loops were dropped a while
ago, but it was forgotten to udpate the documentation.
Change-Id: I34d117325e60b04b075c205d21bb0b827a5e8c52
|
|
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
|
|
RadioInterface ones will be added in next commit, so let's differentiate
the structs required for each one.
Change-Id: Ib0e142a1dd4bedefdb4c5f15c34132da872c0975
|
|
For instance, use in VTY:
"ctr-error-threshold tx_underruns 5 per-second"
If the condition becomes true (eg 5 underruns happened in one sec), the
statement inside OSMO_MAX would become -1, but it was being handled as
an unsigned when doing the OSMO_MAX internal comparison. As a result,
OSMO_MAX((unsigned)-1, 1) was returning -1 (unsigned) stored in
threshold_timer_sched_secs which then became and int -1, which was
handled by osmo_timer_schedule as a 0, hence having an immediate
trigerring all the time.
While at it, make threshold_timer_sched_secs unsigned since it doesn't
make sense to have it as signed anyway.
Change-Id: I6ea3d64dff189a5bc924e72d846e02d50536a8ea
|
|
Change-Id: I4dc8220a6813d6ff30f1b241cc46b801adec4057
|
|
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
|
|
specific TxGain
Change-Id: I3c54c61cd6dd7e40bb2831fd4962ff72130b390d
|
|
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
|
|
Right now, according to a few measurements taken on LimeMicro devices, 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.
This patch is basically doing the same thing as was done previously for
UHDDevice in 992c9bd1cea410e2dd42ce7566299104b5648aff.
Related: OS#4583
Change-Id: If154fe4d4cd118aa30ea43c22ee7119117b77da6
|
|
Change-Id: Ia6a279e4e19eee8368219e3bc1b011802b1fcadc
|
|
Some SDR devices under some bands may provide only under 0 dBm Tx Power.
Change-Id: I8cecb7a37eb80db341a624eb7b826180eac4a1d4
|
|
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
|
|
specific gains
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
|
|
Change-Id: I35c2f3b3b9358ddb64a53f36969621d45bb243f8
|
|
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
|
|
Change-Id: Ie192c9b516ff98f2b1ab8e7927da55a0c1e9eb56
|
|
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
|
|
Copy the RPM spec file from:
https://build.opensuse.org/project/show/home:mnhauke:osmocom:nightly
Related: OS#4550
Change-Id: I694fcd888778ab68d13165f4d0bf65e5d6870fb4
|
|
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 python + matlab should be part of every source release
Change-Id: I9814a9a352dbee03177ef9e8dfd19bc2baf0ca07
|
|
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.
|
|
Change-Id: I2300f909bbfda10a7053320edfd1deaea763759a
|
|
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
|
|
Change-Id: I03800ae094c35c306fa4ca29f84e71d958ffdbdc
|
|
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
|