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