Mercurial > hg > audiostuff

comparison spandsp-0.0.3/spandsp-0.0.3/src/spandsp/v17rx.h @ 5:f762bf195c4b

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
import spandsp-0.0.3
author Peter Meerwald <pmeerw@cosy.sbg.ac.at>
date Fri, 25 Jun 2010 16:00:21 +0200
parents
children
comparison
equal deleted inserted replaced
4:26cd8f1ef0b1 5:f762bf195c4b
1 /*
2 * SpanDSP - a series of DSP components for telephony
3 *
4 * v17rx.h - ITU V.17 modem receive part
5 *
6 * Written by Steve Underwood <steveu@coppice.org>
7 *
8 * Copyright (C) 2003 Steve Underwood
9 *
10 * All rights reserved.
11 *
12 * This program is free software; you can redistribute it and/or modify
13 * it under the terms of the GNU General Public License version 2, as
14 * published by the Free Software Foundation.
15 *
16 * This program is distributed in the hope that it will be useful,
17 * but WITHOUT ANY WARRANTY; without even the implied warranty of
18 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
19 * GNU General Public License for more details.
20 *
21 * You should have received a copy of the GNU General Public License
22 * along with this program; if not, write to the Free Software
23 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
24 *
25 * $Id: v17rx.h,v 1.35 2006/10/24 13:45:28 steveu Exp $
26 */
27
28 /*! \file */
29
30 #if !defined(_V17RX_H_)
31 #define _V17RX_H_
32
33 /*! \page v17rx_page The V.17 receiver
34 \section v17rx_page_sec_1 What does it do?
35 The V.17 receiver implements the receive side of a V.17 modem. This can operate
36 at data rates of 14400, 12000, 9600 and 7200 bits/second. The audio input is a stream
37 of 16 bit samples, at 8000 samples/second. The transmit and receive side of V.17
38 modems operate independantly. V.17 is mostly used for FAX transmission over PSTN
39 lines, where it provides the standard 14400 bits/second rate.
40
41 \section v17rx_page_sec_2 How does it work?
42 V.17 uses QAM modulation, at 2400 baud, and trellis coding. Constellations with
43 16, 32, 64, and 128 points are defined. After one bit per baud is absorbed by the
44 trellis coding, this gives usable bit rates of 7200, 9600, 12000, and 14400 per
45 second.
46
47 V.17 specifies a training sequence at the start of transmission, which makes the
48 design of a V.17 receiver relatively straightforward. The first stage of the
49 training sequence consists of 256
50 symbols, alternating between two constellation positions. The receiver monitors
51 the signal power, to sense the possible presence of a valid carrier. When the
52 alternating signal begins, the power rising above a minimum threshold (-43dBm0)
53 causes the main receiver computation to begin. The initial measured power is
54 used to quickly set the gain of the receiver. After this initial settling, the
55 front end gain is locked, and the adaptive equalizer tracks any subsequent
56 signal level variation. The signal is oversampled to 24000 samples/second (i.e.
57 signal, zero, zero, signal, zero, zero, ...) and fed to a complex root raised
58 cosine pulse shaping filter. This filter has been modified from the conventional
59 root raised cosine filter, by shifting it up the band, to be centred at the nominal
60 carrier frequency. This filter interpolates the samples, pulse shapes, and performs
61 a fractional sample delay at the same time. 192 sets of filter coefficients are used
62 to achieve a set of finely spaces fractional sample delays, between zero and
63 one sample. By choosing every fifth sample, and the appropriate set of filter
64 coefficients, the properly tuned symbol tracker can select data samples at 4800
65 samples/second from points within 0.28 degrees of the centre and mid-points of
66 each symbol. The output of the filter is multiplied by a complex carrier, generated
67 by a DDS. The result is a baseband signal, requiring no further filtering, apart from
68 an adaptive equalizer. The baseband signal is fed to a T/2 adaptive equalizer.
69 A band edge component maximisation algorithm is used to tune the sampling, so the samples
70 fed to the equalizer are close to the mid point and edges of each symbol. Initially
71 the algorithm is very lightly damped, to ensure the symbol alignment pulls in
72 quickly. Because the sampling rate will not be precisely the same as the
73 transmitter's (the spec. says the symbol timing should be within 0.01%), the
74 receiver constantly evaluates and corrects this sampling throughout its
75 operation. During the symbol timing maintainence phase, the algorithm uses
76 a heavier damping.
77
78 The carrier is specified as 1800Hz +- 1Hz at the transmitter, and 1800 +-7Hz at
79 the receiver. The receive carrier would only be this inaccurate if the link
80 includes FDM sections. These are being phased out, but the design must still
81 allow for the worst case. Using an initial 1800Hz signal for demodulation gives
82 a worst case rotation rate for the constellation of about one degree per symbol.
83 Once the symbol timing synchronisation algorithm has been given time to lock to the
84 symbol timing of the initial alternating pattern, the phase of the demodulated signal
85 is recorded on two successive symbols - once for each of the constellation positions.
86 The receiver then tracks the symbol alternations, until a large phase jump occurs.
87 This signifies the start of the next phase of the training sequence. At this
88 point the total phase shift between the original recorded symbol phase, and the
89 symbol phase just before the phase jump occurred is used to provide a coarse
90 estimation of the rotation rate of the constellation, and it current absolute
91 angle of rotation. These are used to update the current carrier phase and phase
92 update rate in the carrier DDS. The working data already in the pulse shaping
93 filter and equalizer buffers is given a similar step rotation to pull it all
94 into line. From this point on, a heavily damped integrate and dump approach,
95 based on the angular difference between each received constellation position and
96 its expected position, is sufficient to track the carrier, and maintain phase
97 alignment. A fast rough approximator for the arc-tangent function is adequate
98 for the estimation of the angular error.
99
100 The next phase of the training sequence is a scrambled sequence of two
101 particular symbols. We train the T/2 adaptive equalizer using this sequence. The
102 scrambling makes the signal sufficiently diverse to ensure the equalizer
103 converges to the proper generalised solution. At the end of this sequence, the
104 equalizer should be sufficiently well adapted that is can correctly resolve the
105 full QAM constellation. However, the equalizer continues to adapt throughout
106 operation of the modem, fine tuning on the more complex data patterns of the
107 full QAM constellation.
108
109 In the last phase of the training sequence, the modem enters normal data
110 operation, with a short defined period of all ones as data. As in most high
111 speed modems, data in a V.17 modem passes through a scrambler, to whiten the
112 spectrum of the signal. The transmitter should initialise its data scrambler,
113 and pass the ones through it. At the end of the ones, real data begins to pass
114 through the scrambler, and the transmit modem is in normal operation. The
115 receiver tests that ones are really received, in order to verify the modem
116 trained correctly. If all is well, the data following the ones is fed to the
117 application, and the receive modem is up and running. Unfortunately, some
118 transmit side of some real V.17 modems fail to initialise their scrambler before
119 sending the ones. This means the first 23 received bits (the length of the
120 scrambler register) cannot be trusted for the test. The receive modem,
121 therefore, only tests that bits starting at bit 24 are really ones.
122
123 The V.17 signal is trellis coded. Two bits of each symbol are convolutionally coded
124 to form a 3 bit trellis code - the two original bits, plus an extra redundant bit. It
125 is possible to ignore the trellis coding, and just decode the non-redundant bits.
126 However, the noise performance of the receiver would suffer. Using a proper
127 trellis decoder adds several dB to the noise tolerance to the receiving modem. Trellis
128 coding seems quite complex at first sight, but is fairly straightforward once you
129 get to grips with it.
130
131 Trellis decoding tracks the data in terms of the possible states of the convolutional
132 coder at the transmitter. There are 8 possible states of the V.17 coder. The first
133 step in trellis decoding is to find the best candidate constellation point
134 for each of these 8 states. One of thse will be our final answer. The constellation
135 has been designed so groups of 8 are spread fairly evenly across it. Locating them
136 is achieved is a reasonably fast manner, by looking up the answers in a set of space
137 map tables. The disadvantage is the tables are potentially large enough to affect
138 cache performance. The trellis decoder works over 16 successive symbols. The result
139 of decoding is not known until 16 symbols after the data enters the decoder. The
140 minimum total accumulated mismatch between each received point and the actual
141 constellation (termed the distance) is assessed for each of the 8 states. A little
142 analysis of the coder shows that each of the 8 current states could be arrived at
143 from 4 different previous states, through 4 different constellation bit patterns.
144 For each new state, the running total distance is arrived at by inspecting a previous
145 total plus a new distance for the appropriate 4 previous states. The minimum of the 4
146 values becomes the new distance for the state. Clearly, a mechanism is needed to stop
147 this distance from growing indefinitely. A sliding window, and several other schemes
148 are possible. However, a simple single pole IIR is very simple, and provides adequate
149 results.
150
151 For each new state we store the constellation bit pattern, or path, to that state, and
152 the number of the previous state. We find the minimum distance amongst the 8 new
153 states for each new symbol. We then trace back through the states, until we reach the
154 one 16 states ago which leads to the current minimum distance. The bit pattern stored
155 there is the error corrected bit pattern for that symbol.
156
157 So, what does Trellis coding actually achieve? TCM is easier to understand by looking
158 at the V.23bis modem spec. The V.32bis spec. is very similar to V.17, except that it
159 is a full duplex modem and has non-TCM options, as well as the TCM ones in V.17.
160
161 V32bis defines two options for pumping 9600 bits per second down a phone line - one
162 with and one without TCM. Both run at 2400 baud. The non-TCM one uses simple 16 point
163 QAM on the raw data. The other takes two out of every four raw bits, and convolutionally
164 encodes them to 3. Now we have 5 bits per symbol, and we need 32 point QAM to send the
165 data.
166
167 The raw error rate from simple decoding of the 32 point QAM is horrible compared to
168 decoding the 16 point QAM. If a point decoded from the 32 point QAM is wrong, the likely
169 correct choice should be one of the adjacent ones. It is unlikely to have been one that
170 is far away across the constellation, unless there was a huge noise spike, interference,
171 or something equally nasty. Now, the 32 point symbols do not exist in isolation. There
172 was a kind of temporal smearing in the convolutional coding. It created a well defined
173 dependency between successive symbols. If we knew for sure what the last few symbols
174 were, they would lead us to a limited group of possible values for the current symbol,
175 constrained by the behaviour of the convolutional coder. If you look at how the symbols
176 were mapped to constellation points, you will see the mapping tries to spread those
177 possible symbols as far apart as possible. This will leave only one that is pretty
178 close to the received point, which must be the correct choice. However, this assumes
179 we know the last few symbols for sure. Since we don't, we have a bit more work to do
180 to achieve reliable decoding.
181
182 Instead of decoding to the nearest point on the constellation, we decode to a group of
183 likely constellation points in the neighbourhood of the received point. We record the
184 mismatch for each - that is the distance across the constellation between the received
185 point and the group of nearby points. To avoid square roots, recording x2 + y2 can be
186 good enough. Symbol by symbol, we record this information. After a few symbols we can
187 stand back and look at the recorded information.
188
189 For each symbol we have a set of possible symbol values and error metric pairs. The
190 dependency between symbols, created by the convolutional coder, means some paths from
191 symbol to symbol are possible and some are not. It we trace back through the possible
192 symbol to symbol paths, and total up the error metric through those paths, we end up
193 with a set of figures of merit (or more accurately figures of demerit, since
194 larger == worse) for the likelihood of each path being the correct one. The path with
195 the lowest total metric is the most likely, and gives us our final choice for what we
196 think the current symbol really is.
197
198 That was hard work. It takes considerable computation to do this selection and traceback,
199 symbol by symbol. We need to get quite a lot from this. It needs to drive the error rate
200 down so far that is compensates for the much higher error rate due to the larger
201 constellation, and then buys us some actual benefit. Well in the example we are looking
202 at - V.32bis at 9600bps - it works out the error rate from the TCM option is like using
203 the non-TCM option with several dB more signal to noise ratio. That's nice. The non-TCM
204 option is pretty reasonable on most phone lines, but a better error rate is always a
205 good thing. However, V32bis includes a 14,400bps option. That uses 2400 baud, and 6 bit
206 symbols. Convolutional encoding increases that to 7 bits per symbol, by taking 2 bits and
207 encoding them to 3. This give a 128 point QAM constellation. Again, the difference between
208 using this, and using just an uncoded 64 point constellation is equivalent to maybe 5dB of
209 extra signal to noise ratio. However, in this case it is the difference between the modem
210 working only on the most optimal lines, and being widely usable across most phone lines.
211 TCM absolutely transformed the phone line modem business.
212 */
213
214 /* Target length for the equalizer is about 63 taps, to deal with the worst stuff
215 in V.56bis. */
216 #define V17_EQUALIZER_PRE_LEN 7 /* this much before the real event */
217 #define V17_EQUALIZER_POST_LEN 7 /* this much after the real event */
218 #define V17_EQUALIZER_MASK 63 /* one less than a power of 2 >= (V17_EQUALIZER_PRE_LEN + 1 + V17_EQUALIZER_POST_LEN) */
219
220 #define V17_RX_FILTER_STEPS 27
221
222 /* We can store more trellis depth that we look back over, so that we can push out a group
223 of symbols in one go, giving greater processing efficiency, at the expense of a bit more
224 latency through the modem. */
225 /* Right now we don't take advantage of this optimisation. */
226 #define V17_TRELLIS_STORAGE_DEPTH 16
227 #define V17_TRELLIS_LOOKBACK_DEPTH 16
228
229 /*!
230 V.17 modem receive side descriptor. This defines the working state for a
231 single instance of a V.17 modem receiver.
232 */
233 typedef struct
234 {
235 /*! \brief The bit rate of the modem. Valid values are 7200 9600, 12000 and 14400. */
236 int bit_rate;
237 /*! \brief The callback function used to put each bit received. */
238 put_bit_func_t put_bit;
239 /*! \brief A user specified opaque pointer passed to the put_but routine. */
240 void *user_data;
241 /*! \brief A callback function which may be enabled to report every symbol's
242 constellation position. */
243 qam_report_handler_t *qam_report;
244 /*! \brief A user specified opaque pointer passed to the qam_report callback
245 routine. */
246 void *qam_user_data;
247
248 /*! \brief The route raised cosine (RRC) pulse shaping filter buffer. */
249 float rrc_filter[2*V17_RX_FILTER_STEPS];
250 /*! \brief Current offset into the RRC pulse shaping filter buffer. */
251 int rrc_filter_step;
252
253 /*! \brief The state of the differential decoder */
254 int diff;
255 /*! \brief The register for the data scrambler. */
256 unsigned int scramble_reg;
257 /*! \brief TRUE if the short training sequence is to be used. */
258 int short_train;
259 int in_training;
260 int training_count;
261 float training_error;
262 int carrier_present;
263 int16_t last_sample;
264
265 /*! \brief The current phase of the carrier (i.e. the DDS parameter). */
266 uint32_t carrier_phase;
267 /*! \brief The update rate for the phase of the carrier (i.e. the DDS increment). */
268 int32_t carrier_phase_rate;
269 /*! \brief The carrier update rate saved for reuse when using short training. */
270 int32_t carrier_phase_rate_save;
271 float carrier_track_p;
272 float carrier_track_i;
273
274 /*! \brief The received signal power monitor. */
275 power_meter_t power;
276 int32_t carrier_on_power;
277 int32_t carrier_off_power;
278 float agc_scaling;
279 float agc_scaling_save;
280
281 float eq_delta;
282 /*! \brief The adaptive equalizer coefficients */
283 complexf_t eq_coeff[V17_EQUALIZER_PRE_LEN + 1 + V17_EQUALIZER_POST_LEN];
284 complexf_t eq_coeff_save[V17_EQUALIZER_PRE_LEN + 1 + V17_EQUALIZER_POST_LEN];
285 complexf_t eq_buf[V17_EQUALIZER_MASK + 1];
286 /*! \brief Current offset into equalizer buffer. */
287 int eq_step;
288 int eq_put_step;
289
290 /*! \brief The current half of the baud. */
291 int baud_half;
292 /*! \brief Band edge symbol sync. filter state. */
293 float symbol_sync_low[2];
294 float symbol_sync_high[2];
295 float symbol_sync_dc_filter[2];
296 float baud_phase;
297 /*! \brief The total symbol timing correction since the carrier came up.
298 This is only for performance analysis purposes. */
299 int total_baud_timing_correction;
300
301 /*! \brief Starting phase angles for the coarse carrier aquisition step. */
302 int32_t start_angles[2];
303 /*! \brief History list of phase angles for the coarse carrier aquisition step. */
304 int32_t angles[16];
305 /*! \brief A pointer to the current constellation. */
306 const complexf_t *constellation;
307 /*! \brief A pointer to the current space map. There is a space map for
308 each trellis state. */
309 int space_map;
310 /*! \brief The number of bits in each symbol at the current bit rate. */
311 int bits_per_symbol;
312
313 /*! \brief Current pointer to the trellis buffers */
314 int trellis_ptr;
315 /*! \brief The trellis. */
316 int full_path_to_past_state_locations[V17_TRELLIS_STORAGE_DEPTH][8];
317 /*! \brief The trellis. */
318 int past_state_locations[V17_TRELLIS_STORAGE_DEPTH][8];
319 /*! \brief Euclidean distances (actually the sqaures of the distances)
320 from the last states of the trellis. */
321 float distances[8];
322 /*! \brief Error and flow logging control */
323 logging_state_t logging;
324 } v17_rx_state_t;
325
326 extern const complexf_t v17_14400_constellation[128];
327 extern const complexf_t v17_12000_constellation[64];
328 extern const complexf_t v17_9600_constellation[32];
329 extern const complexf_t v17_7200_constellation[16];
330
331 #ifdef __cplusplus
332 extern "C" {
333 #endif
334
335 /*! Initialise a V.17 modem receive context.
336 \brief Initialise a V.17 modem receive context.
337 \param s The modem context.
338 \param rate The bit rate of the modem. Valid values are 7200, 9600, 12000 and 14400.
339 \param put_bit The callback routine used to put the received data.
340 \param user_data An opaque pointer passed to the put_bit routine.
341 \return A pointer to the modem context, or NULL if there was a problem. */
342 v17_rx_state_t *v17_rx_init(v17_rx_state_t *s, int rate, put_bit_func_t put_bit, void *user_data);
343
344 /*! Reinitialise an existing V.17 modem receive context.
345 \brief Reinitialise an existing V.17 modem receive context.
346 \param s The modem context.
347 \param rate The bit rate of the modem. Valid values are 7200, 9600, 12000 and 14400.
348 \param short_train TRUE if a short training sequence is expected.
349 \return 0 for OK, -1 for bad parameter */
350 int v17_rx_restart(v17_rx_state_t *s, int rate, int short_train);
351
352 /*! Release a V.17 modem receive context.
353 \brief Release a V.17 modem receive context.
354 \param s The modem context.
355 \return 0 for OK */
356 int v17_rx_release(v17_rx_state_t *s);
357
358 /*! Change the put_bit function associated with a V.17 modem receive context.
359 \brief Change the put_bit function associated with a V.17 modem receive context.
360 \param s The modem context.
361 \param put_bit The callback routine used to handle received bits.
362 \param user_data An opaque pointer. */
363 void v17_rx_set_put_bit(v17_rx_state_t *s, put_bit_func_t put_bit, void *user_data);
364
365 /*! Process a block of received V.17 modem audio samples.
366 \brief Process a block of received V.17 modem audio samples.
367 \param s The modem context.
368 \param amp The audio sample buffer.
369 \param len The number of samples in the buffer.
370 */
371 void v17_rx(v17_rx_state_t *s, const int16_t amp[], int len);
372
373 /*! Get a snapshot of the current equalizer coefficients.
374 \brief Get a snapshot of the current equalizer coefficients.
375 \param s The modem context.
376 \param coeffs The vector of complex coefficients.
377 \return The number of coefficients in the vector. */
378 int v17_rx_equalizer_state(v17_rx_state_t *s, complexf_t **coeffs);
379
380 /*! Get the current received carrier frequency.
381 \param s The modem context.
382 \return The frequency, in Hertz. */
383 float v17_rx_carrier_frequency(v17_rx_state_t *s);
384
385 /*! Get the current symbol timing correction since startup.
386 \param s The modem context.
387 \return The correction. */
388 float v17_rx_symbol_timing_correction(v17_rx_state_t *s);
389
390 /*! Get a current received signal power.
391 \param s The modem context.
392 \return The signal power, in dBm0. */
393 float v17_rx_signal_power(v17_rx_state_t *s);
394
395 /*! Set the power level at which the carrier detection will cut in
396 \param s The modem context.
397 \param cutoff The signal cutoff power, in dBm0. */
398 void v17_rx_signal_cutoff(v17_rx_state_t *s, float cutoff);
399
400 /*! Set a handler routine to process QAM status reports
401 \param s The modem context.
402 \param handler The handler routine.
403 \param user_data An opaque pointer passed to the handler routine. */
404 void v17_rx_set_qam_report_handler(v17_rx_state_t *s, qam_report_handler_t *handler, void *user_data);
405
406 #ifdef __cplusplus
407 }
408 #endif
409
410 #endif
411 /*- End of file ------------------------------------------------------------*/

Repositories maintained by Peter Meerwald, pmeerw@pmeerw.net.