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/OpenBSC@lists.osmocom.org/.
Tom Tsou tom at tsou.ccOn Wed, Jun 29, 2016 at 3:49 PM, Alexander Chemeris <alexander.chemeris at gmail.com> wrote: > If I remember this part of the code correctly, this zeroing is required to > make this work when there are lost bursts. E.g. if you need 4 bursts, but > you only received bursts 0, 1 and 2 you should let the device know that your > missing burst 3. If you don't do that, decoder won't run at all and to will > miss what could be a decodable frame. I see. In that case, the PDTCH behavior may not be unusual, but PTCCH case is certainly strange. On PTCCH, the spare burst seems to be triggering such that the 4 segment block sent to the decoder is always all zeros. I'm testing in controlled conditions and closely monitoring signal levels. I don't think we're missing PTCCH bursts in this case. I seems like osmo-bts is attempting to decode something that doesn't actually exist. -TT