Attention is currently required from: pespin.
4 comments:
File Transceiver52M/Makefile.am:
Patch Set #1, Line 100: $(top_builddir)/libosmo-trx/src/libosmotrx.la \
It's already above the `LIBOSMOCORE_LIBS`... […]
Done
File Transceiver52M/Transceiver.cpp:
Patch Set #1, 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.
Patch Set #1, 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.
Patch Set #1, 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 change 43115. To unsubscribe, or for help writing mail filters, visit settings.