Structure of traffic data in burst_ind messages
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?
On Fri, Jan 25, 2013 at 1:13 AM, Sylvain Munaut <246tnt at gmail.com> wrote:
> > 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 ...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel