this also removes the entire help text around arguments (that
were very outdated already) and only leaves the actual values with changes.
Change-Id: Icb9e8e7b1c68cf024db3a7273af791f017c32003
this config option overwrites the EARFCN config that is typically
used to tell the UE the bands to scan for cells. When custom
frequencies are used, this option allows to set them explicitly.
Change-Id: Ice070ea6755e273d916db2dc941068d33bbe206a
when they are greater than 0 they are written as config paramter.
if they are -1 they are disbaled and automatic gain calibration is
used.
Change-Id: I473ff3ae679784178574d2f76b612dbf77180490
we've provided only all_log_level so far but sometimes it's needed
to select the level per layer. This patch adds the ability
to do so for the NAS layer in the UE.
Change-Id: Iab2bce65e8af81f6d344849c97952e6441cb2846
we've detected a possible race condition during the Msg3
transmission that caused the thread that sets the Msg3 grant
to be delayed. The PHY worker that executed TTI+2 finished
by that time already and didn't even see the pending UL grant.
This is issue is more likely to happen on loaded system,
for example when running parallel ZMQ jobs. We therefore decided
to reduce the number of parallel PHY workers to 2 so the issue
is circumvented.
Change-Id: Ibdb42a1705d87b6d343201458c8fe397398802bc
since ZMQ runs are not using wall clock anyway, measuring
TTI execution isn't useful, disable it therefore to avoid
misleading warnings.
Change-Id: I5c2cb0abcfce0ee67806f6611356f4d5d180541d
the order of checks needs to go from high to low, i.e. the higher
release feature (e.g. qam256) needs to be checked and set first.
in theory it should also be possible to have a CA-capable UE
that does not support QAM256, but for srsUE we announce both anyway.
Change-Id: I2fa49f0cb5d80db412a811ceeb380359c8ad67a7
* add new UE feature
* enable in srsue.conf.templ
* add new table for maximum rates
* add config scenario to enable SIB option for QAM64
Change-Id: I6ac2c9989a761e91b93d76c2507f55f0140b202d
Due to the integration of DL-QAM256 another table for DL max rates is needed.
Therefore, I added the parameter 'qam256' to the feature list in the resource.cfg.
The patch also enables the correct UE settings in the config file.
Change-Id: I2d34395449cdcfb31db66ea887d9adbee551e757
pass-through the option so they can be used in templates
just concatenate with rf_dev_args for srsLTE eNB/UE, arguments
parsing will handle them
Change-Id: I3818026c159780f29968888f547163cdf730afad
the num_carriers is parsed as a string in the conf dict and therefore
needs to converted to int before matching
also changed the num_carriers to be of type UINT
Change-Id: I1386812d32e1181ba666720bbb875bf9bbce0f51
Take the change to fix several small things and support recording pcap
in srsENB.
pcap generation can be enabled with scenario cfg-srs-enable-pcap.
Change-Id: Ia096a9be7efb2123f95115c751e2402fb4fec935
Before this patch, only virtual RF through ZeroMQ was supported.
This patch allows configuring srsUE and srsENB to use a real SDR with
UHD/SoapySDR backend connected through a physical RF network, while
still keeping compatibility to run on virtual RF ZeroMQ network, based
on the resources used (controlled by scenarios). For instance, one can
first run a suite through the phyisical RF (using 2 UHD-controlled SDRs)
and afterwards with ZeroMQ using the following default-suites.conf:
- 4g:srsenb-rftype-uhd+srsue-rftype-uhd
- 4g:srsenb-rftype-zmq+srsue-rftype-zmq
Change-Id: I7dbbe328f4c0225fe74e878bb2da13fe39ccf049
2 tests (iperf3, ping) working against a full srs{UE,ENB,EPC} network
using ZeroMQ backend for RF (so no real RF support yet, that will come
next).
Related: OS##4295, OS#4296
Change-Id: I290c0d79258a9f94f00c7ff2e1c6c5579c0e32f4
Andre Puschmann
Pau Espin