On Tue, Jul 5, 2016 at 4:35 AM, Neels Hofmeyr <nhofmeyr(a)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