This won't build, and has been in a untested non working state for a
year, but might still be useful after fixing it up in the future in case
someone needs it.
Change-Id: I9db1740b5c399a02a41b1d07792c645cf7d1bd1b
Removing new lines in DISTCHECK_CONFIGURE_FLAGS again is needed, as it
otherwise fails with:
enable-sanitize
/bin/bash: line 1: enable-sanitize: command not found
Change-Id: I049af384eccdb6f8e5b305ca35de106eeaca3fa8
Have one arg per line, and order it mostly alphabetically while at it
(backends are still together, as recommended in review).
Change-Id: I354affacb38958efe70baedc6175aeab525190a6
It just uses the viterbi equalizer and the sigproclib to generate and
demodulate bursts and prints the bits, only useful for
development.
Change-Id: I852e34d9667d1f12f235f8b3da1fcc0d738b2db9
This is basically a fixed version of ttsous ancient branch that can be
used instead of the VA. Required config option part of a future
patchset.
Change-Id: I6558992bd69f18526be5ebe7d424ca00ceb67772
2fc2b594da6e329577b195cb2543a8dd9e1b9ed0 changed std::thread to pthread
for proper affinity to circumvent startup issues, so just stick to
pthread instead of mixing std::thread and pthread, which made tracking
thread creation difficult due to different functions.
Change-Id: I0ba2fd958530394b9d99ed82111064d428c5870f
Sophisticated users can export BLADERF_DEFAULT_TUNING_MODE=fpga which
reduces the startup time to 1 second, or (default)
BLADERF_DEFAULT_TUNING_MODE=host which always works.
Defaulting to fpga mode has the unfortunate side effect that the blade
can get stuck in a weird invalid mode when supplying wrong parameters
that breaks sample streaming until it is power cycled or "reset" by
using host tuning once. So, let's do the safe thing, and not default to
fpga mode.
Change-Id: I109f925f07a198d1fb33fe793e91e455fea05a96
All config file examples must be listed in EXTRA_DIST unconditionally.
Adding them conditionally results in incomplete release tarballs,
containing only some '*.cfg' files and failing to build.
Change-Id: Iffb6d7577de175fc5d14642f0af6852508d74e69
Related: OS#6349
It turns out that uhd versions >= 4.0.0.0 *require* that either the
HOME or the XDG_CONFIG_HOME variables are set, and otherwise will
terminate the program.
Change-Id: I1816013c507da28719590f063da0a397da656a10
Closes: OS#6269
The dev type was set too early, but the actual dev is only being
discovered during open, so update it. This broke the gain to power
mapping by defaulting to a wrong device.
Change-Id: I1dda6023ca6f15bc063c3dfbc704db2410ff7c98
Blade 1 defaults to fpga tuning, but the blade 2 code defaults to host,
which does 8000 register reads and writes. The only way to speed this up
is to set the env var, which reduces opening the blade device from 10 to
1 seconds.
Change-Id: I32fe31f1e11f4ceb3c864ec8739d177e780d0a7e
This should be fine, because we can at most receive 1.5 bursts of data
at once and produce 2 bursts with previous data, so if this is insufficent the usb buffers are late or the upper layer is stuck and we're in trouble anyway.
Change-Id: Ifb8bf2894c87e4234e3d3f65d66c1e98c8f63c53
The new revision contains an important fix [1] for GPRS scheduling.
Change-Id: Ibb57b29bb0424a40836819c15d25d1133f554d32
Related: [1] osmocom-bb.git I439615639b8e840b9fd4f3af6934d9f298f32216
Related: OS#5500
..and fix the delay warning.
I'd rather have a proper fn advance of 1, but that breaks gprs, but just
slightly increasing the ts number is sufficient to fix issues with late
tx bursts that then get silently dropped by the sdr.
The mobile app does not care, and will happily work even with fn+3.
Change-Id: I46b3ea6b0094026bd50709739df464438f9e54c4
This fixes the 20 second startup delay caused by tx/control threads
getting temporarily stuck while trying to set their own priority.
Apparently the only sane way for core affinity+priority is to set both
as attributes during thread creation using pthreads.
This switches the cmd queue to the timeout version, too, to ensure the
thread doesn't get stuck waiting for messages, and allows cleaner exits.
Change-Id: I7e2f83a9b9df024acaf9076c58189cb6b7bcc34b
The VA is already being used by the ms side and is part of the original
gsm design. It only works for gmsk, 4sps, and needs a bit of rx burst
scaling and burst shifting.
Change-Id: I9d7a4ff72e323832a94d885d5714fcde01ceeb3d
This commit adds support for rach bursts to the viterbi equalizer, which
is currently only being used by the ms side, so the equalizer can be used
by the osmo-trx network side, too. The difference is that rach bursts are
shorter than any other burst type (due to unknown TA) and start with
diffrent tail bits.
This drops the multiversioning which was only working for x86 anyway because
it can't be combined with no_ubsan.
Change-Id: I4a5cedc8c9a3289c75ce7b914eac286e601ebed0
After upgrading our CI environment to use Debian 12 with GCC 12, the
byteswap code fails the build with the following. I've talked to Eric
about this and he recommended to just remove the code as practically
nobody will use osmo-trx with a big endian system.
USRPDevice.cpp:591:30: error: 'data' is used uninitialized [-Werror=uninitialized]
591 | *wordPtr = host_to_usrp_u32(*wordPtr);
| ~~~~~~~~~~~~~~~~^~~~~~~~~~
Related: OS#6057
Change-Id: I806d8c1432cb20efca1830a2752a4cbc70384b54
Manual attempts to get the number of complex and single samples right
turned out to be a bit error prone at times...
Change-Id: I3c9953073555e3a7f70b78b0946dfdf949175a82
Pau Espin
Harald Welte
Eric Wild
Oliver Smith
Vadim Yanitskiy
Andreas Eversberg