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
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
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
There might be some configuration that's not supported by osmo-bts-lms,
and we should reject that properly.
Change-Id: I6f82edce589030a4407f6150fb7e8abe6417c1f2
Closes: OS#3347
In Change-Id Ib2fca81b76d027b08e2891056fa076d071597783 we introduced
some coding style violations. Let's make newly-added code follows
standard Osmocom coding style.
Change-Id: Ib7ddd275014f03a2eed3cddc02b1356e2b00c0bc
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
Before this patch, any configuration in osmo-trx.cfg regarding the rx
and tx "antenna" (path) would have been completely ignored, as the
radioDevice::make() function would simply drop those arguments to the
floor.
Change-Id: Ie50f854abbc9dcf351cddc052d10206382e1d5d3
Initially, Rx gain was hardcoded to be 47. This was too high for our
setup and we were constantly getting "clipping detected" messages.
Reducing Rx gain to 34 solved the issue. However, it looks like gains
should be controlled through configuration files.
Change-Id: I30580f18c4ad630c09f725b1d24c125fc3119809
LMS_StartStream() (in LMSDevice::start()) was moved to separate loop. It
is because LMS_SetupStream() would fail for second channel if streaming
has already been started (LMS_StartStream()) for single channel
configuration.
Change-Id: I6704bb92864aa81417507c4ae24a22f41dc529c1
Log level of "send buffer of len ..." messages was changed as it was
causing problems on some machines.
Change-Id: I605d50e81966c7bd169b27788d62af6fb54c84e1
The tx timestamp offset was not set. We set it to the same value as it
was in UHD interface for LimeSDR
Change-Id: I78bc40cd575097f71a5f82b63467fa81c3f8d837
As of LimeSuite 618fbb9c3188b36d75ad5785a97b8887dcc468f6, it seems 5e6
is within the returned range, but LMS_SetLPFBW fails anyway.
See for more information: https://github.com/myriadrf/LimeSuite/issues/184
Change-Id: I967e7da7c0e3e8138b76733ee4a0e6311d20b62e
I'm not quite sure what the ts_offset is for, but by using "0"
we are now receiving exactly the timestamp that we're expecting:
LMSDevice.cpp:486 [tid=140576250332928] chan 0 recv buffer of len 2500 expect 305ed0 got 305ed0 (305ed0) diff=0
Change-Id: I270c94945b1af9662cfc468cfda1ae3af3ac0a27
ts_initial must not point to the timestamp of the first sample
in the last "flush" sample buffer, but to the first timestamp we
expect in the next buffer.
Change-Id: I23af62870544d4c6cf5f6e2d6578936603bceb91
Rx 1.4 MHz, Tx 5MHz. Both massively too wide for GSM, but there's
no smaller band-width available.
Change-Id: I9723c9a2ea77f65bfa9d796d7c44adc2417e89cf
LMS_Init() will override basically all device settings with their
default value, including the sample rate. We hence have to make sure
to call it before any other API function that changes the device config
such as sample rate, frequency, filter bandwidth, ...
Change-Id: I4cdbae8406b5e1e93da491e90f8bad41d4be748b
This is work in progress towards a direct LimeSuite driver in OsmoTRX,
bypassing the currently rather complex stack of wrappers by going
through UHD, SoapyUHD, SoapySDR and LimeSuite.
Change-Id: Iaef29c4c2585ef8c2f94866c9591919f538c1a2d
Same way as we do in osmo-bts. After this commit, osmo-trx no longer
exists. Instead, osmo-trx-uhd and osmo-trx-usrp1 are generated based on
configure flags enabled.
A new flag --with(out)-uhd has been added to enable/disable build of
osmo-trx with UHD backend. It is left enabled by default to keep
compatibility with older build scripts. Binary with USRP1 backend must
still be manually enabled with --with-usrp1 flag.
Change-Id: Iea8c0d7434762713a53440d29bf3ebd84accb262
This way code of radioInterface is independent of the device and doesn't
need to be rebuild for each device.
Change-Id: Id104e1edef02f863b6465ced5b4241050dc188f9