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
Allow selecting a specific LimeSDR device by setting dev-args in the
config file. Split up the given dev-args address by comma and select
the device where all substrings can be found.
I could not test this with real hardware, but I have added a test case
to make sure this works as expected.
Related: OS#3654
Change-Id: Ib9aaa066a01bf9de3f78234d7ada884d6f28c852
Make the "opt" argument const. This function will also be used by
LMSDevice.cpp in a follow-up commit.
Related: OS#3654
Change-Id: If3f0f682ca453c2b0a06175ec9626567932cfce6
Under failure, it could still be that stream status is updated, so let's
father that in all cases.
Change-Id: I4e2b8be06d2993db1bab233948a8ee774b8ac4ee
This log category is applied to messages related to TRX CTRL socket
interface, and it's printed in yellow, same color used in osmo-bts-trx
for TRX category (so same messages are printed with same color in both
sides).
Change-Id: I98ec5e416272783ad3fbadf70478a4e48ae64983
Original issue: In order to use SSE instructions, 16-byte aligned memory
chunks are needed, and C++ version < C++11 doesn't provide for a native
new/delete store. For that reason, memalign() must be used in the
implementation of convolve_h_alloc() for some buffers.
On the other side, The C++ code relies on C++ "new T[]" operator to
allocate a chunk of memory containing an array of class instances. As
classes are complex types, they cannot be allocated through C structures
(calling malloc). Experimentally can be seen too that it's unreliable
and the process will crash during startup if malloc() is used and then a
Complex<> deferred from it.
Previous implementation allowed for use of convolve_h_alloc or new[]
based on how the (signal)Vector is called, because then the buffer is
not going to be managed internally. But that's unreliable since resize()
calling resize() on it could use "delete" operator on a malloc'ed
buffer, and end up having a new new[] allocated buffer. It was also
found that some of the callers were actually leaking memory through ASan (because the
buffer is not managed by the Vector instance).
IMHO best option would be to rewrite all this code using C structures
and malloc/free exclusively, since it would make all this cod eeasier to
maintain.
But for now, let's extend the Vector class to allow specifying an
external alloc/free function and let the Vector instance take care of
the ownership of the buffer in all scenarios.
Change-Id: Ie484a4762a7f77fe1b105188ea03a6f025730b82
This change fixes lots of memory leaks inside libLimeSuite as
announced by ASan after exiting the osmo-trx process (throgh
CTRL+C for instance).
This way also we make sure libLimeSuite can communicate with the HW and
close whatever subsystems were enabled during LMS_Open time.
Change-Id: I56ffb87079e34aa2d0322fd2ca6429742f9f7640
They are recreated during start(). Actually, if they are not stopped
here, during start() after stop(), LMS_SetupStream() will fail because
it will detect the streams are already opened.
Change-Id: I70d47c287aabdabc5dc1304a942d130aeb10bdc5
So far, the Rx gain was set to 34 dB, wile the comment stated it
would be set to half-point, which is 73/2=36dB. Let's adjust the
code to match the comment.
Change-Id: Idc646def53b83faf4e6c011fb595fa436e223b32
Due to (I believe) a copy+paste mistake from the USRP1 code,
we were using only a scale range of up to 9830 when transmitting
samples, rather than the full 16 bit signed integer range up to
32767.
As a result, we were loosing almost two bits (MSBs) of resolution
as well as a lot of transmit power.
This changes the scale factor to 0.707 (1/sqrt(2)).
Please note that the much higher DAC output level means that the analog
gain should be reduced. The theoretic range of up to 73dB should not
be used, but Lime Microsystems suggest a value of 61..67 dB. This can
be achieved by using a "osmotrx tx-attenuation" value of 6..12 inside
the osmo-bts-trx configuration file.
Related: OS#3341
Related: OS#3342
Change-Id: I71702feaa11f53e7614a6938a984dd748405474a
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
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
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
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
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
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