30 Jun
2016
30 Jun
'16
1:30 a.m.
On Wed, Jun 29, 2016 at 3:49 PM, Alexander Chemeris
<alexander.chemeris(a)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