I've figured this one out. Just sharing in case it helps other newbies like me.<div><br></div><div>Softbits are necessary for convolutional decoding only. For all other processing hardbits should be used.</div><div><br>
</div><div>There is no problem with  "osmo_ubit2pbit_ext()". We just have to feed it hardbits and not softbits! :-)</div><div><br></div><div>B</div><div><br><br><div class="gmail_quote">On Tue, Feb 5, 2013 at 11:52 PM, Bhaskar11 <span dir="ltr"><<a href="mailto:niceguy108@gmail.com" target="_blank">niceguy108@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While playing with ccch_scan, I came across a strange problem.<div><br></div><div>At some point the code uses:</div><div>
<div><font face="courier new, monospace"><span style="white-space:pre-wrap">      </span>/* Convert to softbits */</font></div>
<div><font face="courier new, monospace"><span style="white-space:pre-wrap">      </span>for (i=0; i<116; i++)</font></div><div><font face="courier new, monospace"><span style="white-space:pre-wrap">                </span>bursts[(116*bid)+i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1);</font></div>

</div><div><br></div><div><br></div><div>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.</div>

<div><br></div><div>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"?</div><div><br></div><div>Sylvain, can you explain the idea of using softbits instead of hard binary? Is it for GSMTAP to represent signal strength?</div>

<div><br></div><div>Thanks in advance for your help.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>B</div></font></span></blockquote></div></div>