FreeCalypso > hg > freecalypso-citrine

comparison doc/TCH-special-feature @ 36:3362a76ab432

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/TCH-special-feature: outdated info removed, added referral to the TCH-bit-access write-up in the freecalypso-tools tree
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 15 Oct 2016 06:03:45 +0000
parents cb00b90edaff
children
comparison
equal deleted inserted replaced
35:23dbd942aa56 36:3362a76ab432
2 explicitly enabled at compile time) which we call TCH rerouting. When this 2 explicitly enabled at compile time) which we call TCH rerouting. When this
3 feature is enabled, it applies the following special handling to GSM voice 3 feature is enabled, it applies the following special handling to GSM voice
4 traffic channels (TCH): 4 traffic channels (TCH):
5 5
6 * All downlink TCH bits passing from the channel decoder to the vocoder block 6 * All downlink TCH bits passing from the channel decoder to the vocoder block
7 (260 bits every 20 ms with the original FR codec) can be non-invasively 7 (260 bits every 20 ms; only FR and EFR codecs are supported) can be non-
8 intercepted and forwarded to the external host connected to the RVTMUX serial 8 invasively intercepted and forwarded to the external host connected to the
9 interface; 9 RVTMUX serial interface;
10 10
11 * Using the same serial interface, the external host can supply substitute 11 * Using the same serial interface, the external host can supply substitute
12 uplink TCH bits which will be transmitted in the place of the built-in 12 uplink TCH bits which will be transmitted in the place of the built-in
13 vocoder output, i.e., the latter can be effectively suppressed. 13 vocoder output, i.e., the latter can be effectively suppressed.
14 14
76 - 40 (decimal) bytes of payload - 76 - 40 (decimal) bytes of payload -
77 0x02: closing flag 77 0x02: closing flag
78 78
79 The 40 bytes of payload sent in every TCH_DLBITS_IND packet directly correspond 79 The 40 bytes of payload sent in every TCH_DLBITS_IND packet directly correspond
80 to the 20 16-bit words provided by the Calypso DSP in its a_dd_0 buffer. The 80 to the 20 16-bit words provided by the Calypso DSP in its a_dd_0 buffer. The
81 first 3 words (6 bytes) contains the DSP's own status information (not fully 81 first 3 words (6 bytes) contain the DSP's own status information (not fully
82 understood by us yet, but we let you see what the DSP tells us without redacting 82 understood by us yet, but we let you see what the DSP tells us without redacting
83 anything out), and the remaining 17 words (34 bytes) are supposed to contain 83 anything out), and the remaining 17 words (34 bytes) contain the TCH bits
84 the TCH bits received from the GSM network in the FR codec format. Each DSP 84 received from the GSM network in the GSM 05.03 bit order - see TCH-bit-access
85 write-up in the FreeCalypso host tools package for more information. Each DSP
85 API word is sent in the big-endian byte order, i.e., the most significant byte 86 API word is sent in the big-endian byte order, i.e., the most significant byte
86 followed by the least significant byte. 87 followed by the least significant byte.
87 88
88 If you wish to send your own TCH uplink bits, replacing the output of the 89 If you wish to send your own TCH uplink bits, replacing the output of the
89 built-in vocoder with your own alternate uplink data, you will need to send 90 built-in vocoder with your own alternate uplink data, you will need to send
112 of further TCH_ULBITS_REQs. 113 of further TCH_ULBITS_REQs.
113 114
114 Testing 115 Testing
115 ======= 116 =======
116 117
117 The just-described mechanism has been tested as follows: 118 See TCH-bit-access write-up in the freecalypso-tools Hg repository.
118
119 1. I placed a call to WWV (+1-303-499-7111), and after verifying with my ear
120 that the downlink audio was good, I recorded the downlink TCH bits on that
121 call into a file with the tch record command in fc-shell.
122
123 2. I placed a call to another phone (running over a live commercial GSM network)
124 and played the saved recording from WWV into the call uplink with the
125 tch play command in fc-shell.
126
127 3. The audio heard on the other end of the call in the previous step: the
128 recording from WWV was definitely recognizable, but it didn't sound perfect,
129 i.e., it was rather garbled.
130
131 [NOTE: the experiment described above was performed with an older version of
132 the firmware which is now codenamed Citrine, namely, the version with L1-2014.
133 I have not played with the TCH rerouting feature again since the transition to
134 L1-2016.]
135
136 Further debugging of this mechanism will require two things which I currently
137 lack: (1) proper understanding of the workings of the GSM 06.10 FR codec and
138 (2) a test GSM network (as in OpenBTS/OpenBSC/etc) that could be used instead
139 of live commercial ones, so we could see exactly what the test MS is
140 transmitting on the air and what the BTS transmits in the downlink.
141 119
142 Host side reference implementation 120 Host side reference implementation
143 ================================== 121 ==================================
144 122
145 If you are going to implement your own system for talking to FreeCalypso GSM 123 If you are going to implement your own system for talking to FreeCalypso GSM
146 pseudo-modems via the RVTMUX binary packet interface, we strongly recommend 124 pseudo-modems via the RVTMUX binary packet interface, we strongly recommend
147 that you use our rvinterf and fc-shell Unix/Linux host utilities as your 125 that you use our rvinterf and fc-shell Unix/Linux host utilities as your
148 starting point. You can find their source code in the freecalypso-tools Hg 126 starting point. You can find their source code in the freecalypso-tools Hg
149 repository on Bitbucket. 127 repository on Bitbucket.
150
151 The following test commands have been added to fc-shell for exercising the
152 experimental TCH rerouting mechanism:
153
154 tch record <filename>
155
156 Sends a TCH_CONFIG_REQ packet to the target, commanding the firmware to
157 start forwarding TCH downlink bits to the external host, and starts
158 recording the bits it receives in the named file. The file is written
159 with the same ordering of GSM 06.10 bits as used by the popular libgsm
160 implementation of this codec, i.e., the bits received from the GSM
161 device (ultimately coming from TI's DSP) are reordered before being
162 written into the file. It is only a reordering of bits with no change
163 in the information content.
164
165 I was hoping that the resulting files could be played with the SoX play
166 command under Slackware Linux, but all I got was garbled audio, and my
167 audio-fu is not good enough to figure out what is wrong.
168
169 tch record stop
170
171 Stops TCH downlink recording and closes the file into which the bytes
172 were being written; until the file is thus closed, it may not be
173 actually written out to the file system.
174
175 tch play <filename>
176
177 Plays GSM 06.10 FR speech frames from the named file in libgsm format
178 (same as written by the tch record command) into the call uplink.
179
180 tch play stop
181
182 Terminates the TCH UL play-from-file operation. This command is
183 normally not needed, as the play session will end automatically when
184 the end of file is reached.