reported/provided by user softdev86 in https://github.com/srsLTE/srsLTE/issues/566
author tested with local 4 port cell. I am not able to verify locally but
it looks ok, we'll revise later if needed.
When using srsLTE with Lime devices, calibration was performed before any configuration steps have happened, thus making calibration values invalid. Removing Lime specific calibration step from rf_soapy_imp makes so that devices will be automatically calibrated by SoapyLMS on rf_soapy_start_stream call.
Tested and working with srsENB using LimeSDR-USB v1.4 and LimeSDR-Mini v1.2 boards.
when the default RF args are used, NULL is passed as argument
to the RF driver. In this case, we should use the previous
SoapySDRDevice_enumerate() and let Soapy pick the device
This patch adds version string to the 'libsrslte_rf' library.
This results in the library being built as
libsrslte_rf.so.20.04.2
with the following symbolic links
libsrslte_rf.so.0 -> libsrslte_rf.so.20.04.2
libsrslte_rf.so -> libsrslte_rf.so.0
The SRSLTE_SOVERSION variable should be increased with each backwards
incompatible change of the library.
Signed-off-by: Jan Remes <jan.remes@invasys.com>
* Fix deadlock caused by update_measurements calling in_sync
* Fix overlapping SRS condition
* Do not use shortened PUSCH in transmissions and retx from RAR
* Revert "Fix deadlock caused by update_measurements calling in_sync"
This reverts commit f58c8c8c766f8f95baa3a3bf8287d8e25b2057ba.
* Take into account CRS from neigbhour cells when measuring interference
* fix std::isnormal compilation
* Fixed compilation of test
* Address comments
* Remove unused overrides
with the B210 and 2 RF ports, i.e. MIMO mode, we have stopped the
Rx stream after changing the rx_samp_rate but didn't start it again.
Either the issue doesn't exist in SISO mode or we never saw it but for MIMO
it can be reproduced easily with rate changes during streaming, i.e.:
$ ./lib/src/radio/test/benchmark_radio -p 2 -t 10 -x -y -s 23.04e6
Instantiating objects and allocating memory...
Initialising instances...
Opening 2 channels in RF device= with args=default
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
[INFO] [LOGGING] Fastpath logging disabled at runtime.
Opening USRP channels=2, args: type=b200,master_clock_rate=23.04e6
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Asking for clock rate 23.040000 MHz...
[INFO] [B200] Actually got clock rate 23.040000 MHz.
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
Warning: TX gain was not set. Using open-loop power control (not working properly)
Setting manual TX/RX offset to 0 samples
Start capturing 10000 frames of 23040 samples...
Changing sampling rate to 23.04 Msamps/s
Setting manual TX/RX offset to 0 samples
Changing sampling rate to 1.92 Msamps/s
Setting manual TX/RX offset to 0 samples
/home/anpu/src/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.1211: Error timed out while receiving samples from UHD.
/home/anpu/src/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.1211: Error timed out while receiving samples from UHD.
/home/anpu/src/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.1211: Error timed out while receiving samples from UHD.
/home/anpu/src/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.1211: Error timed out while receiving samples from UHD.
/home/anpu/src/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.1211: Error timed out while receiving samples from UHD.
it fixes#1623.
this happens more often with MIMO since lates are more likely here.
after a late, the Rx stream must not be stopped on the B2xx either.
<log>
RF status: O=3, U=0, L=1
/home/anpu/src/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.1209: Error timed out while receiving samples from UHD.
stop rx stream
./home/anpu/src/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.1209: Error timed out while receiving samples from UHD.
stop rx stream
/home/anpu/src/srsLTE/lib/src/phy/ue/ue_sync.c.775: Error receiving samples
/home/anpu/src/srsLTE/lib/src/phy/ue/ue_cell_search.c.312: Error calling srslte_ue_sync_work()
/home/anpu/src/srsLTE/lib/src/phy/ue/ue_cell_search.c.272: Error searching cell
</log>
the enable_rx_timestamps() for the radio_ctrl object has only been
introduced in Nov 2019 for UHD 3.15 and therefore needs
to be excluded when compiling for 3.14 and below.
Note: According to the original UHD commit in
67dbaa41f2 (diff-60a9387c0fc8406fd5b39fa995dd8c14)
it looks like the Rx timestamps are disabled by default
for UHD versions before 3.15
This commit fixes#1602
at the when applying the fading channel we copied the state back
to our buffer. Since we are offsetting the read buffer
by X samples, we need to make sure that we don't read after then
(len-X) samples of the temporary memory buffer
the PSS detection needs more temporary buffer than a full subframe.
we therefore need to allocate and initialize the sync object with
larger maximum size to support Scell search of large cells, e.g.
20 MHz
this fixes issue #1538
with ZMQ RF, we've seen the radio returning -1 and traced
the issue down to the ringbuffer.
in fact, pthread_cond_timedwait() returned 22 (EINVAL) indicating
a wrong timeout value. The issue was likely an overflow
in the timespec parameter. This patch checks for the return
value of pthread_cond_timedwait() and also calculates the
nanosecond wrap around for the timespec
amarisoft flags an RF error and exits after not receiving samples
for the radio. Running with ZMQ in the RFCI, the UE sometimes needs more
time to start up due to slow processing and no fftw wisdom file and
then Amarisoft eNB times out. This gives the whole process a little
bit more time. Should we still find it too short we may increase
it further.
Use the return value of parse_string function to determine whether a parameter was found.
I experienced issues when the rx_type was set, but the rx_format was not. This led to "Unsupported sample format pub" as the tmp variable is still set to the value of the rx_type.
clang complained about an uinit var that is returned and it turned
out that we don't even implement that function in NEON.
I've found a nice MIT-licensed header that was easy to integrate.
this fixes the subframe-accurate rx in tracking mode.
previously we've only alligned to the next subframe start in find and
when there was a single overflow we've lost the track.
this patch calculates the offset in samples to the actual start of the
subframe (full ms of the receive timestamp) vs. the actual
receive timestamp and uses the value as the "next_rf_sample_offset"
to realign on the next receive
we've used a macro that can return -1 as access index
for an array. this has now been converted in a member
that is initialized and checked during init
fixes Coverity issue 1480088 where srslte_ue_dl_find_dl_dci() expects
an array of struct srslte_dci_dl_t but is only given one element.
srslte_ue_dl_find_and_decode() itself only uses the first decoded
message but find_dl_dci() may still decode more than that
this turns off some Lime specific tweaks that we did, for example
turning off streaming before changing the sampling rate.
those are now implemented inside the LimeSuite (as of 20.01)
and are no longer required here
patch also disable the explicit BW setting and async background thread
It allows to provide an index for tx_port, rx_port, tx_freq and rx_freq even
for the first (and possibly only) port. So for example a MIMO config would be this for example:
tx_port0=tcp://*:2001,tx_port1=tcp://*:2003,rx_port0=tcp://localhost:2000,rx_port1=tcp://localhost:2002
the missing mem zero'ing caused the unit test to fail on some
machines where the memory wasn't initialized by default.
for d and d16 allocate the maximum number of bits, not
only the max length of a DCI
* Use task id to track old background tasks in RA procedure
* Improve robustness against RF overflow in PHY
* Increase SNR out-of-sync threshold
* Do not change frequency if it's the same
* Increase sync priority
* Increase time to start receiving to reduce input buffer occupation
* Use scoped lock in sf_worker