This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
We really want to have those two as distinct operations - and we
want proper state machines in L1 to quickly return if they've
managed to acquire a FB or SB or not. Otherwise scanning will
take ages...
This code now introduces a new l1ctl_fbsb_req that is sent via
L1CTL to ask for a bitmask of FB0/FB1/SB operations. The actual
FB0/FB1 detection now no longer runs for 500 TDMA interrupts
but completes as soon as we either know there is no FCCH,
or that our frequency error is smaller than a caller-specified
threshold.
FB0/FB1 are already working, SB is not yet, sorry.
* remove linuxlist.h copy and use osmocore
* don't put 'struct gsm_time' into l1ctl packets
* include rx_level and snr for each burst in l1ctl
* properly build libosmocore.a for target
* move gsmtime functions into libosmocore
* move ctype.h to standard location
The cause is really not clear. The formual using 2*Pi to convert
from radians to frequency is perfectly correct.
However, measurements with various test equipment (including Racal 6103)
have shown our frequency error estimate is always off by a power of two...
Pablo Neira Ayuso
Harald Welte