osmo-bts.git branch zecke/sysmobts-calibration updated. 0.3.0-266-gbc7b625

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-commitlog@lists.osmocom.org/.

gitosis at osmocom.org gitosis at osmocom.org
Tue Dec 23 11:38:30 UTC 2014

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  2eb9812ec53fcaccf5623a1b7aad7fd6373552e5 (commit)
  discards  cbe5e35c60c74cd511a6b4965aae7614863a393c (commit)
  discards  e4894b25e63b25ac3360a483113adc3e6818ae27 (commit)
       via  bc7b625afb3e5cf88e3e4e1320a5415bd48a9606 (commit)
       via  e121a761baaa2414de4a744392cacdc35db0d324 (commit)
       via  02f2ded39e9ae83c89017b9036a6c6cd5bafd0b0 (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 (2eb9812ec53fcaccf5623a1b7aad7fd6373552e5)
             N -- N -- N (bc7b625afb3e5cf88e3e4e1320a5415bd48a9606)

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 -----------------------------------------------------------------

commit bc7b625afb3e5cf88e3e4e1320a5415bd48a9606
Author: Holger Hans Peter Freyther <holger at 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.


commit e121a761baaa2414de4a744392cacdc35db0d324
Author: Holger Hans Peter Freyther <holger at 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.


commit 02f2ded39e9ae83c89017b9036a6c6cd5bafd0b0
Author: Holger Hans Peter Freyther <holger at 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.


Summary of changes:

Osmocom BTS-side code (Abis, scheduling, ...)

More information about the osmocom-commitlog mailing list