This is basically a trxcon that includes a transceiver, and can just
be used with existing and future apps supporting the trxcon interface,
i.e. mobile or ccch_scan.
Supports bladerf and uhd, binaries are automatically built if those libs
are detected + the osmocom-bb submodule exists.
Currently using hardcoded sched/prios aimed at a setup with working,
reliable usb and reserved cores, for example a raspi 4 (ONLY 4, not 3,
not 2, not any other version)
Additionally builds test tools used for development: osmo-trx-syncthing*
Change-Id: I36c65a8c725c4da76dc70006cd96b0a2b6878e84
The problem here is that the ipc if requires reducing the clock ind
inteval to a few fn/ts on the trx side to work at all, but scheduling
still does not work out, unless you start driving the IF using the tx
side, at which point the approach is useless, because it does not really
do more than a burst loopback that is easier to do with the higher
layers/interfaces.
The code is still useful should there be a reason to continue working on
this.
Change-Id: I8f582c7c06fed8d1dcc5ea52472a97dc313fdde5
This is not really finished, there are multiple reasons to not use this:
1) main clock is not a gsm multiple, so it will continously drift
2) small buffer sizes lead to tx gaps that are hard to detect and break
everything.
Change-Id: I455c34bb9520d5f09eeb1ac76fceb4bdea94d1ac
It does not make sense for the MS to use 11-bit Access Bursts on
PTCCH/U because the payload does not matter, only the ToA does.
Change-Id: I5fb9f1c6810cdcd26a885b183e414d01d422eb28
By default systemd will execute service with root directory
(or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it
to 'osmocom' subdir of state directory
(/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I041bb9e0b4250826d2d15d0ea2cdb93d7a0cd04b
Avoid building osmo-trx a second time on arm during "make distcheck". If
the build of osmo-trx already passed on arm, running "make distcheck"
should give the exact same result as on x86_64.
This should shorten the build time significantly for osmo-trx jobs
running on raspberry pis, currently they take half an hour.
Change-Id: Ib4fbf7d54d479bbdda3c1415493bfc57b37d3971
Fix for the following error we see since building master-osmo-trx on
debian 10 instead of 9:
/usr/bin/ld: ipc_driver_test-uhdwrap.o: undefined reference to symbol '_ZTIN5boost6detail16thread_data_baseE'
/usr/bin/ld: //usr/lib/x86_64-linux-gnu/libboost_thread.so.1.67.0: error adding symbols: DSO missing from command line
After spending a lot of time on researching this, my understanding is
now that uhd.pc should have had "-lboost_thread" in versions up to the
latest release 4.2.0 because before that it would include boost thread
headers in its logging code:
04a83b6e76
ld is able to figure out which library provides the missing symbol, and
apparently depending on the binutils version and linker flags, it may
just ignore this and not show an error. This is why apparently it worked
with debian 9 and still does work in OBS (different flags), and why it
was not fixed upstream in uhd.pc. By now fixing it is not needed in the
latest version anymore, and there are already versions of uhd.pc in
various linux distributions without -lboost_thread, so I think it's
appropriate to add the workaround here in configure.ac.
Fixes: OS#5608
Related: https://stackoverflow.com/q/19901934
Change-Id: I0367f1c2981bf56252e7514d5993cbbec960b21b
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