12 Feb
2013
12 Feb
'13
4:46 a.m.
I've figured this one out. Just sharing in case it helps other newbies like
me.
Softbits are necessary for convolutional decoding only. For all other
processing hardbits should be used.
There is no problem with "osmo_ubit2pbit_ext()". We just have to feed it
hardbits and not softbits! :-)
B
On Tue, Feb 5, 2013 at 11:52 PM, Bhaskar11 <niceguy108(a)gmail.com> wrote:
While playing with ccch_scan, I came across a strange
problem.
At some point the code uses:
/* Convert to softbits */
for (i=0; i<116; i++)
bursts[(116*bid)+i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1);
After this, "xcch_decode()" works ok and "osmo_ubit2pbit_ext()" also
works
ok. But "osmo_ubit2pbit()" fails as it converts almost all softbits to 0xFF.
Is this a bug or a "feature"? Do we need to recode "osmo_ubit2pbit"
so
that its bit-checking is more robust as in "osmo_ubit2pbit_ext"?
Sylvain, can you explain the idea of using softbits instead of hard
binary? Is it for GSMTAP to represent signal strength?
Thanks in advance for your help.
B