After switching to libosmocoding there's no need in low-level bursts
test which is part of libosmocoding anyway.
Change-Id: Icb8caf62ac653a39a7a82f2225e8edeab7f5afb5
add support for the TX/RX antenna-id feature that has been
introduced with release OCTSDR-2G-02.07.00-B1314-BETA. The
user can now set individual ID numbers for the TX and for
the RX antenna.
Change-Id: I872fe3c4d7b593358a4ce2f02cf0726611b9f3aa
With octasics latest release (octsdr-2g-02.07.01-B1351-beta), some struct
members are moved or renamed. This patch adds ifdef-logic and configure
checks to restore compatibilty.
Change-Id: I73287983e8bed8bf64b2ab87e6b810c2c59ea6fd
This tests the computations of the tx_power.c code using sysmoBTS 1002,
1020, 1100 and 2050 values, as well as the power ramping code.
Change-Id: I1cc88d4c6edff326e2e67d4f869aa02c9b2b1ac5
The header file octphy/octvc1/gsm/octvc1_gsm_default.h is not
visible to the configure script when the octphy header files
are referenced via --with-octsdr-2g instead having them
installed in /usr/local/include. This results in a failed
AC_CHECK_MEMBER check for tOCTVC1_GSM_TRX_CONFIG.usCentreArfcn,
even if header files with multi-trx support are used.
The configure.ac script manipulates the CPPFLAGS in order to
make the octphy include files visible to AC_CHECK_ and restores
the original CPPFLAGS when done. This is required when
--with-octsdr-2g is used. AC_CHECK_MEMBER is executed
before the CPPFLAGS are manipulated. This causes no issues
if the headers are properly installed to /usr/local/include,
but does not work when --with-octsdr-2g is used.
This commit moves the AC_CHECK_MEMBER command into the section
where the manipulated CPPFLAGS are valid in order to fix the
problem described above
See also commit: f5494e84e8
Change-Id: I7bdfa4449cd6061c395cce315b372c2833520e37
The multi-trx had to be removed because of build conflicts
with octphy header that lack the struct members for needed
to support multi-trx.
For details see the following revert-commits:
ed6b48e4a5c9a1f284ac
This commit reintroduces multi trx support and ads an ifdef
decision to ensure that header files without multi-trx
support still work.
Change-Id: I7f9b2906cc149c817183745b4c96bcc7f9ebdad0
Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I02153ad52faf1465e9f7821378e04118f17352d2
This commit adds basic support for the Litecell 1.5. Multi-TRX is not
supported yet. Instead, multiple instances of the BTS can be launched
using command line parameter -n <HW_TRX_NR> to specify if TRX 1 or
2 must be used by the bts. Note that only TRX 1 opens a connection to
the PCU. Full support for GPRS on both TRX will come at the same time
than the multi-TRX support.
The BTS manager has been adapted to match the new hardware but otherwise
it has not been improved or changed compared to the one used on the
SuperFemto/Litecell (sysmobts).
This reverts commit 94a05abb98.
The tests don't work well with subdir-objects, so we have to live with
the warnings meanwhile until somebody finds time to find the magic spell
to solve the autotools quest.
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
We should only calibrate the clock if there is a GPS fix. Start
gpsd to determine if there is a fix or not. Work around trimble
decoding issues (sent an email upstream). We need to gain some
more experience to see if there memory leaks. We also need to
re-schedule the calibration depending on the outcome.
In order to support transmit power reduction by thermal management
as well as the variety of new internal / external PA configurations
of BTSs, we need a slightly more complex system.
Also, as at high power a single dB can be quite a big difference,
we are now doing all computations in milli-dB(m), i.e. 1/10000 bel.
Ramping is now used both for up and down ramping, as that is useful in
cases where you want to gracefully shut down a cell by shrinking its
radius, gradually handing over subscribers to neighboring cells.
Furthermore, this code is becoming part of the 'common' codebase, as it
is not really specific to how sysmobts is working.
The user can specify a single aggregate value for external system
gain/attenuation. Let's say you have 1dB loss of antenna cable, so you
can put that as 'user-gain -1' into the config, which means that a
'transmit power of 20dBm' will be compensatet for that and the TRX is
instructed to output 21dBm to compensate the cable loss. Similarly,
external PAs can be described by a positive user-gain.
One of the next steps will be to communicate those values and the
nominal power capability of the specific BTS to the BSC, so the BSC will
automatically show correct signal levels in the VTY and log files.
The code includes provisions for future extensions regarding
* an external and an internal PA with calibration tables
* a thermal attenuation setting to be controlled by the site manager
Limit the range from 0 to (_MAX_SYSINFO_TYPE - 1) instead of
0 to 31. This way we will never access the lchan->si.buf[] out
of bounds. This is only a theoretical issue though as the code
filling the lchan->si.buf for the SACCH will not have valid
>= _MAX_SYSINFO_TYPE. Add a small regression test to check we
still schedule all SIs.
Fixes: CID 1040765
Add function for requesting the temperature information to the
microcontroller. I have added a function that we can extend
for requesting more information but in this case we only need to
know the temperature.
I have added to a microcontroller temperature handling function
in the manager for monitoring this information.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
The first test checks the AGCH may queue length computation.
The second test fills the queue by calling bts_agch_enqueue() with a
mix of IMM.ASS and IMM.ASS.REJ. Then it drains the queue by calling
bts_ccch_copy_msg(). After each of both steps, statistics are printed
out.
Sponsored-by: On-Waves ehf
libosmoabis has a BTS-side implementation of the IPA protocol for years,
and osmo-bts should have used that all the time. Unfortunately it had
its own local hack, this patch is migrating to the libosmocore
implementation.
During development one switches from GSM900 to GSM1800 and GSM850 to
GSM1900. This commit attempts to make this switch more easy.
GSM1800 and GSM1900 have overlapping ARFCNs. This means that the
mapping from bands to arfcn is not injective. Because of that I
removed the code to deduce the band from the ARFCN. This was done
in commit 8c3d807b3f. The auto-band
option allows to move between GSM900/GSM1800 and GSM850/GSM1900.
Add a simple testcase with these auto-band configurations.
This was found and debugged by Sylvain. The BTS will always support
A5/0 so we do not keep track of that, the first bit of the flags is
used for A5/1, second for A5/2... but for RSL there is an offset to
go from RSL to A5(x). Add a testcase and change the code.
* Comment out the osmo-bts-bb/Makefile as we have removed it from
the SUBDIRS and are not packaging the code right now
* Add missing include files for the build
Right now osmo-bts requires access to one OpenBSC header file and
this requires that openbsc and osmo-bts git are in the same directory.
Begin with making the location of the OpenBSC sourcecode configurable.
This approach will allow to build osmo-bts on our Jenkins installation
but now has the risk of more code including the openbsc/*.h header files.
Check that adding a paging command works, check that it is expired
after the first call to paging_gen_msg. The test will be extended
to test the scheduling and selection of the various paging messages.
This only implements creating, binding, connecting and free'ing RTP
sockets, not yet anything regarding receiving or transmitting codec
frames on them.
You will need the rtp branch of libosmocore for libosmotrau
This code re-works osmo-bts to add support for the upcoming sysmocom BTS.
It also tries to add some level of abstraction between the generic
part of a BTS (A-bis, RSL, OML, data structures, paging scheduling,
BCCH/AGCH scheduling, etc.) and the actual hardware-specific bits.
The hardware-specific bits are currently only implemented for the sysmocom
femtobts, but should be (re-)added for osmocom-bb, as well as a virtual
BTS for simulation purpose later.
The sysmocom bts specific parts require hardware-specific header files
which are (at least currently) not publicly distributed.
Max
Philipp Maier
Harald Welte
Neels Hofmeyr