FreeCalypso > hg > freecalypso-docs
diff TCH-tap-modes @ 106:28c1cb869d91
TCH-tap-modes: updates for TCH/HS
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 22 Jul 2024 22:36:29 +0000 |
parents | 8a45cd92e3c3 |
children | dfa5f99631a6 |
line wrap: on
line diff
--- a/TCH-tap-modes Mon Dec 11 19:02:01 2023 +0000 +++ b/TCH-tap-modes Mon Jul 22 22:36:29 2024 +0000 @@ -128,9 +128,10 @@ FreeCalypso invention) has changed in a slight but incompatible way between the original hackish version from 2016 and the new production version as of 2022, and capturing TCH DL with new firmware requires the updated version of fc-shell -that will be released as part of fc-host-tools-r18. The current (late 2022) -incarnation of FreeCalypso TCH DL sniffing feature supports FR1, HR1 and EFR -codecs, although only FR1 and EFR have been tested so far. +that was released as part of fc-host-tools-r18. The current (developed in late +2022) incarnation of FreeCalypso TCH DL sniffing feature supports FR1, HR1 and +EFR codecs; initially only FR1 and EFR were tested, but in 2024 HR1 joined the +tested and known-working set. The function of TCH UL substitution is currently implemented in FC Tourmaline only for FR1 and EFR (no HR1, no AMR), and it likewise requires running an @@ -157,8 +158,9 @@ analysis with the 3 status words that make up the buffer header: Status word 0 (a_dd_0[0] or a_dd_1[0]) is a word of flag bits. We don't know -the meaning of every bit in this word, but at least for TCH/FS and TCH/EFS (we -haven't exercised TCH/HS at all) we know the following bits: +the meaning of every bit in this word, but here are the bit meanings we've been +able to figure out so far, looking at TCH/FS, TCH/EFS and more recently TCH/HS +DL captures: * Bit 15 (B_BLUD) is a "buffer filled" or "data present" flag. This flag is observed as 1 in *almost* every 20 ms window in which a traffic frame is @@ -176,6 +178,9 @@ good; in the case of TCH/FS this bit has always been observed as 1 and should be ignored because there is no CRC-8 in TCH/FS. + (Update for TCH/HS: in this channel mode this bit has always been observed + as 0.) + * Bit 7 has always been observed as 1 wheneven B_BLUD is set but B_AF is cleared, i.e., whenever the block was channel-decoded in FACCH rather than speech mode. @@ -187,6 +192,9 @@ and 06.81, but only when the speech-not-FACCH channel decoder was invoked as indicated by B_AF. + (Update for TCH/HS: these bits apply to HR codec too, following GSM 06.41 + section 6.1.1 now.) + * Bit 2 is BFI as defined in section 6.1.1 of GSM 06.31 and 06.81. Whenever the block was decoded as FACCH (bit 14 clear, bit 7 set), bit 2 has always been observed as set, agreeing with the stipulation in GSM 06.31 and 06.81 @@ -196,6 +204,16 @@ logic is expected to OR bits 2 and 9 together to get the BFI flag for the Rx DTX handler of GSM 06.81. + (Update for TCH/HS: bit 2 is BFI in HR codec too.) + +* Bit 1 is seen only in TCH/HS, and appears to be the elusive BCI flag whose + existence has been figured out from ETSI GSM 06.06 reid.c source. See this + article for more information: + + https://osmocom.org/projects/retro-gsm/wiki/HRv1_error_flags + +* Bit 0 is UFI for TCH/HS only. + In the case of 20 ms blocks (reassembled from 8 half-bursts) that were channel- decoded as speech rather than FACCH, the observed behavior is that bits 15 and 14 are set, the payload portion of the buffer is filled with the output from the