Path: utzoo!attcan!uunet!munnari.oz.au!uhccux!ames!rex!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.dcom.modems
Subject: Re: Modem Com analyzer wanted
Message-ID: <ie!xf2.qe2@smurf.sub.org>
Date: 8 Oct 90 15:20:59 GMT
References: <1990Oct07.123733.15484@virtech.uucp>
Organization: University of Karlsruhe, FRG
Lines: 52

In comp.dcom.modems, article <1990Oct07.123733.15484@virtech.uucp>,
  cpcahil@virtech.uucp (Conor P. Cahill) writes:
< I am looking for a product that I can plug in between the modem and
< the PHONE system (not that this is on the telo line, not the serial
< line - I already have a serial analyzer) to capture the data being
< transmitted and be able to make some sense out of it.
< 
< This think would need to understand V.22, V.22bis, and V.32.
< 
For V.22 or V.22bis, you _might_ get along with the following procedure:
- Buy two extra modems.
- Cut a strategic path on the circuit board so that they can hear the line,
  but are unable to send anything out.
- A few seconds before the two regular modems start talking, tell one of your
  listening modems to ATA and the other to ATD.

For V.32, the above is impossible (or nearly so).
The reason for this is that unlike V.22/V.22bis, which split the allowable
frequency range in two (at 1800 Hz) and use one half for one direction and
the other half for the other, V.32 requires both modems to talk in the same
frequency range. Each modem must extract the remote side's signal from the
phone line by subtracting its own signal for the local echo, and a delayed
version of this for the remote echo (if any).

So a third V.32 modem (or indeed anything else), listening to this, would get
horribly confused.

< The reason I need this is that one of my clients is having trouble
< with a modem dropping calls and/or locking up and we need to figure
< out what is going on. 

There exists equipment to test the quality of phone / other data lines.
(I'm not able to recommend anything, however.) If the two modems can talk to
each other OK when you connect their LINE jacks to each other (and say ATD
and ATA to them) (did you test that?), it might be best to use equipment
which can actually measure & tell you what the trouble is -- analyzing line
noise, bandwidth and filter characteristics, phase shifts and jitters, you
name it.

This is the other problem with the "line monitor" idea -- any box which would
listen on the line, and show the data, won't be able to tell you anything
that you don't already know from the serial analyzer: the data from the local
modem is OK (if not, you've got other problems...), and the remote data show
up on your local modem's serial port anyway.

If the modem "locks up", that is, doesn't even respond to <pause> +++ <pause>
ATH anymore, then that's most likely a hardware or firmware problem, and
looking at the phone line doesn't seem likely to help solving the problem.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/