Problem with softbits in osmo_ubit2pbit()
niceguy108 at gmail.com
Tue Feb 12 03:46:58 UTC 2013
I've figured this one out. Just sharing in case it helps other newbies like
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! :-)
On Tue, Feb 5, 2013 at 11:52 PM, Bhaskar11 <niceguy108 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel