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
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
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
..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
The timekeeper should never wait for lazy readers, because that causes
timekeeping and later usb transfers to fail.
Change-Id: Id0aad606a296b2885617013ce6637204357b13d7
One of the mystery bugs was that the blade ms needed two starts
after powercycling the bladerf due to transfer timeouts.
This is now fixed.
Change-Id: I1cd8790191790f4861a70bc55c8f4c9993fa10c8
* AM_CPPFLAGS is for preprocessor flags like '-I' or '-D',
* AM_CFLAGS/AM_CXXFLAGS is for C/C++ compiler flags like '-Wall',
* AM_LDFLAGS is for linker flags like '-no-undefined', not libraries!
* Link ipc-driver-test against libdevice.la,
* Do not put $(UHD_CFLAGS) everywhere.
Change-Id: Iafd68974c9c613fb4e65a01d076b2c687b716c83
The "safe" scaling factor introduced in
7ac54b10d3 is too low and dates back to
the beginning and the move from usrp1->uhd, but the modulator will
exceed +-1 so "proper" scaling leads to overflows. Let's just do what
osmotrx has been doing for many years...
Change-Id: I75a2eba1f7f7b81249c06ce3fc9dfeee08878cb9
Given integral type A and non integral type B and depending on rounding
mode, optimization, compiler, and phase of the moon A(A)*B != A(A*B) so
split the two cases.
While at it, also make the template automagically work for complex types
instead of requiring manual casts, the general idea here is to allow
inlining and vectorization by treating all args as plain arrays, which is fine.
This works as expected with -tune=native, x64 implies sse2, and we do not
target any neon-less arm versions either.
Clang only array length hints can improve this even more.
Change-Id: I93f077f967daf2ed382d12cc20a54846b3688634
5561f1129d introduced some changes,
but while RadioInterface lost its call to close() that was previously
used to improperly reset the buffers upon init() that call was
accidentally not removed for RadioInterfaceMulti and
RadioInterfaceResamp, so those reset previously initialized values to 0
during init(), which break osmo-trx for weird setups.
Change-Id: I74fc1586f8ae0832f4093ba8a44a1c70c78ec3d8