Hi. There seems to be peculiar coding error with osmo-bts-trx and usrp b210: ... <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550946 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550950 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550955 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550959 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] ... The error seems to: - happen only on 2nd subslot of TCH/H - does not prevent calls establishement - let voice to go through The visible effect though is extra delay for call establishment when BSC allocates next available subslot - see https://projects.osmocom.org/issues/1795 for details. Have anyone else seen this? It could be that tch_hr_decode() screw up bits somehow while trying to decode stolen FACCH bits but the code seems rather arcane. For instance, when calling unmap (it actually just attempts to get hu(B) and hl(B) flags from 3GPP TS 45.003 §4.3.5 located in bits 58 and 57 correspondingly) potentially stolen bits in the beginning of function, why bursts 0..3 are treated as even and 2..4 as odd? -- Max Suraev &lt;msuraev(a)sysmocom.de&gt; http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte