Attention is currently required from: pespin. fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-trx/+/43115?usp=email )
Change subject: Transceiver52M: migrate to libosmo-trx ...................................................................... Patch Set 2: (4 comments) File Transceiver52M/Makefile.am: https://gerrit.osmocom.org/c/osmo-trx/+/43115/comment/0c438109_a2cc79a8?usp=email : PS1, Line 100: $(top_builddir)/libosmo-trx/src/libosmotrx.la \ > It's already above the `LIBOSMOCORE_LIBS`... […] Done File Transceiver52M/Transceiver.cpp: https://gerrit.osmocom.org/c/osmo-trx/+/43115/comment/df23277f_437358a5?usp=email : PS1, Line 660: /* Convert a soft bit normalized to 0..1 (1.0 = confident '1') into the > I wonder where this change come from. […] `float_soft_bit_to_sbit()` isn't new - it's the same quantization step the old code always did; moved here from `Transceiver52M/proto_trxd.c`. It's not 100% equivalent to the old `trxd_fill_burst_normalized255()`, though. libosmo-trx's shared `osmo_trxd_burst_ind_build()`/`osmo_trxd_burst_req_build()` don't take raw floats. In `struct osmo_trxd_burst_ind`, the burst buffer is typed `sbit_t`, not a raw 0..255 wire byte. This is why this function is different: here we're converting from `float` to `sbit_t`, not directly to the raw wire format. The real problem that I see here is that we're now doing several rounds here: `vectorSlicer()` converts from -1..+1 to 0..1, then `float_soft_bit_to_sbit()` converts 0..1 to 127..-127, and then the library converts from 127..-127 to the wire format. This quite a lot of overhead. I'll rework the patch to avoid an additional step, i.e. convert from -1..+1 directly into soft-bits. https://gerrit.osmocom.org/c/osmo-trx/+/43115/comment/8ffade84_b19a224b?usp=email : PS1, Line 695: float soft_bits[OSMO_TRXD_BURST_LEN_MAX]; > this can also probably be split onto the mentioned previous preparation patch? This intermediate buffer is no longer needed and will be removed. https://gerrit.osmocom.org/c/osmo-trx/+/43115/comment/85e04a29_c733a4e8?usp=email : PS1, Line 801: bi->toa256 = (int16_t) lround(ebp.toa * 256.0); > I see tons of changes in how the bi fields are being set, do you mind > explaining why? Can this be do […] The reason is that libosmo-trx's `struct osmo_trxd_burst_ind` is different from the old `struct trx_ul_burst_ind`. Specifically, for fields like `rssi`, `toa`, and `ci` we're using integer types (not `float` or `double`). So whatever conversion was done in `proto_trxd.c` has to be done here. The main difference from old code is that I am using `lround`, which is better because it handles negative values correctly. The old logic (`(type) x + 0.5`) worked fine for positive values, but negative values would lean towards zero instead of rounding to nearest. For the sake of cleanness, I'll migrate to `lround` in a preceding commit. Also, I just noticed that I forgot to update `ci_cb` to `lround` - will do in that commit too. -- To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/43115?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Change-Id: I458ec85c56e2101d073c8c35f11c147191c4ea0c Gerrit-Change-Number: 43115 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <[email protected]> Gerrit-Attention: pespin <[email protected]> Gerrit-Comment-Date: Mon, 03 Aug 2026 20:23:26 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: fixeria <[email protected]> Comment-In-Reply-To: pespin <[email protected]>
