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.