Structure of traffic data in burst_ind messages

Bhaskar11 niceguy108 at gmail.com
Sat Jan 26 19:17:49 UTC 2013


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.

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.

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?

B



On Fri, Jan 25, 2013 at 1:13 AM, Sylvain Munaut <246tnt at gmail.com> wrote:

> Hi,
>
>
> > I see some interesting
> > code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes
> > received. If possible I'd rather build on existing code that build from
> > scratch!
>
> There is no code that does what's needed for traffic channels in
> osmocom-bb. During normal operation, this is entirely dealt with
> inside the DSP, and traffic_ind deals with some TI specific stuff that
> has no relevance whatsoever in this case.
>
>
> > Can you please point me in the right direction?
>
> again ... GSM 05.03
>
> I will not repeat myself, a third time ...
>
>
> Cheers,
>
>      Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20130127/83c7f827/attachment.html>


More information about the baseband-devel mailing list