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