This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Bhaskar11 niceguy108 at gmail.comI'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.htm>