When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I816689e2aeac9decbc44ba210956a929cc7a3169
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I8ba71ab9ccde4ba25151ecbeb2a323f706b57d43
Before this patch, reconnecting to osmo-trx and attempting to configure it for
another band is not going to work without restarting the process.
The new variable is added in order to still allow POWEROFF followed by a
POWERON without need to reconfigure the device. In that case, previous
configuration is kept.
Change-Id: I43e5e1e4dcb36be605c6bd25dd6a5f3649e244e7
Remove this workaround, as we are not building for debian 8 anymore.
Related: OS#5223
Depends: osmo-ci Ibe7ba124557969df62798ba49c4489e9606c2341
Change-Id: I5519075a7f95fa61b0b5f1825e4e9324b9eede76
There's another related logging line also at INFO level in the caller
path in Transceiver.cpp, but it only prints if detectBurst() failed.
Let's print this one as INFO too, which proved to be a good logging
level. This way user also notices gain is too high despite osmo-trx is
still able to decode bursts.
Change-Id: Ieca4f19ae1099a430e9b838f8b6780b1c61a87a9
downsampleBurst() and the Resampler below it clearly only support or are
confgiured for 1<->4 setup currently.
Change-Id: Iebaff7a34bd24e56627f148182859918accbfa82
Gain setting without a band was apparently led to a very low output
level, thanks to defog for pointing this out.
Change-Id: I8b59d38dd7b0781776c9e61226185879541fdc53
Related: OS#3342
This is only useful if the rf path delays the signal by at least one
frame, and therefore a fairly experimental command that might be removed
or reworked in the future and should not be relied upon.
Change-Id: I29964acffad5bad4f5bcad7f631e435a72979c46
The type used to represent a thread ID is implementation
specific, and may be an opaqe structure, making it unsuitable to be
printed by standard means. Let's use osmo_gettid() instead.
Change-Id: Iaa4d0eaf52b901fff06cc67f8dd8b61ac6084911
Related: OS#5032
new libosmocore osmo-trx already depends on does support printing thread
ID as prefix to all messages (confgiurable through VTY), so there's no
use in printing it in osmo-trx unconditionally.
Moreover, The type used to represent a thread ID is implementation
specific, and may be an opaqe structure, making it unsuitable to be
printed by standard means, so in any case we should be better printing
system's TID instead.
Related: OS#5032
Change-Id: Ie98a21246230c946afc47f4f5b9c6618eefde494
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: Iaa77f8a7d3f752173507afd988bd76a8aa632082
Related: OS#5034
The API was moved to libosmocore, let's use it instead of defining our
own here with all the complexity in build system involved.
Depends: libosmocore.git Change-Id Id7534beeb22fcd50813dab76dd68818e2ff87ec2
Related: OS#5027
Change-Id: I19e32fbc47bd88a668e0c912e89b001b0f8831dd
A wrapper function with better support already exists in debug.c and
announced in debug.h. Let's use that one instead.
Related: OS#5027
Change-Id: I2ccf94f95a531d5873da2a4681cf89cbc5b31422
In Transceiver::addRadioVector() we scale the I/Q samples by scaling
the output voltage of the DAC. A relative factor/divisor/ration in
the voltage domain cannot be used 1:1 in the power domain.
There exist two similar formulas:
a) X_dB = 10 * log10(X_lin / X_ref)
b) Y_db = 20 * log10(Y_lin / Y_ref)
both of them are correct, and according to [1]:
a) If you convert a quantity X that relates to power or energy,
=> the factor is 10.
b) If you convert a quantity Y that relates to amplitude,
=> the factor is 20.
Therefore we should be using 20 instead of 10. This change makes
osmo-trx apply per-lchan attenuation values correctly. Otherwise
it would double the values indicated in TRXD messages.
[1] https://dspillustrations.com/pages/posts/misc/decibel-conversion-factor-10-or-factor-20.html
Change-Id: I98bc00bd25df4913d45e55eb008d715aca76fc7c
Related: SYS#4918
The memory leak was reported by ASan:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f23b488e459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x558e83e39e3c in ChannelizerBase::initFilters() /osmo-trx/Transceiver52M/ChannelizerBase.cpp:84
#2 0x558e83e3a8a0 in ChannelizerBase::init() /osmo-trx/Transceiver52M/ChannelizerBase.cpp:188
#3 0x558e83e2d263 in RadioInterfaceMulti::init(int) /osmo-trx/Transceiver52M/radioInterfaceMulti.cpp:197
#4 0x558e83de76d2 in makeRadioInterface(trx_ctx*, RadioDevice*, int) /osmo-trx/Transceiver52M/osmo-trx.cpp:115
#5 0x558e83dea663 in trx_start /osmo-trx/Transceiver52M/osmo-trx.cpp:600
#6 0x558e83dead6f in main /osmo-trx/Transceiver52M/osmo-trx.cpp:695
#7 0x7f23b2576151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
Change-Id: Ibc4c7edeb9bba517db08fce152d863e6cc0c7bbb
The leak was reported by ASan.
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7fd9c9c29f41 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x55bd63ae2364 in RadioInterfaceMulti::init(int) /git/osmo-trx/Transceiver52M/radioInterfaceMulti.cpp:209
#2 0x55bd63a9c6d2 in makeRadioInterface(trx_ctx*, RadioDevice*, int) /git/osmo-trx/Transceiver52M/osmo-trx.cpp:115
#3 0x55bd63a9f663 in trx_start /git/osmo-trx/Transceiver52M/osmo-trx.cpp:600
#4 0x55bd63a9fd6f in main /git/osmo-trx/Transceiver52M/osmo-trx.cpp:695
#5 0x7fd9c7910151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
Change-Id: Ia4f9d4e47caa86ada98054763573e652d281992c
Allow to drop the uhd runtime dependency of osmo-trx-ipc.
uhd is only required for the driver-test utility.
Related: SYS#5266
Change-Id: Iff91e09684167247c9c7de0141451a5b9344aa0d