osmo-bts-trx error logs -- was: GPRS on osmo-trx not working

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/OpenBSC@lists.osmocom.org/.

Tom Tsou tom at tsou.cc
Tue Jul 5 22:38:27 UTC 2016


On Tue, Jul 5, 2016 at 4:35 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> My osmo-trx setup is working well now: GPRS and voice are both functional, but
> I do see a *lot* of error messages in the osmo-bts-trx log. I've pasted a 5-odd
> minute long log below. Most logs are errors.

The errors are failed CRC checks. Over a 5 minute interval there
*should* be a large number of CRC failures because of the large number
of bursts that we pass from osmo-trx to osmo-bts. The receive burst
gating in osmo-trx will filter out over 99% of non-active bursts, but
that still leaves a very high number of false detections that need to
be further gated by the CRC check in osmo-bts.

For testing purposes where low SNR detection is not a concern,
increasing the detection threshold in osmo-trx will reduce the false
detections and CRC checks.

diff --git a/Transceiver52M/Transceiver.cpp b/Transceiver52M/Transceiver.cpp
index a1d0f49..b5f6ee5 100644
--- a/Transceiver52M/Transceiver.cpp
+++ b/Transceiver52M/Transceiver.cpp
@@ -51,7 +51,7 @@ using namespace GSM;
  * correlated synchronization sequences. Lower values pass more bursts up
  * to upper layers but will increase the false detection rate.
  */
-#define BURST_THRESH                   4.0
+#define BURST_THRESH                   10.0

 TransceiverState::TransceiverState()
   : mRetrans(false), mNoiseLev(0.0), mNoises(NOISE_CNT), mPower(0.0)

Alexander has suggested that the detection threshold should be
configurable from the socket control interface. I tend to agree.

> I'm ignoring the error logs, because all seems to be working well. But it
> certainly looks like some things want to either be fixed or be shut up about.
>
> Note that the log level for DL1C is 'notice', so these are quite prominent log
> messages in terms if log priority. Is there really something wrong? Otherwise
> I'd suggest moving these to log level 'info' or 'debug' even.

Our current strategy is to pass more bursts to osmo-bts, not less, and
let the CRC determine whether a burst is valid or not. Downgrading the
CRC failure to 'debug' makes sense with this approach.

  -TT



More information about the OpenBSC mailing list