When pushing traffic with iperf the UE was crashing.
The argument passed to pthread_mutex_timedlock is absolute time based
on the CLOCK_REALTIME timer, not relative time. That seems to be the
root cause of the bug. (That there is a timeout is another story.)
This commit uses absolute value.
Also we separate cases between IS_SOFTMODEM_BASICSIM / IS_SOFTMODEM_RFSIM
and standard realtime UE. In the 'sim' modes we don't care about
timeout and just call pthread_mutex_lock. It seems to be the idea
of the original work. If not, then to be fixed.
-- pipeline is polling the develop-nr branch
-- new conf file / new scenario files
-- main python now supports LTE and 5G-NR executables in a Ubuntu/CentOS env
* Instead of partly initializing in read_config_and_init(), everything of
PDCP is initialized in main() of lte-softmodem
* Omit RC.rrc access in RRU through checking of RC.nb_inst > 0
* Includes FlexRAN, i.e. do not start FlexRAN in RRU
* Function pointers to PDCP functions have to be set explicitly (avoid
confusion of multiply setting function pointers)
Not much major changes. In openair1/PHY/LTE_UE_TRANSPORT/dci_tools_ue.c,
in the function generate_ue_dlsch_params_from_dci,
'harq_pid' was removed and dci_info_extarcted.harq_pid is now used for
all cases.
The ue T tracer only deals with PHY signals (no MAC, RLC, PDCP, RRC).
end_of_burst_delay is used to stop TX only "after a while".
If we stop right after effective signal, with USRP B210 and
B200mini, we observe a high EVM on the S subframe (on the
PSS).
A value of 400 (for 30.72MHz) solves this issue. This is
the default.
This default value can be changed in the configuration file.
For example:
RUs = (
{
local_rf = "yes"
nb_tx = 1
nb_rx = 1
att_tx = 20
att_rx = 0;
bands = [7];
max_pdschReferenceSignalPower = -27;
max_rxgain = 105;
eNB_instances = [0];
sf_extension = 312;
end_of_burst_delay = 200;
}
);
Here we would set a value of 200.
The value to put in the configuration file is for
30.72MHz. The value is scaled accordingly at runtime
(thus only one value to set for every RB configuration,
25, 50 or 100, leading to less problems when adapting
configuration files).
This option is for experts and should not be changed
randomly.