spandsp
0.0.6
|
00001 /* 00002 * SpanDSP - a series of DSP components for telephony 00003 * 00004 * v17rx.h - ITU V.17 modem receive part 00005 * 00006 * Written by Steve Underwood <steveu@coppice.org> 00007 * 00008 * Copyright (C) 2003 Steve Underwood 00009 * 00010 * All rights reserved. 00011 * 00012 * This program is free software; you can redistribute it and/or modify 00013 * it under the terms of the GNU Lesser General Public License version 2.1, 00014 * as published by the Free Software Foundation. 00015 * 00016 * This program is distributed in the hope that it will be useful, 00017 * but WITHOUT ANY WARRANTY; without even the implied warranty of 00018 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 00019 * GNU Lesser General Public License for more details. 00020 * 00021 * You should have received a copy of the GNU Lesser General Public 00022 * License along with this program; if not, write to the Free Software 00023 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. 00024 */ 00025 00026 /*! \file */ 00027 00028 #if !defined(_SPANDSP_V17RX_H_) 00029 #define _SPANDSP_V17RX_H_ 00030 00031 /*! \page v17rx_page The V.17 receiver 00032 \section v17rx_page_sec_1 What does it do? 00033 The V.17 receiver implements the receive side of a V.17 modem. This can operate 00034 at data rates of 14400, 12000, 9600 and 7200 bits/second. The audio input is a stream 00035 of 16 bit samples, at 8000 samples/second. The transmit and receive side of V.17 00036 modems operate independantly. V.17 is mostly used for FAX transmission over PSTN 00037 lines, where it provides the standard 14400 bits/second rate. 00038 00039 \section v17rx_page_sec_2 How does it work? 00040 V.17 uses QAM modulation, at 2400 baud, and trellis coding. Constellations with 00041 16, 32, 64, and 128 points are defined. After one bit per baud is absorbed by the 00042 trellis coding, this gives usable bit rates of 7200, 9600, 12000, and 14400 per 00043 second. 00044 00045 V.17 specifies a training sequence at the start of transmission, which makes the 00046 design of a V.17 receiver relatively straightforward. The first stage of the 00047 training sequence consists of 256 00048 symbols, alternating between two constellation positions. The receiver monitors 00049 the signal power, to sense the possible presence of a valid carrier. When the 00050 alternating signal begins, the power rising above a minimum threshold (-43dBm0) 00051 causes the main receiver computation to begin. The initial measured power is 00052 used to quickly set the gain of the receiver. After this initial settling, the 00053 front end gain is locked, and the adaptive equalizer tracks any subsequent 00054 signal level variation. The signal is oversampled to 24000 samples/second (i.e. 00055 signal, zero, zero, signal, zero, zero, ...) and fed to a complex root raised 00056 cosine pulse shaping filter. This filter has been modified from the conventional 00057 root raised cosine filter, by shifting it up the band, to be centred at the nominal 00058 carrier frequency. This filter interpolates the samples, pulse shapes, and performs 00059 a fractional sample delay at the same time. 192 sets of filter coefficients are used 00060 to achieve a set of finely spaces fractional sample delays, between zero and 00061 one sample. By choosing every fifth sample, and the appropriate set of filter 00062 coefficients, the properly tuned symbol tracker can select data samples at 4800 00063 samples/second from points within 0.28 degrees of the centre and mid-points of 00064 each symbol. The output of the filter is multiplied by a complex carrier, generated 00065 by a DDS. The result is a baseband signal, requiring no further filtering, apart from 00066 an adaptive equalizer. The baseband signal is fed to a T/2 adaptive equalizer. 00067 A band edge component maximisation algorithm is used to tune the sampling, so the samples 00068 fed to the equalizer are close to the mid point and edges of each symbol. Initially 00069 the algorithm is very lightly damped, to ensure the symbol alignment pulls in 00070 quickly. Because the sampling rate will not be precisely the same as the 00071 transmitter's (the spec. says the symbol timing should be within 0.01%), the 00072 receiver constantly evaluates and corrects this sampling throughout its 00073 operation. During the symbol timing maintainence phase, the algorithm uses 00074 a heavier damping. 00075 00076 The carrier is specified as 1800Hz +- 1Hz at the transmitter, and 1800 +-7Hz at 00077 the receiver. The receive carrier would only be this inaccurate if the link 00078 includes FDM sections. These are being phased out, but the design must still 00079 allow for the worst case. Using an initial 1800Hz signal for demodulation gives 00080 a worst case rotation rate for the constellation of about one degree per symbol. 00081 Once the symbol timing synchronisation algorithm has been given time to lock to the 00082 symbol timing of the initial alternating pattern, the phase of the demodulated signal 00083 is recorded on two successive symbols - once for each of the constellation positions. 00084 The receiver then tracks the symbol alternations, until a large phase jump occurs. 00085 This signifies the start of the next phase of the training sequence. At this 00086 point the total phase shift between the original recorded symbol phase, and the 00087 symbol phase just before the phase jump occurred is used to provide a coarse 00088 estimation of the rotation rate of the constellation, and it current absolute 00089 angle of rotation. These are used to update the current carrier phase and phase 00090 update rate in the carrier DDS. The working data already in the pulse shaping 00091 filter and equalizer buffers is given a similar step rotation to pull it all 00092 into line. From this point on, a heavily damped integrate and dump approach, 00093 based on the angular difference between each received constellation position and 00094 its expected position, is sufficient to track the carrier, and maintain phase 00095 alignment. A fast rough approximator for the arc-tangent function is adequate 00096 for the estimation of the angular error. 00097 00098 The next phase of the training sequence is a scrambled sequence of two 00099 particular symbols. We train the T/2 adaptive equalizer using this sequence. The 00100 scrambling makes the signal sufficiently diverse to ensure the equalizer 00101 converges to the proper generalised solution. At the end of this sequence, the 00102 equalizer should be sufficiently well adapted that is can correctly resolve the 00103 full QAM constellation. However, the equalizer continues to adapt throughout 00104 operation of the modem, fine tuning on the more complex data patterns of the 00105 full QAM constellation. 00106 00107 In the last phase of the training sequence, the modem enters normal data 00108 operation, with a short defined period of all ones as data. As in most high 00109 speed modems, data in a V.17 modem passes through a scrambler, to whiten the 00110 spectrum of the signal. The transmitter should initialise its data scrambler, 00111 and pass the ones through it. At the end of the ones, real data begins to pass 00112 through the scrambler, and the transmit modem is in normal operation. The 00113 receiver tests that ones are really received, in order to verify the modem 00114 trained correctly. If all is well, the data following the ones is fed to the 00115 application, and the receive modem is up and running. Unfortunately, some 00116 transmit side of some real V.17 modems fail to initialise their scrambler before 00117 sending the ones. This means the first 23 received bits (the length of the 00118 scrambler register) cannot be trusted for the test. The receive modem, 00119 therefore, only tests that bits starting at bit 24 are really ones. 00120 00121 The V.17 signal is trellis coded. Two bits of each symbol are convolutionally coded 00122 to form a 3 bit trellis code - the two original bits, plus an extra redundant bit. It 00123 is possible to ignore the trellis coding, and just decode the non-redundant bits. 00124 However, the noise performance of the receiver would suffer. Using a proper 00125 trellis decoder adds several dB to the noise tolerance to the receiving modem. Trellis 00126 coding seems quite complex at first sight, but is fairly straightforward once you 00127 get to grips with it. 00128 00129 Trellis decoding tracks the data in terms of the possible states of the convolutional 00130 coder at the transmitter. There are 8 possible states of the V.17 coder. The first 00131 step in trellis decoding is to find the best candidate constellation point 00132 for each of these 8 states. One of thse will be our final answer. The constellation 00133 has been designed so groups of 8 are spread fairly evenly across it. Locating them 00134 is achieved is a reasonably fast manner, by looking up the answers in a set of space 00135 map tables. The disadvantage is the tables are potentially large enough to affect 00136 cache performance. The trellis decoder works over 16 successive symbols. The result 00137 of decoding is not known until 16 symbols after the data enters the decoder. The 00138 minimum total accumulated mismatch between each received point and the actual 00139 constellation (termed the distance) is assessed for each of the 8 states. A little 00140 analysis of the coder shows that each of the 8 current states could be arrived at 00141 from 4 different previous states, through 4 different constellation bit patterns. 00142 For each new state, the running total distance is arrived at by inspecting a previous 00143 total plus a new distance for the appropriate 4 previous states. The minimum of the 4 00144 values becomes the new distance for the state. Clearly, a mechanism is needed to stop 00145 this distance from growing indefinitely. A sliding window, and several other schemes 00146 are possible. However, a simple single pole IIR is very simple, and provides adequate 00147 results. 00148 00149 For each new state we store the constellation bit pattern, or path, to that state, and 00150 the number of the previous state. We find the minimum distance amongst the 8 new 00151 states for each new symbol. We then trace back through the states, until we reach the 00152 one 16 states ago which leads to the current minimum distance. The bit pattern stored 00153 there is the error corrected bit pattern for that symbol. 00154 00155 So, what does Trellis coding actually achieve? TCM is easier to understand by looking 00156 at the V.23bis modem spec. The V.32bis spec. is very similar to V.17, except that it 00157 is a full duplex modem and has non-TCM options, as well as the TCM ones in V.17. 00158 00159 V32bis defines two options for pumping 9600 bits per second down a phone line - one 00160 with and one without TCM. Both run at 2400 baud. The non-TCM one uses simple 16 point 00161 QAM on the raw data. The other takes two out of every four raw bits, and convolutionally 00162 encodes them to 3. Now we have 5 bits per symbol, and we need 32 point QAM to send the 00163 data. 00164 00165 The raw error rate from simple decoding of the 32 point QAM is horrible compared to 00166 decoding the 16 point QAM. If a point decoded from the 32 point QAM is wrong, the likely 00167 correct choice should be one of the adjacent ones. It is unlikely to have been one that 00168 is far away across the constellation, unless there was a huge noise spike, interference, 00169 or something equally nasty. Now, the 32 point symbols do not exist in isolation. There 00170 was a kind of temporal smearing in the convolutional coding. It created a well defined 00171 dependency between successive symbols. If we knew for sure what the last few symbols 00172 were, they would lead us to a limited group of possible values for the current symbol, 00173 constrained by the behaviour of the convolutional coder. If you look at how the symbols 00174 were mapped to constellation points, you will see the mapping tries to spread those 00175 possible symbols as far apart as possible. This will leave only one that is pretty 00176 close to the received point, which must be the correct choice. However, this assumes 00177 we know the last few symbols for sure. Since we don't, we have a bit more work to do 00178 to achieve reliable decoding. 00179 00180 Instead of decoding to the nearest point on the constellation, we decode to a group of 00181 likely constellation points in the neighbourhood of the received point. We record the 00182 mismatch for each - that is the distance across the constellation between the received 00183 point and the group of nearby points. To avoid square roots, recording x2 + y2 can be 00184 good enough. Symbol by symbol, we record this information. After a few symbols we can 00185 stand back and look at the recorded information. 00186 00187 For each symbol we have a set of possible symbol values and error metric pairs. The 00188 dependency between symbols, created by the convolutional coder, means some paths from 00189 symbol to symbol are possible and some are not. It we trace back through the possible 00190 symbol to symbol paths, and total up the error metric through those paths, we end up 00191 with a set of figures of merit (or more accurately figures of demerit, since 00192 larger == worse) for the likelihood of each path being the correct one. The path with 00193 the lowest total metric is the most likely, and gives us our final choice for what we 00194 think the current symbol really is. 00195 00196 That was hard work. It takes considerable computation to do this selection and traceback, 00197 symbol by symbol. We need to get quite a lot from this. It needs to drive the error rate 00198 down so far that is compensates for the much higher error rate due to the larger 00199 constellation, and then buys us some actual benefit. Well in the example we are looking 00200 at - V.32bis at 9600bps - it works out the error rate from the TCM option is like using 00201 the non-TCM option with several dB more signal to noise ratio. That's nice. The non-TCM 00202 option is pretty reasonable on most phone lines, but a better error rate is always a 00203 good thing. However, V32bis includes a 14,400bps option. That uses 2400 baud, and 6 bit 00204 symbols. Convolutional encoding increases that to 7 bits per symbol, by taking 2 bits and 00205 encoding them to 3. This give a 128 point QAM constellation. Again, the difference between 00206 using this, and using just an uncoded 64 point constellation is equivalent to maybe 5dB of 00207 extra signal to noise ratio. However, in this case it is the difference between the modem 00208 working only on the most optimal lines, and being widely usable across most phone lines. 00209 TCM absolutely transformed the phone line modem business. 00210 */ 00211 00212 /*! 00213 V.17 modem receive side descriptor. This defines the working state for a 00214 single instance of a V.17 modem receiver. 00215 */ 00216 typedef struct v17_rx_state_s v17_rx_state_t; 00217 00218 #if defined(__cplusplus) 00219 extern "C" 00220 { 00221 #endif 00222 00223 /*! Initialise a V.17 modem receive context. 00224 \brief Initialise a V.17 modem receive context. 00225 \param s The modem context. 00226 \param bit_rate The bit rate of the modem. Valid values are 7200, 9600, 12000 and 14400. 00227 \param put_bit The callback routine used to put the received data. 00228 \param user_data An opaque pointer passed to the put_bit routine. 00229 \return A pointer to the modem context, or NULL if there was a problem. */ 00230 SPAN_DECLARE(v17_rx_state_t *) v17_rx_init(v17_rx_state_t *s, int bit_rate, put_bit_func_t put_bit, void *user_data); 00231 00232 /*! Reinitialise an existing V.17 modem receive context. 00233 \brief Reinitialise an existing V.17 modem receive context. 00234 \param s The modem context. 00235 \param bit_rate The bit rate of the modem. Valid values are 7200, 9600, 12000 and 14400. 00236 \param short_train TRUE if a short training sequence is expected. 00237 \return 0 for OK, -1 for bad parameter */ 00238 SPAN_DECLARE(int) v17_rx_restart(v17_rx_state_t *s, int bit_rate, int short_train); 00239 00240 /*! Release a V.17 modem receive context. 00241 \brief Release a V.17 modem receive context. 00242 \param s The modem context. 00243 \return 0 for OK */ 00244 SPAN_DECLARE(int) v17_rx_release(v17_rx_state_t *s); 00245 00246 /*! Free a V.17 modem receive context. 00247 \brief Free a V.17 modem receive context. 00248 \param s The modem context. 00249 \return 0 for OK */ 00250 SPAN_DECLARE(int) v17_rx_free(v17_rx_state_t *s); 00251 00252 /*! Get the logging context associated with a V.17 modem receive context. 00253 \brief Get the logging context associated with a V.17 modem receive context. 00254 \param s The modem context. 00255 \return A pointer to the logging context */ 00256 SPAN_DECLARE(logging_state_t *) v17_rx_get_logging_state(v17_rx_state_t *s); 00257 00258 /*! Change the put_bit function associated with a V.17 modem receive context. 00259 \brief Change the put_bit function associated with a V.17 modem receive context. 00260 \param s The modem context. 00261 \param put_bit The callback routine used to handle received bits. 00262 \param user_data An opaque pointer. */ 00263 SPAN_DECLARE(void) v17_rx_set_put_bit(v17_rx_state_t *s, put_bit_func_t put_bit, void *user_data); 00264 00265 /*! Change the modem status report function associated with a V.17 modem receive context. 00266 \brief Change the modem status report function associated with a V.17 modem receive context. 00267 \param s The modem context. 00268 \param handler The callback routine used to report modem status changes. 00269 \param user_data An opaque pointer. */ 00270 SPAN_DECLARE(void) v17_rx_set_modem_status_handler(v17_rx_state_t *s, modem_rx_status_func_t handler, void *user_data); 00271 00272 /*! Process a block of received V.17 modem audio samples. 00273 \brief Process a block of received V.17 modem audio samples. 00274 \param s The modem context. 00275 \param amp The audio sample buffer. 00276 \param len The number of samples in the buffer. 00277 \return The number of samples unprocessed. 00278 */ 00279 SPAN_DECLARE_NONSTD(int) v17_rx(v17_rx_state_t *s, const int16_t amp[], int len); 00280 00281 /*! Fake processing of a missing block of received V.17 modem audio samples. 00282 (e.g due to packet loss). 00283 \brief Fake processing of a missing block of received V.17 modem audio samples. 00284 \param s The modem context. 00285 \param len The number of samples to fake. 00286 \return The number of samples unprocessed. 00287 */ 00288 SPAN_DECLARE_NONSTD(int) v17_rx_fillin(v17_rx_state_t *s, int len); 00289 00290 /*! Get a snapshot of the current equalizer coefficients. 00291 \brief Get a snapshot of the current equalizer coefficients. 00292 \param s The modem context. 00293 \param coeffs The vector of complex coefficients. 00294 \return The number of coefficients in the vector. */ 00295 #if defined(SPANDSP_USE_FIXED_POINTx) 00296 SPAN_DECLARE(int) v17_rx_equalizer_state(v17_rx_state_t *s, complexi_t **coeffs); 00297 #else 00298 SPAN_DECLARE(int) v17_rx_equalizer_state(v17_rx_state_t *s, complexf_t **coeffs); 00299 #endif 00300 00301 /*! Get the current received carrier frequency. 00302 \param s The modem context. 00303 \return The frequency, in Hertz. */ 00304 SPAN_DECLARE(float) v17_rx_carrier_frequency(v17_rx_state_t *s); 00305 00306 /*! Get the current symbol timing correction since startup. 00307 \param s The modem context. 00308 \return The correction. */ 00309 SPAN_DECLARE(float) v17_rx_symbol_timing_correction(v17_rx_state_t *s); 00310 00311 /*! Get a current received signal power. 00312 \param s The modem context. 00313 \return The signal power, in dBm0. */ 00314 SPAN_DECLARE(float) v17_rx_signal_power(v17_rx_state_t *s); 00315 00316 /*! Set the power level at which the carrier detection will cut in 00317 \param s The modem context. 00318 \param cutoff The signal cutoff power, in dBm0. */ 00319 SPAN_DECLARE(void) v17_rx_signal_cutoff(v17_rx_state_t *s, float cutoff); 00320 00321 /*! Set a handler routine to process QAM status reports 00322 \param s The modem context. 00323 \param handler The handler routine. 00324 \param user_data An opaque pointer passed to the handler routine. */ 00325 SPAN_DECLARE(void) v17_rx_set_qam_report_handler(v17_rx_state_t *s, qam_report_handler_t handler, void *user_data); 00326 00327 #if defined(__cplusplus) 00328 } 00329 #endif 00330 00331 #endif 00332 /*- End of file ------------------------------------------------------------*/