
Citation->  Electronic Design, March 9, 1989, v37, n5, p47(9), COPYRIGHT
            Hayden Pub. Co., Inc. 1989, *** Full-text article (28186
            characters, 505   lines) ***

----------------------------------------------------------------------------

Title->     Black magic: building a V.32 modem. (V.32 Modem Design)
            (technical)

Authors->   Till, Johna

Summary->   High-speed modem designers deal with echo cancellation,
            error-correction coding and tight requirements for analog
            components. The fastest dial-up modem is defined by CCITT
            Recommendation V.32. At 9600 bps, full duplex, this is 'the
            Ferrari of modems.' Starting with the data pump, design of a
            V.32 modem is described and discussed. Choosing and designing
            the modem's special features are considered. Component
            engineering is emphasized. A book, The Theory and Practice of
            Modem Design by John A.C. Bingham (John Wiley and Sons, New
            York, NY), is recommended to those wishing to learn more about
            V.32 modem design.

----------------------------------------------------------------------------

Subject Hd->Modems;  How-To Information;  9600 Bps;  System Design

Features->  illustration;  chart

Article #-> 07149054

----------------------------------------------------------------------------

BLACK MAGIC: BUILDING A V.32 MODEM

Designing a high-speed dial-up modem is a lot like devising a Ferrari Testa
Rossa: At high speeds, new problems appear and old ones are exacerbated. 
Just as Ferrari designers have to cope with increased cooling requirements,
streamlining, and aerodynamic stability, high-speed modem designers must
deal with echo cancellation, error-correction econding, and tighter
requirements for analog components.  In a similar vein, the design of the
modem's "engine"--the data pump--is critical to the unit's performance.

Although it's possible to go faster with complex data-compression
algorithms, the fastest standard dial-up modem is defined by the CCITT
Recommendation V.32.  At 9600 bits/s, full duplex, this is truly the Ferrari
of modems.

"It's certainly the most exciting standtard from a technology standpoint,"
says Dudley Westlake, modem marketing manager at Rockwell International
Corp's Newport Beach, Calif., division.  No other modem packs adaptive
equalization, echo cancellation, and trellis coding along with options for
backward error correction and data compression.

Designing such a powerhouse can be a daunting task.  As you begin to design
a V.32 modem--whether as part of your next systems or to enter the
high-speed modem marketplace--you might wonder where to begin.  For
starters, take a brief look at the modem's engine.

The heart of a V.32 system--as in any modem--is the data pump, whic handles
the modulation and demodulation of the signal.  In a V.32 modem, the data
pump also handles forward error-correction enconding, filtering,
equalization, scrambling and descrambling, and echo cancellation.

Most often, the data pump's design is part analog and part digital.  The
analog section takes care of various front-end jobs, including
analog-to-digital and digital-to-analog conversion.  It also deals with
near-end echo cancellation.  The digital part consists of some digital
signal processors, which perform the trellis coding, adaptive equalization,
and filtering for far-end echo cancellation.

Though V.32-data-pump design sounds straightforward enough, it's usually
described by experts as a "black art."  As with the temperamental Ferrari,
careful tuning and tweaking is necessary to achieve optimum performance. 
Consequently, one of the first design issues in building a V.32 machine is
deciding how much of the data pump to build yourself.  Designers often turn
to a predesigned chip set or module for the data pump and turn their
energies toward the modem's other features.  To better understand these
design options, it helps to examine the rest of a V.32 modem.

Functionally, the modem can be divided into six parts.  Besides the data
pump, there's the data-access-arrangement (DAA) circuit, the
data-terminal-equipment (DTE) interface, control and display functions, the
microprocessor, and other "value-added" functions, such as backward
error-correction and data compression (Fig. 1).

The DAA is the interface between the modem and the telephone lines.  Though
it can be tricky to design--especially in he case of the V.32--it often
comes as part of a chip set, requiring only a transformer and resistor.  The
specifications for some components--the transformer, in particular--are
quite stringent because the transformer's linearity directly affects how
well the echo-cancellation algorithm works.  If you've designed a DAA
before, though, making one for a V.32 modem shouldn't present a tremendous
obstacle.

Similarly, interfacing to the DTE should be easy.  Electronic Industry
Association standard 232-D and the CCITT recommendation V.32 govern the
connectors, cable, and lead use.  The main problem here is inside the DTE. 
Small computers often can't handle a full-duplex 9600-bit/s rate, andthere
can be buffer overload problems.

Designing the control and display circuitry and choosing the microprocessor
depend on what added functions the modem will need. If you want to use
complex data-compression algorithms, for instance, you'll have to ensure
that the host processor can handle the computation.  You may, in fact, want
to use an auxiliary processor just for data compression.

USER-FRIENDLY FEATURES

Choosing and designing the modem's special features can constitute the whole
of the design.  On top of data compression and backward error-correction,
you can add security features, such as encryption, passwords, and callback;
network management and diagnostic abilities; and user-friendly features like
autodial.  Because there are so many other areas to work on, manufacturers
often design their own data pumps in order to avoid reinventing the wheel. 
They work on either offering more in the total modem package or tailoring
the modem to fit specific system needs.  "A merchant modem needs most of the
standard features to be competitive," says Howard Raphael, chairman of the
board of directors at Cermetek Microelectronics Inc., in Sunnyvale, Calif. 
"Designers of an OEM modem, though, can groom it for specific system needs."

Of course, you might decide you want to build an optimum-performance modem
as well.  That is, you might want to tackle the data-pump design.  If so,
you should know what's involved.

A V.32 data pump includes adaptive equalization, echo cancellation, and
trellis coding.  Both echo cancellation and trellis coding are relatively
new techniques, and both seem fairly straightforward in theory.  The real
world, however, is not as simple.  Echo cancellation, in particular, is much
harder to do in practice.

An echo canceler does just what its name implies--it cancels echoes.  These
echoes arise from signal reflection at impedance mismatches at the two- to
four-wire hybrids.  There are several different kinds of echo, and all must
be canceled.

Listener echo appears when a modem's receiver first hears a signal and the
hears its echo.  The echo results from making an extra trip across either
the two- or four-wire connection (Fig. 2).  Because the echo is usually much
weaker than the original signal, listener echo isn't a problem.  Generally,
listener echo is stripped out during adaptive equalization.

Talker echo is far more troublesome.  It results from the reflection of a
modem's transmitted signal back into its receiver. Near-end echo arises when
the reflection is at the two-wire-to-four-wire interface, and far-end echo
comes from the four-wire-to-two-wire hybrid (Fig. 3).  Because the echo is
that of the transmitted signal, it's much larger than the received signal.
This is because the received signal might have traversed as much as
thousands of miles of cable.

Canceling this type of echo can be very tricky.  Often, the near-end echo is
canceled at the modem's analog front end, so digital signal processing can
be done on a signal with less dynamic range.  Because the received signal is
so small--with an average attenuation of 33 dB--the a-d converter might not
have enough bits to handle both types of echoes with sufficient accuracy. 
Deciding where to cancel the near-end echo, in fact, is an important factor
in the modem's design.

Once you've stripped out the near-end echo, the far-end echo cancellation
begins.  The transmitted signal is fed to an echo emulator, which emulates
the changes that the transmitted signal has presumably undergone during its
far-end reflection--chiefly delay.

SHAKING HANDS

The delays are calculated during the initial handshaking part of the V.32
protocol, in which each modem sends a signal (half-duplex) down the line to
find the linehs echo characteristics.  This information then sets the taps
in the echo emulator's digital filters.  The presumed echo (transmitted
signal after filtering) is subtracted from the total received signal, and
the result is checked for correlation with the transmitted signal using a
decision-feedback-equalizer type of algorithm.  If there's correlation
between the received signal and the transmitted signal, the echo emulator is
modified to try to cancel it.  When the transmitted signal and the received
signal show no correlation, the echo has been successfully removed (Fig. 4).

All this takes place in real time, with limited signal-processing resources.
Not only is there a finite number of filter taps for what might be an
infinite situation, but also the algorithm for setting them must be fast,
accurate, and robust.

One solution to the problem of canceling echoes is to buy a pre-programmed
echo-cancellation DSP chip, such as SGS-Thompson's TS75320 CP
echo-cancellation IC.  You could then design the data pump around it.  But
even this doesn't get you out of the woods, because other aspects of the
pump design can get hairy.  These include the timing and carrier recovery,
the trellis-coding algorithm, and subtle problems like phase roll and ground
noise.

The timing in a V.32 modem is determined by the transmitter.  A
crystal-based clock in the data pump sets the time for the transmitted
signal, but the modem has to lock the received signal to the transmitted
data.  It does that at a rate determined by the transmit clock.  Because
crystals in the two modems aren't matched exactly, what tends to happen is
that the received signal slowly precesses with respect to the transmitted
signal.  This problem can be difficult to solve.

PHASE ROLL

Sometimes, thanks to phase roll--another unexpected difficulty--signals
change rapidly with respect to each other. Especially on international
lines, the far-end echo can include a frequency shift.  A signal that goes
out at 1.8 kHz, for instance, can come back at 1.801 kHz.  This is because
as the signal travels along the trunk line, it undergoes a slight frequency
shift.  If it returns on the same trunk line, the shift is canceled out.  If
not, phase roll could occur.  In this case, "There's an awful lot of black
magic involved, because people don't agree on the characteristics of the
far-end echo and the phase roll," warns John Bingham, a data-transmission
consultant from Palo Alto, Calif.

Trellis coding is another design that's simple on paper but difficult to
make work accurately.  It isn't unusually tough to implement, but the catch
is finding an algorithm that's robust enough to stand up to real-life line
requirements, yet compact enough to execute quickly.  Telephone-line
situations are often much worse than you would suspect, and your algorithms
must be particularly durable.

The basic idea behind V.32 trellis coding is that four bits are encoded as
five, increasing the number of points in the point-constellation signal
space from 16(2.sup.4.) (Fig. 5a) to 32 (Fig. 5b).  The minimum distance
between points also increases, making their detection less ambiguous. 
Trellis coding--also called forward error correcting--is really a way to
minimize, rather than correct, errors.  It works best with predominantly
white noise, rather than burst noise.  Backward error-correcting encoding
works better in situations in which there's a lot of burst noise.  In many
cases, you need both kinds of coding.

The big trade-off with trellis coding is between the amount of data you save
for encoding and the amount of processing you must do.  Finding a balance
between the two is necessary for a robust algorithm.

With timing and coding difficulties, the problem is that when a V.32 modem
realizes it's no longer receiving correct data, it "retrains" or
reinitializes.  While not a problem in slower modems--some can retrain in
under a second--retraining in a V.32 can take up to 10 to 12 seconds.  If a
modem has to retrain too often, its throughput degrades considerably.  If
your timing solutions and trellis algorithms aren't carefully thought out,
your modem will perform poorly.

Circuit layout can also cause problems.  If you use switched-capacitor
circuitry, you get noise when the frequency at which the FETs are switched
beats with timing frequencies.  Other noise difficulties arise when the
noise floor from the analog front end gets too high.  In this case, when you
lower the received signal level, but maintain the same signal-to-noise
ratio, you'll find that you can't pick up the signal because of the internal
noise.  To avoid these problems, you must take extreme care when routing
your digital lines to be sure that they're properly isolated from the analog
lines.  Solid separate grounding is a must.

MODEM GURUS

It takes experienced modem designers to foresee these problems, and most
design teams talk about having a "modem guru," as well as a signal
processing expert, on board.  These engineers can also be helpful in yet
another way: interpreting the standards.  "Because standards like the V.32
were written by people with a knowledge of the art and science of modem
design, they are written in a sort of shorthand," says William Berger, a
group leader in modem applications at Rockwell.  "Inexperienced designers
may underestimate, or miss entirely, the significance of a deceptively
simple statement."

Clearly, the first design issue you'll face is whether to buy or build the
data pump.  If your design team has high-speed experience, you can afford to
take the extra time--as long as an extra year--to get the modem to market. 
And if your company has the resources, building your own might make sense. 
You can use either general-purpose digital signal processors--many engineers
recommend TI's TMS320 DSP series--or custom or semi-custom parts.  Though it
would take longer, your own design might be more economical and perform
better.  This depends, of course, on how good your design is and how many
V.32 modems you plan to build.

On the other hand, if you need a V.32 modem as part of a system, must get to
market quickly, and aren't making an overwhelming number of modems, your
best bet might be to go with a predesigned data pump.  Several good V.32
data-pump chip sets and modules are available, including a module from
Rockwell and chip sets from Phylon, SGS-Thompson, and Universal Data
Systems.

EACH PUMP IS DIFFERENT

Because every pump's characteristics are different, you'll want to take a
few months to test different pumps before deciding on one. You should design
a test bed, simulate telephone lines, and check out bit-error-rate (BER)
versus signal-to-noise ratio.  Also, look carefully at things like the data
pump's phase jitter and noise level (Fig. 6).  Measure the amount of phase
roll it can handle. See how many times the pump must retrain over different
telephone lines.  After all, "Not all data pumps are created equal," warns
Ken Miller, chief technology officer at Concord Data Systems Inc. in
Marlborough, Mass. Sam Deus, V.32 project leader and senior electronics
engineer at NEC America Inc. in San Jose, Calif., concurs.  "Performance
evaluation of the data pump is the most critical aspect of the design," he
says.

Also, be aware of what is and isn't included on the data-pump chip set or
module.  Some data pumps have extra features, such as dialing commands. 
Check to see which diagnostics are present: Is there a full suite of test
functions?  Some chip sets don't include remote digital loopback abilities
(CCITT Recommendation V.54, loop 2). Others don't include the Viterbi
decoding algorithm, so you'll have to add your own.  This algorithm might
add another 25% to the amount of processing, so you might consider adding
another DSP chip or using a bigger processor.  Again, some chip sets don't
include scramblers and de-scramblers.

Modem testing is an art in itself, especially when it comes to engine
performance.  For this reason, some manufacturers limit themselves to
data-rate, compatibility, and throughput measurements.  If you want to get
deeply involved in performance issues, though, there are a few items to
watch out for.  One is to be sure that you're only varying what you think
you are.  "Repeatability of test results is a problem," says William Berger
of Rockwell.  "Analog test equipment with manual dials makes it easy to make
a slight change in setting, with a big change in the modem's results.  For
instance, waterfall curves--BER versus signal-to-noise ratio--are very
steep, and a small change may mean a large change along the curve."  (Fig.
7)

Another problem can come when you generate noise.  If you're using a digital
generator to create white noise, be careful not to choose too short a
sequence in your polynomial.  If you do, you'll get concentrations in the
frequency spectrum that shouldn't be there.

While you're testing and comparing data pumps, you can be working on the
DAA, controlling processor, extra features, and user interface (if there is
one).  Critical to the success of your design at this point is "a dedicated
team--one that works well together," according to NEC's Sam Deus.  He
further notes, "Your hardware designer doing the DAA and EIA interface must
work closely with the designer doing the controlling code."

COMPONENT ENGINEERING

On the DAA side, most of the design revolves around choosing the parts
correctly.  "Component engineering is even more important in a V.32 modem
than in other modem designs," says Darryl Sell, vice president of
engineering at Racal-Vadic, in Milpitas, Calif.  This is particularly true
when dealing with the transformer at the telephone-line interface.  Finding
a transformer that's highly linear, but in which the primary coil is
conducting perhaps 100 mA of dc current, is no easy task.  "Your transformer
must have at least -65 dB and preferably -70 dB of harmonic distortion,"
Sell points out.  John Bingham warns, "One way to get burned building V.32s
is to cut pennies on the transformer."

Depending on the data pump you've chosen, choosing the transformer might be
all the analog designing you do.  If not, the choice of an a-d converter is
important.  "If you want to be classical about it, just taking the incoming
signal and digitizing it, you need a 14-to-15-bit converter," says Sell.

Other issues crop up when you design the architecture of the modem's
processing and control section.  A critical decision is which microprocessor
to use.  The conventional choice for modem control is a Z80, but many
designers warn that this won't be powerful enough for a V.32.  "If you're
upgrading from a Z80, a good choice is the 64180, so you can use the same
code," says Concord Data's Ken Miller.  "It has direct memory access,
paging, and other good features.  Some high-end designers even go to the
68000 series for CPU-intensive tasks."

Another crucial decision is which functions to implement in the controlling
processor and which to do in other hardware.  An example is controlling
serial communications.  If you do it with the microprocessor, you can save
the cost (and space) of an extra piece of hardware.  Pack too many functions
on your processor, though, and you'll need to choose a more powerful,
expensive design to keep the system's real-time performance acceptable.

There's a similar problem with memory.  If you write your control code in a
high-level language, it will be portable and easier to design and debug.  On
the other hand, it takes up more memory.  To save the cost of memory, you
might end up writing it in assembly language.

An interesting part of the V.32 modem design is adding the extra functions. 
These differentiate one V.32 modem from the next, and it's with these that
designers target their modems to end users or tailor them for integration
into a specific system.  As in most aspects of the design, standards are
important here.  "Make a list of your requirements, then look at the
relevant international standards," says Howard Raphael of Cermetek.

One of the most likely candidates for inclusion here is a backward
error-correction protocol.  While the V.32 recommendation already specifies
one error-correction protocol (trellis coding) just to attain its 9600-bit/s
data rate, adding another ensures that the data delivered by the modem is
correct.

Backward error-correction is basically error-correction by retransmission. 
Data is packaged into packets, then framed by framing, control, and
addressing bits.  Some form of cyclic redundancy check is added to the
packet, and then it's transmitted. The modem at the other end checks each
packet for data integrity. If the packet is error-free, the receiving modem
informs the transmitting modem with an acknowledge signal.  If there are
errors, the receiving modem sends back the packet address with an error
signal, and the packet is retransmitted.

COMPLY OR CONFORM

Two common protocols for this type of error-correction are the Microcom
Network Protocol (MNP), level 4, and the Link Access Protocol D (LAPD).  The
two are not compatible.  The CCITT recently decided upon a compromise
between them in its V.42 recommendation: Rather than choose one protocol
over the other, V.42-compliant modems will include LAPM, a protocol similar
to LAPD, and MNP-4 (LAPM and LAPD, while similar, aren't identical).  A V.42
modem will determine which protocol its connecting modem uses.  If both use
LAPM, the link will follow that protocol.  If not, the link will be made
using the MNP level 4 protocol.

"Key here is the word compliant," says Dave McNamara, a senior product
planning manager at Codex Corp. in Mansfield, Mass.  "A modem that supports
just MNP-4 is compatible with the V.42 recommendation, as is one that
supports just LAPM--but neither of them are compliant with V.42."

V.32 designers must choose one or the other--or both--of the protocols for
their applications.  One factor to keep in mind is that the MNP-4 is a
proprietary protocol (developed by Microcom), and it requires licensing
fees.  Of course, designers could also develop their own error-correction
protocols.  This strategy would make the most sense if the modems were
designed for a close environment--say, a factory floor.

Data compression is another option for V.32 designers.  With a 2:1
data-compression ratio, the 9600-bit/s rate jumps to 19.2 kbits/s; with a
3:1 algorithm, the rate rises to 38.6 kbits/s.  One of the most widely
implemented data-compression algorithms is included in the MNP level 5
protocol suite.  Because it's the first broadly implemented compression
algorithm, MNP-5 has become something of a defacto standard.

However, the CCITT is in the process of deciding upon a recommendation
governing data compression.  This recommandation will probably be known as
V.42 bis, and the algorithm under consideration is one developed by British
Telecom.  MNP-5 isn't being considered, in part because the MNP protocols
violate the OSI 7-layer model for communication protocols.  Consequently,
designers who want their modems to comply with a future standard for data
compression would do well to conform to the V.42 bis.

The V.42 bis data-compression algorithm is an example of a smart
data-compression algorithm, one which adapts the compression to the type of
data.  In the V.42 bis approach, the encoder (compressor) and decoder
(decompressor) maintain identical dictionaries of strings.  The encoder
accepts characters and matches them to the longest string in the dictionary.
It then sends the index of the string to the decoder, which reconstructs the
string from its own dictionary.  The key is that the dictionaries are
adaptive--the encoder builds the dictionary by observing the input
characters. Because the decoder must maintain an identical dictionary,
error-free communication between the two is vital.

WRITE, FARM, OR BUY?

Another feature to think about carefully is the modem's command set.  If
you're designing for the European community, you'll probably want to go with
the CCITT V.25 bis recommendation.  If it's for the American PC marketplace,
however, you'll most likely want to choose the Hayes AT command set.  And if
the modem is to be integrated into a system as a PC card, you have a choice
between writing your own software drivers, farming the task out to a
software company, or buying prefabricated drivers.

Other features to consider are security, diagnostics, and network
management.  The type of security capabilities you choose will depend on how
secure the communications must be.  A fairly simple form of security is
password security, in which the modem doesn't grant access without the
correst password.  Another is automatic dialback, in which the user gives
the modem and I.D. or password, and the modem calls back to a prestored
number.  A user that's not at that number clearly won't get access to the
modem.

CRYPTIC MODEMSPEAK

A more comprehensive form of modem security is encryption, in which the data
itself is encrypted.  Users decode the data with a system of keys, and key
management becomes an important issue. Security and network management are
thus closely linked.

Diagnostics and network management are also linked.  One of the more useful
purposes of a network management system is the ability to discern the type
and cause of a modem failure and decide on the appropriate action.  This
could be dispatching a technician to the modem site, for instance.

More basic forms of diagnostics are covered in the CCITT recommendation
V.54, which describes two kinds of loop-back testing appropriate for modems.
Loop 3 is a local analog loop-back ability.  It basically involves hooking
the transmitter to the receiver, although the situation in V.32 is more
complex, thanks to the echo cancellation.  Loop 2 is a remote loop-back
test.  In this mode, one modem sends a test pattern to a remote modem, which
returns it.

Both loops are usually included as part of the engine.  If they aren't, it
might be wise to include them, either alone or as part of a more
comprehensive network-management package.

After you've designed or chosen your data pump, picked your processor, and
agreed on the features to include, it's time to think about one of the more
subtle aspects of modem design: meeting Federal Communications Commission
(FCC) and Electronic Industry Association (EIA) specifications.  In the
U.S., these bodies govern things like radiation emission and lead functions
in connectors.  If a modem is to operate in the U.S., it must be
FCC-certified. Particularly troublesome to modem designers is part 68 of the
FCC rules, which defines the DAA circuitry, and parts 15a and 15b, which
regulate the radiation of industrial and commercial equipment.

"Some designers don't think about these things until the last minute," says
Deus.  "Then they must rely on Band-Aid fixes.  It's better to design
carefully from the beginning."  Another FCC regulation to keep an eye on is
the "drop test"--any hand-held device must be able to withstand a drop of a
certain distance.

One piece of advice that's echoed by most modem manufacturers is to find out
what you're getting into with a V.32 design.  "Do your homework," says Dave
McNamara of Codex.  "Don't underestimate the complexity.  Collect every
piece of information available," Deus agrees.  Miller says, "Be careful,
because this is a very sophisticated technology--much more so than other
modems."

----------------------------------------------------------------------------

