In AC_INIT(), it still stated openbts. Let's clean this up and use
the same method of version generation that we use in all other osmocom
projects, too.
Change-Id: Ie7ae0585955aebdc3950b1dd8bff0d1fff3be212
There's no need to explicitly mention library package because
${shlibs:Depends} will take care of it automatically.
Change-Id: Ibd9cfc3673d828122edb85ba9de7ceb77f0299d0
SCHED_RR allows us to operate osmo-trx reliable even under exceptionally
high system load, as the realtime scheduler priority will have higher
priority than the other "regular" tasks on the system.
Change-Id: Ia2452b9763960b2be37fbeee9d832554da68a53f
Closes: OS#2344
It seems that TX_WINDOW_USRP1 is for devices that do not support tx
sync to timestamp. LimeSDR supports it. Changing to TX_WINDOW_FIXED
greatly reduces number of "dumping stale buffer" messages
Modified to match current master by Harald Welte.
Change-Id: I8de5b165ccd72a62b0f16655618e24ca740d9637
The libdbd dependency is not used because libsqlite3 is used directly -
adjust debian/control to match.
Change-Id: Id2ab1facad703fa0c1d45084e70d41e73dbad6e7
Related: OS#1929
Stop calling writeClockInterface() when receiving commands in Transceiver::driveControl,
otherwise it fools osmo-bts-trx clock skew check because it is always sending a clock
indication with the same fn when it issues any commands during the time in between
CMD POWEROFF and RSP POWERON, because fn is not increased during that period.
Also use mForceClockInterface flag to delay delivery of first IND CLOCK until we start
serving frames, otherwise the first one is sent and only after a long period of time
the next clock indications are sent, when the radio starts to process bursts. That makes
osmo-bts-trx unhappy because it expects to receive an IND CLOCK aprox at least every
400 frames. This way also we send the first IND CLOCK after the RSP POWERON 0 response.
Change-Id: I91b81a4d7627cec39c1814a39ed4be306681b874
Fix MCBTS device setup where the map access was failing on the wrong
assumption that all devices support 1-SPS TX-RX operation. Some devices
and/or configurations such as LIMESDR and MCBTS only support running
at 4-SPS.
Even though certain settings (e.g. number of physical channels or the
FPGA clocking rate) are not dependent on the SPS value, we still need to
specify because we use SPS as a parameter for device classification.
Fixes: OS#2341
Change-Id: I56e939285d585cc38efa6c329e30e3acebb734eb
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
In commit a3dce85f
"sigProcLib: Use explicit NaN check in sinc table generation"
Use of std::isnan(double) was added without namespace specifier,
which may cause build issues depending on whether the C version
isnan() call is available. Add standard namespace to force C++
call usage and potential build issues.
Change-Id: I49328c43fdd690a4e6a2b2e949411aaf5674ead1
Instead use object allocated STL vectors. This simplifies code,
removes the need to explicitly release buffers, and fixes a
memory leak in destructor deallocation. Also, remove simplified
init and release sub-calls.
Maintain partition filter allocation using memalign() for SIMD
alignment requirements.
Change-Id: Ie836982794c10fb1b6334e40592d44b200454846
Using "x < 0.01" is a crude check for detecting NaN condition, which
occurs in a sinc call when x = 0 due to divide-by-zero. Use stdlib
isnan() call for this purpose. Also, as the table is created only
once during initialization, use double floats for table value
generation.
Change-Id: I3a838fe3139fa977dfe906246020a14451185714
Trigonometric sin/cos tables are unused after initialization.
There is no benefit to implementing lookup tables for run-once
operations. Also perform initial calculations in double width
because there is no penalty for doing so.
Change-Id: I45bba5daf8610cbba6af95b92c2142f2256491ff
Vector class already has a semantically odd non-const copy
constructor that serves the same function as a C++11 move
constructor. Make the move constructor semantics explicit
and address Coverity at the same time.
Change-Id: I22e0099abe601b0c59beee808f7560837c6977dd
Fixes: Coverity CID 170738
The osmo-trx internals rely heavily on dynamic alloction of
I/Q signal vectors. In a number of cases there is no reason
to to use dynamic rather than stack based allocation. Convert
these cases accordingly.
Change-Id: If53da1bf77b5944b6117765fa98ce12e1ccdeede
The modulator vector to be shaped by Laurent C1 pulse is complex,
but was set as real. The error does not affect behaviour because
we only support complex-complex and complex-real calculations;
real-real convolution is not supported. So in this case the data
vector was already assumed to be complex despite the improper
flag setting.
Change-Id: I03afc6a93a01fde7a9a02e4eb9d201d3ee37d21a
Upon issuing POWEROFF command to a running transceiver, UHD
interfacing thread state may become undefined if the device
is stopped with I/O threads still active. Bad behavior is
device dependent with only network based USRP devices
affected. USB based device thread behavior stops and shutdowns
as expected. Tested with N200, X300, and B210.
Tested solutions include the following:
1. Set pthread_setcanceltype() with PTHREAD_CANCEL_ASYNCHRONOUS
2. Add sleep delay to allow I/O threads to timeout before
stopping the device
3. Wait for I/O threads to join after cancellation before stopping
the device
This patch resolves the issue by with the third approach. Number 1
is not guaranteed to always work with UHD internals as driver code
may explicitly set thread parameters. Using sleep calls to fix
order-of-operation issues is almost never a good idea.
Change-Id: Ib72ab98a27a02084b040319046c92d1c4157ae4c
Commit 1fb0ce67 "uhd: Use map container for for device parameter access"
inadvertently removed the string identifier for the USRP2 and derived
devices (N200/N210).
Add the missing USRP2 string identifier. Also search for partial string
matches in the UHD provided device and mboard stings. This is necessary
to guarantee that strings such as "N200r3" instead of just "N200" are
sucessfully found.
Tested with N200, X310, B200mini and B210 devices.
Change-Id: Ide4e22418e2cc469418cba018970cb0eb9906697
Also remove entirely completely unused calls. Most of these
calls have been around since OpenBTS conception. Nearly a
decade is long enough time for deprecation.
Change-Id: Ifc122aaff23414c363b4b00f99061eed8a6902d0
OsmoTRX is written in C++ so we might as well use built-in
container types when applicable. Map access allows removal
of significant amounts of special device handling code.
Aggregate device rates and timing offsets into a single
table with access keyed by device/tx-sps/rx-sps tuples.
Change-Id: I8660f75a2b2a13488b913c07637bdd0f5f0f4cf9
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
It is now 2017. We can and should be able to use C++11 features now.
Change-Id: I96477e4125390b17b43a3705bb1daf98fa01c9bb
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Implemeted with a Galois LFSR for speed and flexibility compared to Fibonacci version.
Aliases for three popular PRBS' are added for convenience - PRBS9, PRBS15 and PRBS64.
Note that we can't test PRBS64 completely, because the sequence is too long to
be generated.
Change-Id: Ib5331ba5d0b5819929541686fdd87905e2177b74
Some compilers don't support the __builtin_cpu_supports built-in,
so let's make them able to compile the project anyway.
Change-Id: I0c90402d8e4c9f196c54b066ff30891c8de3ad2b
The '__builtin_cpu_supports' is a GCC's built-in function which
returns a positive integer if the run-time CPU supports specified
SIMD feature and returns 0 otherwise.
This change adds a new check, whether compiler supports this call.
See /gcc/X86-Built-in-Functions.html at gcc.gnu.org for reference.
Change-Id: I797f638573e8c3aae39c28abb157ce2ac419f3f7
HAVE_SSE3 and HAVE_SSE4_1 were never defined if CPU architecture
doesn't match the (86*|x86_64*|amd64*) condition.
Change-Id: I3350b14dbc91e9b388d0b04a0ed22ba27d436313
Despite the macro message says, that cpuid functionality was stripped
it was still partially preset and wasn't used anyhow.
Change-Id: I380bc9c13d29319685781ef27973afe6744fcf3d
This bug only affects generation of normal bursts filled with random bits which
are used in test mode. It doesn't affect operation of osmo-trx during normal
operation. That's why it has stayed unnoticed for so long.
Each Normal Burst has 3 tail bits, not 4.
Also it's better to set stealing bits to 0 for maximum compatibility. We may want to
introduce a selector for each bit whether to set it to 0, to 1 or to a random number.
Change-Id: I0377029556c8b681b3ba3b635bf19572b34546ea
This should fix package build for Ubuntu 17.04: obsolete package
hardening-wrapper was removed which cause .deb build failure.
The dependency on it is incorrect to begin with because we use
DEB_BUILD_MAINT_OPTIONS instead.
Change-Id: I3ea72b4123a280a846086d083c4f3189d611f8cf
The 'diversity' option was an experimental 2 antenna receiver
implementation for UmTRX. The implementation has not been
maintained and current working status is unknown.
In addition to code rot, Coverity is triggering errors in the
associated code sections.
Removal of code cleans up many cases of special handling that
were necessary to accommodate the implementation.
Change-Id: I46752ccf5dbcffbec806081dec03e69a0fbdcdb7
The osmo-trx binary outputs no info about its SSE support status.
This commits adds some putput that informs about the SSE of the
binary and also tells which of the SSE levels the CPU supports.
Change-Id: Iacc83fd668c31644e0efb3e18962cf2870ed1daf
Currently we find SSE3 and SSE4.1 code mixed togehter along with
generic code in one file. This introduces the risk that the
compiler exidantly mixes SSE4.1 instructions into an SSE3, or
even worse into a generic code path.
This commit splits the SSE3 and SSE4.1 code into separate files
and compiles them with the matching target options.
Change-Id: I846e190e92f1258cd412d1b2d79b539e204e04b3
Currently the build environment checks which extension the current
CPU supports and picks the compiler flags accordingly.
If the build is happening on a machine that does not support the
extensions we need (SSE3, SSE4.1), the binary will lack those
extensions, even if its intended to be used on a more powerful
machine that would support the extensions.
This commit removes the CPU tests from the build process.
Change-Id: Ic913aa13c23c348ae62e78c9dfd6ed8b0a62798c
The ARM and the X86 implementation of the conversion functions share
the same, non cpu specific implementation in separate files.
This commit removes the code duplication by putting the generic
implementation into a convert_base.c, similar to to convolve_base.c
Change-Id: Ic8d8534a343e27cde79ddc85be4998ebd0cb6e5c
The current implementation can select the SSE support level during
compiletime only.
This commit adds functionality to automatically detect and switch
the SSE support level and automatically switch the Implementation
if the CPU does not support the required SSE level.
Change-Id: Iba74f8a6e4e921ff31e4bd9f0c7c881fe547423a
Convolution is a complex process and we should be able to verify
if computing results change when the implementation is touched.
This commit adds a test program that executes some testcases.
The testcases are crafted in a way that every implmentation
(several different ones for SSE) is executed once. The output
can be compared against the included .ok file.
Change-Id: Ic702ecb356c652fbcd76bee689717fb5d3526fe9
The non-sse implementation and the sse implementation of the convert
and convolve functions have different parameter lists. This makes it
difficult to use function pointers in order to select the right
function depending on the SSE-Level and CPU.
This commit uniformizes the parameter lists in preparation for
planned runtime cpu detection support
Change-Id: Ice063b89791537c4b591751f12f5ef5c413a2d27
The compiler option -march=native instructs the compiler to auto-optimize
the code for the current build architecture. This is fine for building
and using locally, but contraproductive when generating binary packages.
This commit replaces -march=native with $(SIMD_FLAGS), which contains a
collection of supported SIMD options, so we won't loose the SSE support.
Change-Id: I3df4b8db9692016115edbe2247beeec090715687
OpenBTS relies on reading in configuration values from the OpenBTS.config
sqlite3 database. This configuration method is not maintained and not
recommended for Osmocom or OpenBTS use. Command line setup is the
recommended approach.
Note that when the osmo-trx logging mechanism is replaced, the sqlite
dependency will be removed.
Change-Id: I95d7b771fde976818bee76f89163e72c3a44ecdd