This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Osmocom BTS-side code (Abis, scheduling, ...)".

The branch, zecke/sysmobts-calibration has been updated discards bc7b625afb3e5cf88e3e4e1320a5415bd48a9606 (commit) discards e121a761baaa2414de4a744392cacdc35db0d324 (commit) discards 02f2ded39e9ae83c89017b9036a6c6cd5bafd0b0 (commit) discards 3d75cb056d4b67b6cd3aeb6c786a201c4f9a6638 (commit) discards 2048b09a6443fab269ee2da55c32c4813482cad4 (commit) discards 814ec0773161fb9d4074cf35edef2ab2c8b2ac65 (commit) discards 1716cb479cfe1ddaa240e7ed1dc6a47f00bdc234 (commit) via 83a549a153a30b8bc7122e0ca2f99ea6fcb1ea44 (commit) via a70c8f1c8ae5b222008888d98bdf7deee411d2e3 (commit) via 0ae0c43883fa3c60ed3adf9703236db873b4229f (commit) via 3bf0b4382a75cf8a36fe2eeed9d8ff7085c92125 (commit) via 84f21fbcb5b4b8677f6c20f73bb38430dbde0a48 (commit) via f2fbdcff6b49bab3f9f202d8f7212bfc63145ce7 (commit) via 553db72509fb6936e782a75cd04d1ed91d00f12c (commit) via d81b78b524c823122d569fc09f4a764b7a2e13f2 (commit) via 8fc2630dd4884ffeb4c5fc93457c8c06e6dbf918 (commit) via bd988f6ad3624ae0be3bdc19143d4db0290744f5 (commit) via 1e245336ecfe6cbdf3c4253ca5557146d493126d (commit) via 4457c0d9ba73a0f8f9e95bb24dd3f33f469b4fe3 (commit) via 660116fb9d7b382808377274ae4aed7c45e980e3 (commit) via b15d2c9d2f8ebe56672ab2191a4dc39d22fa0ab8 (commit) via 50dc96507caba9480938eb3d9d0db9236f877b49 (commit)

This update added new revisions after undoing existing revisions. That is to say, the old revision is not a strict subset of the new revision. This situation occurs when you --force push a change and generate a repository containing something like this:

* -- * -- B -- O -- O -- O (bc7b625afb3e5cf88e3e4e1320a5415bd48a9606) \ N -- N -- N (83a549a153a30b8bc7122e0ca2f99ea6fcb1ea44)

When this happens we assume that you've already had alert emails for all of the O revisions, and so we here report only the revisions in the N branch from the common base, B.

Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below.

- Log ----------------------------------------------------------------- http://cgit.osmocom.org/osmo-bts/commit/?id=83a549a153a30b8bc7122e0ca2f99ea6...

commit 83a549a153a30b8bc7122e0ca2f99ea6fcb1ea44 Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Tue Dec 23 11:47:28 2014 +0100

sysmobts: Create a calibration loop that will be run

Continously run the calibration process. Everytime we call the reset function classify the outcome. In case of a failure schedule the next command soon and otherwise wait several hours.

Remember if the process was started through the VTY or the run loop. In case it can't be started immediately reset and schedule a new run.

http://cgit.osmocom.org/osmo-bts/commit/?id=a70c8f1c8ae5b222008888d98bdf7dee...

commit a70c8f1c8ae5b222008888d98bdf7deee411d2e3 Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Tue Dec 23 09:45:55 2014 +0100

sysmobts: Start the calibration the first time the link is up

After a reboot the system might have been off for a long time and the currently used value might be wrong. Remember that we never ran the calibration and execute it on start.

http://cgit.osmocom.org/osmo-bts/commit/?id=0ae0c43883fa3c60ed3adf9703236db8...

commit 0ae0c43883fa3c60ed3adf9703236db873b4229f Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Mon Dec 22 18:24:57 2014 +0100

sysmobts: Initial version to use libgps to determine FIX state

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.

http://cgit.osmocom.org/osmo-bts/commit/?id=3bf0b4382a75cf8a36fe2eeed9d8ff70...

commit 3bf0b4382a75cf8a36fe2eeed9d8ff7085c92125 Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Tue Jan 6 19:11:49 2015 +0100

sysmobts: The correction for GPS is in the reverse direction

Change the sign before passing it as correction value. The error is the difference between the TCXO and GPS. We need to correct by the reverse of the error. This seems to be different depending on the clock source we have.

This is a last minute untested change.

http://cgit.osmocom.org/osmo-bts/commit/?id=84f21fbcb5b4b8677f6c20f73bb38430...

commit 84f21fbcb5b4b8677f6c20f73bb38430dbde0a48 Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Fri Dec 12 21:54:43 2014 +0100

sysmobts: Use the ctrl interface for calibration

This runs the entire procedure for calibration with reasonable error and success checking. It can be triggered from the VTY of the sysmobts-mgr right now.

What is missing is to hook up with GPSD to check if the system has a fix and provide a mode that will continously run the calibration command.

http://cgit.osmocom.org/osmo-bts/commit/?id=f2fbdcff6b49bab3f9f202d8f7212bfc...

commit f2fbdcff6b49bab3f9f202d8f7212bfc63145ce7 Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Fri Dec 12 19:20:17 2014 +0100

sysmobts: Copy more of l1if_rf_clock_info_reset into the CTRL code

The CTRL code should have used/extended the l1_if calibration code. The sysmobts-mgr code first needs to determine if the clock adjustment is necessary at all. This is done by first resetting the counters, then waiting, then asking for the diff and then applying the correction value. But the reference clock is only set by the application comand.

Copy more code of l1if_rf_clock_info_reset to set the reference clock as value. This is leaving some todos inside the code that will be resolved as part of SYS#835.

Related: SYS#835

http://cgit.osmocom.org/osmo-bts/commit/?id=553db72509fb6936e782a75cd04d1ed9...

commit 553db72509fb6936e782a75cd04d1ed91d00f12c Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Fri Dec 12 16:59:41 2014 +0100

sysmobts: Begin with calib control from the sysmobts manager

In the long run we will connect to GPSD and wait for a fix and then run the calibration. The first step is to open (and re-open) the control connection to the BTS.

As the connection is on localhost there should not be a computation overhead to always have the connection open. When connecting assume that the ASYNC connect worked directly as otherwise we get no notification of the failure.

This looks like a "bug" of libosmo-abis that should check if the socket has been connected or not.

http://cgit.osmocom.org/osmo-bts/commit/?id=d81b78b524c823122d569fc09f4a764b...

commit d81b78b524c823122d569fc09f4a764b7a2e13f2 Author: Holger Hans Peter Freyther holger@moiji-mobile.com Date: Fri Dec 12 16:54:08 2014 +0100

msg: Generalize the message structure test

This was taken out of LaF0rge's OML router branch and is now used by the extended calibration feature.

-----------------------------------------------------------------------

Summary of changes: include/osmo-bts/Makefile.am | 2 +- include/osmo-bts/cbch.h | 16 +++ include/osmo-bts/gsm_data.h | 6 + src/common/Makefile.am | 3 +- src/common/bts.c | 2 + src/common/cbch.c | 196 +++++++++++++++++++++++++++ src/common/measurement.c | 4 + src/common/oml.c | 18 ++- src/common/rsl.c | 33 ++++- src/common/support.c | 4 + src/common/vty.c | 15 +- src/osmo-bts-sysmo/l1_if.c | 5 + src/osmo-bts-sysmo/misc/sysmobts_mgr_calib.c | 21 ++- src/osmo-bts-sysmo/misc/sysmobts_mgr_nl.c | 11 +- src/osmo-bts-sysmo/oml.c | 17 +++ 15 files changed, 340 insertions(+), 13 deletions(-) create mode 100644 include/osmo-bts/cbch.h create mode 100644 src/common/cbch.c

hooks/post-receive