I&#39;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  &quot;osmo_ubit2pbit_ext()&quot;. 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">&lt;<a href="mailto:niceguy108@gmail.com" target="_blank">niceguy108@gmail.com</a>&gt;</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&lt;116; i++)</font></div><div><font face="courier new, monospace"><span style="white-space:pre-wrap">		</span>bursts[(116*bid)+i] = bt[i] ? - (bi-&gt;snr &gt;&gt; 1) : (bi-&gt;snr &gt;&gt; 1);</font></div>

</div><div><br></div><div><br></div><div>After this, &quot;xcch_decode()&quot; works ok and &quot;osmo_ubit2pbit_ext()&quot; also works ok. But &quot;osmo_ubit2pbit()&quot; fails as it converts almost all softbits to 0xFF.</div>

<div><br></div><div>Is this a bug or a &quot;feature&quot;? Do we need to recode &quot;osmo_ubit2pbit&quot; so that its bit-checking is more robust as in &quot;osmo_ubit2pbit_ext&quot;?</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>