spandsp 0.0.6
v17rx.h
Go to the documentation of this file.
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 Lesser General Public License version 2.1,
14 * as 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 Lesser General Public License for more details.
20 *
21 * You should have received a copy of the GNU Lesser General Public
22 * License along with this program; if not, write to the Free Software
23 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
24 */
25
26/*! \file */
27
28#if !defined(_SPANDSP_V17RX_H_)
29#define _SPANDSP_V17RX_H_
30
31/*! \page v17rx_page The V.17 receiver
32\section v17rx_page_sec_1 What does it do?
33The V.17 receiver implements the receive side of a V.17 modem. This can operate
34at data rates of 14400, 12000, 9600 and 7200 bits/second. The audio input is a stream
35of 16 bit samples, at 8000 samples/second. The transmit and receive side of V.17
36modems operate independantly. V.17 is mostly used for FAX transmission over PSTN
37lines, where it provides the standard 14400 bits/second rate.
38
39\section v17rx_page_sec_2 How does it work?
40V.17 uses QAM modulation, at 2400 baud, and trellis coding. Constellations with
4116, 32, 64, and 128 points are defined. After one bit per baud is absorbed by the
42trellis coding, this gives usable bit rates of 7200, 9600, 12000, and 14400 per
43second.
44
45V.17 specifies a training sequence at the start of transmission, which makes the
46design of a V.17 receiver relatively straightforward. The first stage of the
47training sequence consists of 256
48symbols, alternating between two constellation positions. The receiver monitors
49the signal power, to sense the possible presence of a valid carrier. When the
50alternating signal begins, the power rising above a minimum threshold (-43dBm0)
51causes the main receiver computation to begin. The initial measured power is
52used to quickly set the gain of the receiver. After this initial settling, the
53front end gain is locked, and the adaptive equalizer tracks any subsequent
54signal level variation. The signal is oversampled to 24000 samples/second (i.e.
55signal, zero, zero, signal, zero, zero, ...) and fed to a complex root raised
56cosine pulse shaping filter. This filter has been modified from the conventional
57root raised cosine filter, by shifting it up the band, to be centred at the nominal
58carrier frequency. This filter interpolates the samples, pulse shapes, and performs
59a fractional sample delay at the same time. 192 sets of filter coefficients are used
60to achieve a set of finely spaces fractional sample delays, between zero and
61one sample. By choosing every fifth sample, and the appropriate set of filter
62coefficients, the properly tuned symbol tracker can select data samples at 4800
63samples/second from points within 0.28 degrees of the centre and mid-points of
64each symbol. The output of the filter is multiplied by a complex carrier, generated
65by a DDS. The result is a baseband signal, requiring no further filtering, apart from
66an adaptive equalizer. The baseband signal is fed to a T/2 adaptive equalizer.
67A band edge component maximisation algorithm is used to tune the sampling, so the samples
68fed to the equalizer are close to the mid point and edges of each symbol. Initially
69the algorithm is very lightly damped, to ensure the symbol alignment pulls in
70quickly. Because the sampling rate will not be precisely the same as the
71transmitter's (the spec. says the symbol timing should be within 0.01%), the
72receiver constantly evaluates and corrects this sampling throughout its
73operation. During the symbol timing maintainence phase, the algorithm uses
74a heavier damping.
75
76The carrier is specified as 1800Hz +- 1Hz at the transmitter, and 1800 +-7Hz at
77the receiver. The receive carrier would only be this inaccurate if the link
78includes FDM sections. These are being phased out, but the design must still
79allow for the worst case. Using an initial 1800Hz signal for demodulation gives
80a worst case rotation rate for the constellation of about one degree per symbol.
81Once the symbol timing synchronisation algorithm has been given time to lock to the
82symbol timing of the initial alternating pattern, the phase of the demodulated signal
83is recorded on two successive symbols - once for each of the constellation positions.
84The receiver then tracks the symbol alternations, until a large phase jump occurs.
85This signifies the start of the next phase of the training sequence. At this
86point the total phase shift between the original recorded symbol phase, and the
87symbol phase just before the phase jump occurred is used to provide a coarse
88estimation of the rotation rate of the constellation, and it current absolute
89angle of rotation. These are used to update the current carrier phase and phase
90update rate in the carrier DDS. The working data already in the pulse shaping
91filter and equalizer buffers is given a similar step rotation to pull it all
92into line. From this point on, a heavily damped integrate and dump approach,
93based on the angular difference between each received constellation position and
94its expected position, is sufficient to track the carrier, and maintain phase
95alignment. A fast rough approximator for the arc-tangent function is adequate
96for the estimation of the angular error.
97
98The next phase of the training sequence is a scrambled sequence of two
99particular symbols. We train the T/2 adaptive equalizer using this sequence. The
100scrambling makes the signal sufficiently diverse to ensure the equalizer
101converges to the proper generalised solution. At the end of this sequence, the
102equalizer should be sufficiently well adapted that is can correctly resolve the
103full QAM constellation. However, the equalizer continues to adapt throughout
104operation of the modem, fine tuning on the more complex data patterns of the
105full QAM constellation.
106
107In the last phase of the training sequence, the modem enters normal data
108operation, with a short defined period of all ones as data. As in most high
109speed modems, data in a V.17 modem passes through a scrambler, to whiten the
110spectrum of the signal. The transmitter should initialise its data scrambler,
111and pass the ones through it. At the end of the ones, real data begins to pass
112through the scrambler, and the transmit modem is in normal operation. The
113receiver tests that ones are really received, in order to verify the modem
114trained correctly. If all is well, the data following the ones is fed to the
115application, and the receive modem is up and running. Unfortunately, some
116transmit side of some real V.17 modems fail to initialise their scrambler before
117sending the ones. This means the first 23 received bits (the length of the
118scrambler register) cannot be trusted for the test. The receive modem,
119therefore, only tests that bits starting at bit 24 are really ones.
120
121The V.17 signal is trellis coded. Two bits of each symbol are convolutionally coded
122to form a 3 bit trellis code - the two original bits, plus an extra redundant bit. It
123is possible to ignore the trellis coding, and just decode the non-redundant bits.
124However, the noise performance of the receiver would suffer. Using a proper
125trellis decoder adds several dB to the noise tolerance to the receiving modem. Trellis
126coding seems quite complex at first sight, but is fairly straightforward once you
127get to grips with it.
128
129Trellis decoding tracks the data in terms of the possible states of the convolutional
130coder at the transmitter. There are 8 possible states of the V.17 coder. The first
131step in trellis decoding is to find the best candidate constellation point
132for each of these 8 states. One of thse will be our final answer. The constellation
133has been designed so groups of 8 are spread fairly evenly across it. Locating them
134is achieved is a reasonably fast manner, by looking up the answers in a set of space
135map tables. The disadvantage is the tables are potentially large enough to affect
136cache performance. The trellis decoder works over 16 successive symbols. The result
137of decoding is not known until 16 symbols after the data enters the decoder. The
138minimum total accumulated mismatch between each received point and the actual
139constellation (termed the distance) is assessed for each of the 8 states. A little
140analysis of the coder shows that each of the 8 current states could be arrived at
141from 4 different previous states, through 4 different constellation bit patterns.
142For each new state, the running total distance is arrived at by inspecting a previous
143total plus a new distance for the appropriate 4 previous states. The minimum of the 4
144values becomes the new distance for the state. Clearly, a mechanism is needed to stop
145this distance from growing indefinitely. A sliding window, and several other schemes
146are possible. However, a simple single pole IIR is very simple, and provides adequate
147results.
148
149For each new state we store the constellation bit pattern, or path, to that state, and
150the number of the previous state. We find the minimum distance amongst the 8 new
151states for each new symbol. We then trace back through the states, until we reach the
152one 16 states ago which leads to the current minimum distance. The bit pattern stored
153there is the error corrected bit pattern for that symbol.
154
155So, what does Trellis coding actually achieve? TCM is easier to understand by looking
156at the V.23bis modem spec. The V.32bis spec. is very similar to V.17, except that it
157is a full duplex modem and has non-TCM options, as well as the TCM ones in V.17.
158
159V32bis defines two options for pumping 9600 bits per second down a phone line - one
160with and one without TCM. Both run at 2400 baud. The non-TCM one uses simple 16 point
161QAM on the raw data. The other takes two out of every four raw bits, and convolutionally
162encodes them to 3. Now we have 5 bits per symbol, and we need 32 point QAM to send the
163data.
164
165The raw error rate from simple decoding of the 32 point QAM is horrible compared to
166decoding the 16 point QAM. If a point decoded from the 32 point QAM is wrong, the likely
167correct choice should be one of the adjacent ones. It is unlikely to have been one that
168is far away across the constellation, unless there was a huge noise spike, interference,
169or something equally nasty. Now, the 32 point symbols do not exist in isolation. There
170was a kind of temporal smearing in the convolutional coding. It created a well defined
171dependency between successive symbols. If we knew for sure what the last few symbols
172were, they would lead us to a limited group of possible values for the current symbol,
173constrained by the behaviour of the convolutional coder. If you look at how the symbols
174were mapped to constellation points, you will see the mapping tries to spread those
175possible symbols as far apart as possible. This will leave only one that is pretty
176close to the received point, which must be the correct choice. However, this assumes
177we know the last few symbols for sure. Since we don't, we have a bit more work to do
178to achieve reliable decoding.
179
180Instead of decoding to the nearest point on the constellation, we decode to a group of
181likely constellation points in the neighbourhood of the received point. We record the
182mismatch for each - that is the distance across the constellation between the received
183point and the group of nearby points. To avoid square roots, recording x2 + y2 can be
184good enough. Symbol by symbol, we record this information. After a few symbols we can
185stand back and look at the recorded information.
186
187For each symbol we have a set of possible symbol values and error metric pairs. The
188dependency between symbols, created by the convolutional coder, means some paths from
189symbol to symbol are possible and some are not. It we trace back through the possible
190symbol to symbol paths, and total up the error metric through those paths, we end up
191with a set of figures of merit (or more accurately figures of demerit, since
192larger == worse) for the likelihood of each path being the correct one. The path with
193the lowest total metric is the most likely, and gives us our final choice for what we
194think the current symbol really is.
195
196That was hard work. It takes considerable computation to do this selection and traceback,
197symbol by symbol. We need to get quite a lot from this. It needs to drive the error rate
198down so far that is compensates for the much higher error rate due to the larger
199constellation, and then buys us some actual benefit. Well in the example we are looking
200at - V.32bis at 9600bps - it works out the error rate from the TCM option is like using
201the non-TCM option with several dB more signal to noise ratio. That's nice. The non-TCM
202option is pretty reasonable on most phone lines, but a better error rate is always a
203good thing. However, V32bis includes a 14,400bps option. That uses 2400 baud, and 6 bit
204symbols. Convolutional encoding increases that to 7 bits per symbol, by taking 2 bits and
205encoding them to 3. This give a 128 point QAM constellation. Again, the difference between
206using this, and using just an uncoded 64 point constellation is equivalent to maybe 5dB of
207extra signal to noise ratio. However, in this case it is the difference between the modem
208working only on the most optimal lines, and being widely usable across most phone lines.
209TCM absolutely transformed the phone line modem business.
210*/
211
212/*!
213 V.17 modem receive side descriptor. This defines the working state for a
214 single instance of a V.17 modem receiver.
215*/
217
218#if defined(__cplusplus)
219extern "C"
220{
221#endif
222
223/*! Initialise a V.17 modem receive context.
224 \brief Initialise a V.17 modem receive context.
225 \param s The modem context.
226 \param bit_rate The bit rate of the modem. Valid values are 7200, 9600, 12000 and 14400.
227 \param put_bit The callback routine used to put the received data.
228 \param user_data An opaque pointer passed to the put_bit routine.
229 \return A pointer to the modem context, or NULL if there was a problem. */
230SPAN_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);
231
232/*! Reinitialise an existing V.17 modem receive context.
233 \brief Reinitialise an existing V.17 modem receive context.
234 \param s The modem context.
235 \param bit_rate The bit rate of the modem. Valid values are 7200, 9600, 12000 and 14400.
236 \param short_train TRUE if a short training sequence is expected.
237 \return 0 for OK, -1 for bad parameter */
238SPAN_DECLARE(int) v17_rx_restart(v17_rx_state_t *s, int bit_rate, int short_train);
239
240/*! Release a V.17 modem receive context.
241 \brief Release a V.17 modem receive context.
242 \param s The modem context.
243 \return 0 for OK */
244SPAN_DECLARE(int) v17_rx_release(v17_rx_state_t *s);
245
246/*! Free a V.17 modem receive context.
247 \brief Free a V.17 modem receive context.
248 \param s The modem context.
249 \return 0 for OK */
250SPAN_DECLARE(int) v17_rx_free(v17_rx_state_t *s);
251
252/*! Get the logging context associated with a V.17 modem receive context.
253 \brief Get the logging context associated with a V.17 modem receive context.
254 \param s The modem context.
255 \return A pointer to the logging context */
257
258/*! Change the put_bit function associated with a V.17 modem receive context.
259 \brief Change the put_bit function associated with a V.17 modem receive context.
260 \param s The modem context.
261 \param put_bit The callback routine used to handle received bits.
262 \param user_data An opaque pointer. */
263SPAN_DECLARE(void) v17_rx_set_put_bit(v17_rx_state_t *s, put_bit_func_t put_bit, void *user_data);
264
265/*! Change the modem status report function associated with a V.17 modem receive context.
266 \brief Change the modem status report function associated with a V.17 modem receive context.
267 \param s The modem context.
268 \param handler The callback routine used to report modem status changes.
269 \param user_data An opaque pointer. */
270SPAN_DECLARE(void) v17_rx_set_modem_status_handler(v17_rx_state_t *s, modem_status_func_t handler, void *user_data);
271
272/*! Process a block of received V.17 modem audio samples.
273 \brief Process a block of received V.17 modem audio samples.
274 \param s The modem context.
275 \param amp The audio sample buffer.
276 \param len The number of samples in the buffer.
277 \return The number of samples unprocessed.
278*/
279SPAN_DECLARE_NONSTD(int) v17_rx(v17_rx_state_t *s, const int16_t amp[], int len);
280
281/*! Fake processing of a missing block of received V.17 modem audio samples.
282 (e.g due to packet loss).
283 \brief Fake processing of a missing block of received V.17 modem audio samples.
284 \param s The modem context.
285 \param len The number of samples to fake.
286 \return The number of samples unprocessed.
287*/
288SPAN_DECLARE_NONSTD(int) v17_rx_fillin(v17_rx_state_t *s, int len);
289
290/*! Get a snapshot of the current equalizer coefficients.
291 \brief Get a snapshot of the current equalizer coefficients.
292 \param s The modem context.
293 \param coeffs The vector of complex coefficients.
294 \return The number of coefficients in the vector. */
295#if defined(SPANDSP_USE_FIXED_POINTx)
296SPAN_DECLARE(int) v17_rx_equalizer_state(v17_rx_state_t *s, complexi_t **coeffs);
297#else
298SPAN_DECLARE(int) v17_rx_equalizer_state(v17_rx_state_t *s, complexf_t **coeffs);
299#endif
300
301/*! Get the current received carrier frequency.
302 \param s The modem context.
303 \return The frequency, in Hertz. */
304SPAN_DECLARE(float) v17_rx_carrier_frequency(v17_rx_state_t *s);
305
306/*! Get the current symbol timing correction since startup.
307 \param s The modem context.
308 \return The correction. */
309SPAN_DECLARE(float) v17_rx_symbol_timing_correction(v17_rx_state_t *s);
310
311/*! Get a current received signal power.
312 \param s The modem context.
313 \return The signal power, in dBm0. */
314SPAN_DECLARE(float) v17_rx_signal_power(v17_rx_state_t *s);
315
316/*! Set the power level at which the carrier detection will cut in
317 \param s The modem context.
318 \param cutoff The signal cutoff power, in dBm0. */
319SPAN_DECLARE(void) v17_rx_signal_cutoff(v17_rx_state_t *s, float cutoff);
320
321/*! Set a handler routine to process QAM status reports
322 \param s The modem context.
323 \param handler The handler routine.
324 \param user_data An opaque pointer passed to the handler routine. */
325SPAN_DECLARE(void) v17_rx_set_qam_report_handler(v17_rx_state_t *s, qam_report_handler_t handler, void *user_data);
326
327#if defined(__cplusplus)
328}
329#endif
330
331#endif
332/*- End of file ------------------------------------------------------------*/
void(* modem_status_func_t)(void *user_data, int status)
Definition: async.h:114
void(* put_bit_func_t)(void *user_data, int bit)
Definition: async.h:105
Definition: complex.h:43
Definition: complex.h:78
Definition: private/logging.h:34
Definition: private/v17rx.h:55
put_bit_func_t put_bit
The callback function used to put each bit received.
Definition: private/v17rx.h:59
int short_train
Scrambler tap.
Definition: private/v17rx.h:168
int bit_rate
The bit rate of the modem. Valid values are 7200 9600, 12000 and 14400.
Definition: private/v17rx.h:57
float v17_rx_carrier_frequency(v17_rx_state_t *s)
Definition: v17rx.c:170
float v17_rx_signal_power(v17_rx_state_t *s)
Definition: v17rx.c:182
logging_state_t * v17_rx_get_logging_state(v17_rx_state_t *s)
Get the logging context associated with a V.17 modem receive context.
Definition: v17rx.c:1374
v17_rx_state_t * v17_rx_init(v17_rx_state_t *s, int bit_rate, put_bit_func_t put_bit, void *user_data)
Initialise a V.17 modem receive context.
Definition: v17rx.c:1517
SPAN_DECLARE_NONSTD(int) v17_rx(v17_rx_state_t *s
Process a block of received V.17 modem audio samples.
void v17_rx_set_qam_report_handler(v17_rx_state_t *s, qam_report_handler_t handler, void *user_data)
Definition: v17rx.c:1563
void v17_rx_set_modem_status_handler(v17_rx_state_t *s, modem_status_func_t handler, void *user_data)
Change the modem status report function associated with a V.17 modem receive context.
Definition: v17rx.c:1367
int v17_rx_restart(v17_rx_state_t *s, int bit_rate, int short_train)
Reinitialise an existing V.17 modem receive context.
Definition: v17rx.c:1380
int v17_rx_equalizer_state(v17_rx_state_t *s, complexf_t **coeffs)
Get a snapshot of the current equalizer coefficients.
Definition: v17rx.c:208
void v17_rx_signal_cutoff(v17_rx_state_t *s, float cutoff)
Definition: v17rx.c:188
void v17_rx_set_put_bit(v17_rx_state_t *s, put_bit_func_t put_bit, void *user_data)
Change the put_bit function associated with a V.17 modem receive context.
Definition: v17rx.c:1360
int v17_rx_free(v17_rx_state_t *s)
Free a V.17 modem receive context.
Definition: v17rx.c:1556
int v17_rx_release(v17_rx_state_t *s)
Release a V.17 modem receive context.
Definition: v17rx.c:1550
float v17_rx_symbol_timing_correction(v17_rx_state_t *s)
Definition: v17rx.c:176