It's really not used, so let's drop unused code and simplify work for
new to come device drivers implementation.
Change-Id: I0d18f9c2584771e2f7b3d5c6b016e764e02855ff
ALERT log level is not Osmocom standard level, it's just a define in
osmo-trx to keep compatibility with old code.
Same goes for one reference to "ERR" intead of "ERROR".
Change-Id: I0e171a8ac8a8bfa804ac97fba3d73efcfa6424b4
No need to use the heap here since buffer is only used as a temporary
trash. Using the stack is quicker.
Change-Id: Iede8dc0903ee3865a52c8e2fd811bcde444fee33
add device dependant max gain setup - limesdr mini and limenet micro need slightly reduced maximum gains to get a PASS on phase error measurements
rework clock reference setup - external clock needs to be selected before calling LMS_Init(), internal can only be set after.
remove now unused compat_LMS_VCTCXO* functions - we do not set the VCTXCO directly anymore
Change-Id: I3cf905b0a84bc1ec200891762a6646141ee37181
move enable: it is important that channels are actually enabled before applying any configuration (besides external clock)
move disable: move to close, so channels are not disabled and not enabled again while osmotrx is active.
Change-Id: I82878913254ce15a85db8d006e13d5eb639793e9
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
Under failure, it could still be that stream status is updated, so let's
father that in all cases.
Change-Id: I4e2b8be06d2993db1bab233948a8ee774b8ac4ee
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
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
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-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