FreeCalypso > hg > freecalypso-sw

comparison doc/TCH-special-feature @ 1033:5ab737ac3ad7

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
TCH special feature documentation update
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 01 Jun 2016 02:06:44 +0000
parents 759b3cbf46aa
children
comparison
equal deleted inserted replaced
1032:6e7dd5e52650 1033:5ab737ac3ad7
77 The 40 bytes of payload sent in every TCH_DLBITS_IND packet directly correspond 77 The 40 bytes of payload sent in every TCH_DLBITS_IND packet directly correspond
78 to the 20 16-bit words provided by the Calypso DSP in its a_dd_0 buffer. The 78 to the 20 16-bit words provided by the Calypso DSP in its a_dd_0 buffer. The
79 first 3 words (6 bytes) contains the DSP's own status information (not fully 79 first 3 words (6 bytes) contains the DSP's own status information (not fully
80 understood by us yet, but we let you see what the DSP tells us without redacting 80 understood by us yet, but we let you see what the DSP tells us without redacting
81 anything out), and the remaining 17 words (34 bytes) are supposed to contain 81 anything out), and the remaining 17 words (34 bytes) are supposed to contain
82 the TCH bits received from the GSM network in the FR codec format. 82 the TCH bits received from the GSM network in the FR codec format. Each DSP
83 API word is sent in the big-endian byte order, i.e., the most significant byte
84 followed by the least significant byte.
83 85
84 If you wish to send your own TCH uplink bits, replacing the output of the 86 If you wish to send your own TCH uplink bits, replacing the output of the
85 built-in vocoder with your own alternate uplink data, you will need to send 87 built-in vocoder with your own alternate uplink data, you will need to send
86 your uplink TCH bits to the modem in packets of the following format: 88 your uplink TCH bits to the modem in packets of the following format:
87 89
90 0x13: TCH_ULBITS_REQ opcode 92 0x13: TCH_ULBITS_REQ opcode
91 - 33 or 34 (decimal) bytes of payload - 93 - 33 or 34 (decimal) bytes of payload -
92 0x02: closing flag 94 0x02: closing flag
93 95
94 Sending 260 bits requires only 33 bytes, but the DSP operates in terms of 96 Sending 260 bits requires only 33 bytes, but the DSP operates in terms of
95 16-bit words, hence 17 of those words are used. The upper byte of the last 97 16-bit words, hence 17 of those words are used. The least significant byte of
96 word is not expected to be used, but if you send 34 bytes rather than 33, you 98 the last word (i.e., the very last byte with our big-endian transmission order)
97 will have control over every bit going into the DSP API RAM in this case. 99 is not expected to be used, but if you send 34 bytes rather than 33, you will
100 have control over every bit going into the DSP API RAM in this case.
98 101
99 There is a queue inside the firmware in which these TCH uplink data blocks are 102 There is a queue inside the firmware in which these TCH uplink data blocks are
100 stored; this queue is filled by the serial packet receiving handler and drained 103 stored; this queue is filled by the serial packet receiving handler and drained
101 by the L1S (synchronous) code that executes at the right times in the GSM TDMA 104 by the L1S (synchronous) code that executes at the right times in the GSM TDMA
102 multiplex when uplink TCH transmission is expected. Up to 4 blocks can be 105 multiplex when uplink TCH transmission is expected. Up to 4 blocks can be
107 of further TCH_ULBITS_REQs. 110 of further TCH_ULBITS_REQs.
108 111
109 Testing 112 Testing
110 ======= 113 =======
111 114
112 The just-described mechanism has been tested to the following extent: I have 115 The just-described mechanism has been tested as follows:
113 sent TCH_CONFIG_REQ packets to the modem, requesting that TCH downlink 116
114 forwarding be enabled or disabled, and observed that the flow of TCH_DLBITS_IND 117 1. I placed a call to WWV (+1-303-499-7111), and after verifying with my ear
115 packets from the modem to the host starts and stops as expected. I have not 118 that the downlink audio was good, I recorded the downlink TCH bits on that
116 done any further work to verify the correctness of the FR codec payload bits 119 call into a file with the tch record command in fc-shell.
117 within these packets. However, the TCH uplink substitution mechanism has not 120
118 been tested at all, as I do not have a source of FR codec bits for testing. 121 2. I placed a call to another phone (running over a live commercial GSM network)
122 and played the saved recording from WWV into the call uplink with the
123 tch play command in fc-shell.
124
125 3. The audio heard on the other end of the call in the previous step: the
126 recording from WWV was definitely recognizable, but it didn't sound perfect,
127 i.e., it was rather garbled.
128
129 Further debugging of this mechanism will require two things which I currently
130 lack: (1) proper understanding of the workings of the GSM 06.10 FR codec and
131 (2) a test GSM network (as in OpenBTS/OpenBSC/etc) that could be used instead
132 of live commercial ones, so we could see exactly what the test MS is
133 transmitting on the air and what the BTS transmits in the downlink.
119 134
120 Host side reference implementation 135 Host side reference implementation
121 ================================== 136 ==================================
122 137
123 If you are going to implement your system for talking to FreeCalypso GSM pseudo- 138 If you are going to implement your system for talking to FreeCalypso GSM pseudo-
124 modems via the RVTMUX binary packet interface, we strongly recommend that you 139 modems via the RVTMUX binary packet interface, we strongly recommend that you
125 use our rvinterf and fc-shell Unix/Linux host utilities as your starting point. 140 use our rvinterf and fc-shell Unix/Linux host utilities as your starting point.
126 You can find their source code in the rvinterf subtree. 141 You can find their source code in the rvinterf subtree.
142
143 The following test commands have been added to fc-shell for exercising the
144 experimental TCH rerouting mechanism:
145
146 tch record <filename>
147
148 Sends a TCH_CONFIG_REQ packet to the target, commanding the firmware to
149 start forwarding TCH downlink bits to the external host, and starts
150 recording the bits it receives in the named file. The file is written
151 with the same ordering of GSM 06.10 bits as used by the popular libgsm
152 implementation of this codec, i.e., the bits received from the GSM
153 device (ultimately coming from TI's DSP) are reordered before being
154 written into the file. It is only a reordering of bits with no change
155 in the information content.
156
157 I was hoping that the resulting files could be played with the SoX play
158 command under Slackware Linux, but all I got was garbled audio, and my
159 audio-fu is not good enough to figure out what is wrong.
160
161 tch record stop
162
163 Stops TCH downlink recording and closes the file into which the bytes
164 were being written; until the file is thus closed, it may not be
165 actually written out to the file system.
166
167 tch play <filename>
168
169 Plays GSM 06.10 FR speech frames from the named file in libgsm format
170 (same as written by the tch record command) into the call uplink.
171
172 tch play stop
173
174 Terminates the TCH UL play-from-file operation. This command is
175 normally not needed, as the play session will end automatically when
176 the end of file is reached.