[comp.dcom.modems] Modem Com analyzer wanted

cpcahil@virtech.uucp (Conor P. Cahill) (10/07/90)

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.

Anyone know of such a beast?  I would presume that modem manufacturers
would have one but I am afraid that it may be home-grown.

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. 
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

bill@bilver.UUCP (Bill Vermillion) (10/08/90)

In 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.
->
->Anyone know of such a beast?  I would presume that modem manufacturers
->would have one but I am afraid that it may be home-grown.
->
->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. 
->-- 

Why not just put another modem on the line after the first in a
monitor only mode?  You could capture and then do a compare with
what was supposed to be received.   Reverse the lines and look at
transmit.   (Actually reverse the functions either A or O and set
S10 to 255 to never notice carrier drop).

Then you turn the transmitter off.
AT compatible command sets show this as setting the register C.
ATC0  turns the transmitter off and your modem is a listener only.

I just looked this up in my 1982 Hayes SmartModem manual.  Can you
beleive that sucker cost $550 discounted, for 1200 BPS then!!
Modem's dead, but the manual is still fine :-)

-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill@bilver.UUCP

cpcahil@virtech.uucp (Conor P. Cahill) (10/08/90)

In article <1084@bilver.UUCP> bill@bilver.UUCP (Bill Vermillion) writes:
>
>Why not just put another modem on the line after the first in a
>monitor only mode?  You could capture and then do a compare with
>what was supposed to be received.   Reverse the lines and look at
>transmit.   (Actually reverse the functions either A or O and set
>S10 to 255 to never notice carrier drop).

Because I want to hook this thing up to an existing modem and let it
capture data for extended periods of time and later allow me to 
review the data to see what problems occured on the line.  I already
have stuff to do this on the serial line between the modem and the 
host, but I need to see what is going on between the modems (and 
the data probably should be timestamped & the device should
be able to tell me what is going on in both directions).  Yes
I know this is a big wishlist, and no, I haven't seen any such
product out there.  I am asking the question to see if
someone else out there has heard of such a device.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

urlichs@smurf.sub.org (Matthias Urlichs) (10/08/90)

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)/

lstowell@pyrnova.pyramid.com (Lon Stowell) (10/11/90)

For V.32 you will have the problems with training of the Echo
Cancellor as noted.  

You can use a FireBert from TTC to check the phone lines, you
can use a TAS to check the modems themselves for ability to
survive common impairments...

Frequently it is a matter of a too short carrier hold timing in
V.22bis /V.32 modems.....    Also the tendency of both of these
to retrain in the middle of transmission.  V.22bis modems may
take up to 0.7 to 1 second, V.32's may take up to 48 or more
seconds.   Darned few protocols and Front End Processors account
for these nasty tendencies.....THEY take the link down
prematurely while the modem is attempting to reestablish
commo...

You may wish to use an HP-4954 or Tektronix TC-2000 series
protocol analyzer to see whether the modems or the DTE's are
dropping prematurely....   as a general rule, if DSR drops
before DTR does, the modems did it.... If DTR drops before
either DSR or CxDet, the DTE on THAT modem did it.....