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, Jun 21, 2016 at 11:36 AM, Alexander Chemeris <alexander.chemeris at gmail.com> wrote: > I introduced BER calculations in osmo-bts-trx some time ago for DATA, > so the data is there - see gsm0503_coding.c, *_decode() functions. I > also updated the code to pass this information to upper layers - see > rx_tchf_fn(), rx_tchh_fn(), rx_pdtch_fn() in scheduler_trx.c. I tested > that the data actually gets to measurement reports for TCH and SDDCH, > but I don't remember if we tested this for GPRS. Are you sure it > doesn't work with the current master? If so, it probably got broken > during the rebase or after that. Measurement reports do appear to be going out through l1if_process_meas_res(), but the BER calculation is incorrect because of puncturing, which is significant for higher CS/MCS values. The full BER calculation takes the re-coded and re-punctured sequence (performed after decoding and CRC verification) and compares to the decision sliced receive sequence. But, the full calculation may be unnecessary. A close and simple approximation to the full BER calculation treats all zero valued soft bits as punctured bits and removes them from the calculation. @@ -509,6 +509,8 @@ int osmo_conv_decode_ber(const struct osmo_conv_code if (n_errors) { *n_errors = 0; for (i=0; i< *n_bits_total; i++) { + if (!input[i]) + continue; if (! ((recoded[i] && input[i]<0) || (!recoded[i] && input[i]>0)) ) *n_errors += 1; I think this is a reasonable approach to make the current BER measurement sane. > I didn't do that for RACH, because currently RACH gating is performed > in osmo-trx and works pretty well as far as I can tell, so > osmo-bts-trx gets RACH's which are valid with high probability. > > We can introduce an option to turn osmo-trx built-in RACH gating and > rely on osmo-bts instead and then compare which one works better. That > should be a minor change - I'm happy to implement this a bit later. We will always have some level of burst gating in the TRX to remove clearly invalid or unrecoverable bursts (e.g. unrealistic TOA values). One option is to reduce the detection threshold close to zero so that any 'reasonable' burst is passed. This seems like another reason to add configurable burst threshold detection to osmo-bts-trx. -TT