This chapter defines the protocol used between osmo-trx and
osmo-bts-trx.
Most of the text comes originally from osmo-trx.git/README, as it's the
only known documentation of the protocol other than the code itself.
Change-Id: I56c418eef0f826ae1aadbed5b151fbed241c7885
When using multi-arfcn feature, several logical channels (arfcn) are multiplxed
into one physical transceiver, as can be seen in
uhd_device::set_channels.
As a result, when multi-arfcn is enabled some properties are actually
shared for those logical channels, and internally mapped to the first
(only existing) channel, and per-channel internal array variables are allocated
accordingly (size() == 1).
When setting RxGain, we need to set the correct existing physical
channel. Same check is done in getRxGain, and then we apply the RxGain correctly and
we avoid outputing an error "Requested non-existent channel" immediatelly after.
Change-Id: I5b02bb1ef6450dc48be7b8058d96a5691847d3cc
Fixes following Adress Sanitizer warning:
=================================================================
==27120==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs operator delete) on 0x60c00003d900
#0 0x7f2f216de421 in operator delete(void*, unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cc:151
#1 0x561641ce18b7 in ChannelizerBase::~ChannelizerBase() (/build/new/out/bin/osmo-trx-uhd+0x4a8b7)
#2 0x561641ce1cad in Channelizer::~Channelizer() (/build/new/out/bin/osmo-trx-uhd+0x4acad)
#3 0x561641cd5160 in RadioInterfaceMulti::close() (/build/new/out/bin/osmo-trx-uhd+0x3e160)
#4 0x561641cd5047 in RadioInterfaceMulti::~RadioInterfaceMulti() (/build/new/out/bin/osmo-trx-uhd+0x3e047)
#5 0x561641cd5093 in RadioInterfaceMulti::~RadioInterfaceMulti() (/build/new/out/bin/osmo-trx-uhd+0x3e093)
#6 0x561641ca3fdd in trx_stop() (/build/new/out/bin/osmo-trx-uhd+0xcfdd)
#7 0x561641ca4b32 in main (/build/new/out/bin/osmo-trx-uhd+0xdb32)
#8 0x7f2f1f555222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#9 0x561641ca195d in _start (/build/new/out/bin/osmo-trx-uhd+0xa95d)
0x60c00003d900 is located 0 bytes inside of 128-byte region [0x60c00003d900,0x60c00003d980)
allocated by thread T0 here:
#0 0x7f2f216dcf19 in operator new[](unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cc:93
#1 0x561641ce142d in ChannelizerBase::init() (/build/new/out/bin/osmo-trx-uhd+0x4a42d)
#2 0x561641cd5865 in RadioInterfaceMulti::init(int) (/build/new/out/bin/osmo-trx-uhd+0x3e865)
#3 0x561641ca1cb7 in makeRadioInterface(trx_ctx*, RadioDevice*, int) (/build/new/out/bin/osmo-trx-uhd+0xacb7)
#4 0x561641ca44c6 in trx_start(trx_ctx*) (/build/new/out/bin/osmo-trx-uhd+0xd4c6)
#5 0x561641ca4b05 in main (/build/new/out/bin/osmo-trx-uhd+0xdb05)
#6 0x7f2f1f555222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cc:151 in operator delete(void*, unsigned long)
==27120==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
==27120==ABORTING
Change-Id: Ib7c98ae478f319573dd86a0d2cb264f676bb3859
This is a preparatory change that enables a possibility to choose
the amount of synch. sequences to be used for Access Burst (RACH)
detection. The VTY flag will be introduced in further changes.
There are two correlation types now:
- RACH (default) - TS0 only;
- EXT_RACH - all TS0, TS1, and TS2 together.
Change-Id: Ia4f20524350bb8c380d7e10360758eddae8b03e9
Related: OS#3054
According to 3GPP TS 05.02, section 5.2.7, there are three
synch. sequences for Access Bursts:
- TS0: GSM, GMSK (default),
- TS1: EGPRS, 8-PSK,
- TS2: EGPRS, GMSK.
Let's prepare everythyng to be able to detect all TS0-3 synch.
sequences, but keep detection of both TS1 and TS2 disabled
until the corresponding VTY option is introduced.
Change-Id: I838c21db29c54f1924dd478c2b34b46b70aab2cd
Related: OS#3054
Makes osmo-trx-* more consistent with other Osmocom programs, and
allows an unified test for not having "UNKNOWN" in --version.
Related: OS#3578
Change-Id: I90cf01d972aa10b48c59b67a1e7f82a4255ef526
This way the dependencies are passed after the .la object, which seems
to be the correct order. Some setups may fail to find some symbols from
libosmocore otherwise (OBS i586).
Change-Id: I22c80055bcffd4179a0a8ca76533ba7aaa38c859
osmo-trx can start a considerable amount of threads that can make
debugging it challenging at least. By using phtread_setname_np, the
system sets a meaningful name to the thread which can be seen while
debugging with gdb or by printing /proc/$pid/task/$tid/comm.
Now we also log system TID when setting the name so we can identify
different tasks in /proc even if pthread_setname_np fails.
Change-Id: I84711739c3e224cb383fd12b6db933785b28209e
The following warning was observed with GCC 4.8.5:
make[4]: Entering directory `.../osmo-trx/Transceiver52M/device/lms'
CXX LMSDevice.lo
LMSDevice.cpp: In member function 'LMSDevice::writeSamples()':
LMSDevice.cpp:582:22: warning: 'rc' may be used uninitialized
in this function [-Wmaybe-uninitialized]
samplesWritten += rc;
Let's fix this by zero-initializing 'rc'.
Change-Id: I4b4a061fc12e5fd1db8d1087d8e0c46ff1e23412
Avoids this type of compilation warnings:
‘void* memcpy(void*, const void*, size_t)’ writing to an object of non-trivially copyable type ‘class Complex<float>’; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]
Change-Id: I9724454dfb7b87f74f39074e4004580ac3b5fe5c
Fixes this type of compilation warning:
‘void* memcpy(void*, const void*, size_t)’ writing to an object of non-trivially copyable type ‘class Complex<float>’; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]
Change-Id: Ibb2380a0a335ce798fe87221519fbbebade53054
This change allows to remove some wrong use of code as per compilation
warning:
osmo-trx/Transceiver52M/sigProcLib.cpp:1266:40: error:
‘void* memcpy(void*, const void*, size_t)’ writing to an object of non-trivially copyable type ‘class Complex<float>’; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]
midMidamble->size() * sizeof(complex));
Change-Id: Id446711349bec70fa4e7c8efe0f7f9faf7e4f277
Fixes compilation warning:
In file included from osmo-trx/Transceiver52M/device/uhd/UHDDevice.cpp:31:
/usr/include/uhd/utils/thread_priority.hpp:10:17: note: #pragma message: This header is deprecated - please use <uhd/utils/thread.hpp> instead.
Header was moved in uhd.git c33928d2bbdd27688c3475e77fc461e7d16eba5a.
Change-Id: I6299df48a5e14c54eaa07288d166c705eb9ebdbe
We don't want the version of the last tagged version, but the version
number uniquely representing the current HEAD. Use the script from
libosmocore.
I suspect that this somehow got broken in commit 00d5114717
Related: OS#3517
Change-Id: Iba3212aa417dce4240c5c27eb4f12afcd9c95e5b
This is useful if we add more AC_CHECK_HEADER or similar configure tests including
C++ header files or required C++ features, since otherwise gcc is used
by default and test fail.
Change-Id: Iee757c78b72290c5d2a4c31339800a4e72b6be23
Transceiver::stop() can only be called from either CTRL iface thread or
from main thread (running osmocom loop). That's because stop attempts to
cancel and then join all the other threads, which would then lock if
attempting to stop from some of them.
As a result, the best option is to indicate to the user of the
transceiver option (osmo-trx.cpp) to stop it in a correct fashion by
destroying the object from the main thread.
Change-Id: Iac1d2dbe2328e735db2d4b933cb67b1af1babca1
If LImeSDR device is unplugged or its fw crashes during operation,
reading from the device will fail and will first receive short reads and
finally 0 byte reads. Let's quickly notify these events to upper layers
instead of trying to process the buffer and checking timestamps for
something we know it's already not useful.
Related: OS#3340
Change-Id: Ib1af8cdd6cdadf581b039882add4049eea45a0f7
pthread_cancel is implemented in c++ using exception handlers. In
destructor of Log object, the log function is called which will
eventually call fputs() to write to a file. Since that function is
considered a cancelation point, if pthread_cancel has been called the
exception handler will start unstacking frames and calling destructors
in the process. At some point this will cause a runtime exception in c++
which will call std::terminate() to abort the process.
The solution is thus to avoid starting the cancellation process inside the
destructor.
This behavior was spotted while calling the destructor of Transceiver
object in forthcoming patches.
See a more detailed example here:
https://skaark.wordpress.com/2010/08/26/pthread_cancel-considered-harmful/
Change-Id: I71ca90f3fbc73df58b878a03361f7b7831d838b4
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
osmotrxuhd is already being built since it's enabled by default, but
let's make it more explicit that we are building it too.
Change-Id: Ie9c224485cce047cd3ee4600ff7fbdb082355cdc
Until now, setRxGain in LMSDevice did not take into account the setter
parameter and was always using hardcoded 34dB, which was experimentally
found to be a good default value.
Let's force that value during initialization, but still allow the upper
layers (controlled by BTS) to set different values. osmo-bts only sends
a SETRXGAIN command (which calls setRxGain in osmo-trx) if a value is
explicitly set in its VTY config, so we are on the safe side if the user
doesn't explicitly configure a desired dB.
Change-Id: I5684e675281a3f581855dbb56d199a6fe238a712
Pau Espin
Harald Welte
Neels Hofmeyr
Oliver Smith