We only need to run this once and we know the clock error. In case it
is 0/0 we know that we didn't receive one of the two clocks. This could
be because the GPS doesn't have a fix. I accidently pushed this code into
the master branch and it is too late to rebase.
We need to read the Layer1 message queues fast enough, switch on
realtime processing for that. Move the firmware init after the
process execution to have some time for the firmware to reload
before the application sysmobts is restarted.
Migrate the LED and firmware reloading into a systemd service. This
makes the respawn and screen obsolete as it will be done with systemd
and the journal script.
This starts sysmobts-remote and dumps the documentation about the
VTY to the doc/ directory.
$ ./contrib/dump_docs.py
this writes doc/vty_reference.xml
From our header files v2.4 onwards, we include some macros that allow us
to do compile-time checks for the API header version. As older headers
don't have those macros, we have to fall back to assume it will be v2.2
It has been tested with the OCXO and the network listen mode of the
firmware. For other sources we are not required to synchronize to
the network and the tool needs to be adjusted.
Once we get RF-ACTIVATE.conf from L1, we now enable the corresponding
LED. We also switch it off on RF-DEACTIVATE.conf. We do _not_ switch
it off when osmo-bts crashes or terminates before RF-DEACTIVATE.conf.
The latter is intentional, as RF may very well still be active at that
point. The re-spawning script will re-set the DSP and therby turn off
the RF and then disable the LED.
A better solution might be to do all this in the kernel driver for the
DSP.
Holger Hans Peter Freyther
Harald Welte