Structure of traffic data in burst_ind messages
Bhaskar11
niceguy108 at gmail.com
Sat Jan 26 20:17:49 CET 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