I'm able to track the channel and extract the data. But to detect end of traffic I follow the similar code as in ccch_scan by checking the signal to noise ratio of the bursts on the downlink but during SACCH bursts only.<div>
<br></div><div>In most cases app_state.dch_badcnt quickly climbs beyond 6, and the channel is dropped within barely a second. Much of the traffic data bursts also have a very low snr. Very occasionally, the channel stays on for 3 to 5 seconds, then drops. During these rare occasions the traffic data remains with high snr for longer time also.</div>
<div><br></div><div>What am I doing wrong? Is this the right way to detect end of traffic data? Is it normal for this channel to have low snr?</div><div><br></div><div>B</div><div><br></div><div><br><br><div class="gmail_quote">
On Fri, Jan 25, 2013 at 1:13 AM, Sylvain Munaut <span dir="ltr"><<a href="mailto:246tnt@gmail.com" target="_blank">246tnt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div class="im"><br>
<br>
> I see some interesting<br>
> code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes<br>
> received. If possible I'd rather build on existing code that build from<br>
> scratch!<br>
<br>
</div>There is no code that does what's needed for traffic channels in<br>
osmocom-bb. During normal operation, this is entirely dealt with<br>
inside the DSP, and traffic_ind deals with some TI specific stuff that<br>
has no relevance whatsoever in this case.<br>
<div class="im"><br>
<br>
> Can you please point me in the right direction?<br>
<br>
</div>again ... GSM 05.03<br>
<br>
I will not repeat myself, a third time ...<br>
<br>
<br>
Cheers,<br>
<br>
     Sylvain<br>
</blockquote></div><br></div>