Troubleshooting phone line quality problems

You probably landed here after reading my modem overview article, if not, please read that first, here.
 
I wrote this diagnostic article after reading through information from http://modemsite.com/. That site was the go-to place for modem use under Windows XP during the 2000’s. During the late 90s when the Winmodem AKA Softmodem was invented the largest producer became Conexant with it’s HCF and HSF winmodems. This changed during the decade of 2000-2010 as there were a plethora of chip makers who jumped into the winmodem chip business, followed later in the decade by a plethora of consolidation and of companies like Creative, Supra, Diamond (which bought Supra and was later itself bought by S3, which was later bought by HTC) Intel, Motorola and others exiting the modem business. modemsite.com was created and it tracked all of that, and is still a must-see site if your dealing with older hardware with PCI busses and older modems under Windows XP.
 
Unfortunately, that site author stopped updating the site in 2010 and many links on it now are broken, although some of the data is still retrievable from the Internet Archive. The biggest problem is there is no information on dealing with modems under Windows 7, particularly 64bit Windows 7 and later. I am attempting here to pick up from where that site left off. I used that site as a starting point as well as posts here and here.
 
For troubleshooting really sophisticated line quality issues, a 56k USR (US Robotics/3com) Courier or Sportster makes available all the needed data and is probably as good as an expensive telephone lineman’s line analysis tester. These modems are available cheaply on Ebay, (as well as new) but older ones are NOT plug-and-play and you will need an edited INF file to run them under Windows 7. See my companion article here on modifying Windows INF files for one of these. You also will need a serial port on your PC – and not many new PC’s ship with serial ports today. However if you don’t have a USR modem a regular modem will likely work – even the cheap internal LSI softmodem can be coaxed to give usable diagnostics. You will also need an analog phone – a linemen’s butt set, (under $20 from Ebay) or even an old “hang up on itself” phone/brick from Goodwill will work.
 
Before troubleshooting line issues, the demarcation point that the phone line enters the building must be located, and the inside line disconnected, then the testing modem or handset must be connected to the incoming line at the dmarc point and tests then are run. Inside wiring issues basically operate under the following rule: if you need instructions on how to correct your own inside wiring, you need to hire a wiring guy to fix it. In other words, running a short length of copper under 200 feet inside a building is so simple that if you can’t do it without screwing it up, you probably should not be attempting to diagnose your phone line problems. We are assuming in this article you are testing at the dmarc point.
 
As a general rule phone line quality issues fall into the following 4 groups; line quality issues, call disconnections, induced interference, and multiple D/A conversions.
 
General line quality issues
 
The first and largest category is general line quality issues. There are 4 major causes of these. The first is poor connections in the phone company network. If you are rural and your phone line is out on poles there may be dozens of splices between your phone and the telephone company Central Office (CO). Some of these splices may not have been done correctly, some may be compromised by rainwater seepage into the cable or animal activity (squirrels chewing on wires, etc.) The second are failing repeaters or other electronic gear, or inadequate spacing of repeaters on a long phone line. The third are manufacturing defects in the phone cable itself. Large 100-pair phone cables can have stretches where on a couple of wires in the cable, the insulation is too thin, or nonexistent. This happens when the wire is made on a worn jig and the insulation is not evenly deposited on the wire. Normally this is not a problem since the adjacent wires in the cable bundle have their insulation intact, but if 2 wires with the same problem press against each other, there will be a connection between them. This can also happen due to overhead cable flexing due to wind movement, the flexing causes the wires to rub against each other. These cause cross connects. Telephone linemen are familiar with this problem and will usually tag these pairs as damaged. The last defect isn’t really a defect, it’s an impedance issue, caused by bridge taps or load coils in the phone line, and it specifically affects DSL connections, not voiceband 56k dialup connections.
 
Some line quality issues can be identified by listening to the line. An intermittent crackling sound like sharp static is likely going to be a bad or compromised splice, or it is going to be failing or failed electronics, like a bad repeater. Occasionally hearing other people’s talking at a faint volume when you are on the phone is generally caused by a cross connect to another line.
 
All of these general line quality issues are only corrected by a telephone company lineman. In general you must contact your phone company and request a dispatch – and it is critical to be present when the lineman arrives so you can talk to him, describe the problem, and find out what the cause was.
 
Incomplete calls/unexpected disconnections
 
The next category is incomplete calls or unexpected disconnections. If this is NOT caused by the ISP booting you off after a certain number of hours, it is caused by phone line quality rapidly varying. (keep in mind there was never any such thing as “unlimited’ dialup it was a marketing term) It can be caused by a cross connect to another line, when the modem is online and the party on the other pair picks up the phone it changes the line characteristics so quickly the modems disconnect. This happens with fax calls also. It can also be caused by a poor quality phone line where the modem has established a call and compensated for the line, but the line characteristics change slightly and the call is just barely hanging on, the slight change is enough to push it over the edge. It also can be caused by going through multiple D/A conversions – such as dialing through a private telephone system – and jitter in the digitized portion of the call disrupting the connection.
 
Some of these problems are also fixable by contacting the phone company, but it can be that the line quality issues are on the other end of the call, at the ISP, or remote fax machine, and you will have no control over that.
 
Induced interference
 
The third category is induced interference. The most common is induced 60 cycle A/C hum. This can be caused by running telephone lines in the same conduit as power lines, (something that is illegal under all building codes) or it can be caused by failing equipment. If it is hum your dealing with, using a portable AM radio tuned in between stations can sometimes establish the source of the hum. I had one case once where the 60 cycle hum radiation was so bad that AM radios that were located at the other end of the home from the interference source, could not tune in stations. The source turned out to be a flat panel computer monitor that visually was working perfectly. I found it by turning off circuit breakers one at a time in the home at the power panel. Sometimes radio signals from broadcast stations are induced on the phone lines, this can be caused by inadequate RF suppression on the phone line at the outside pole. That needs to be checked by the phone company.
 
Multiple A/D conversions which prevent a 56k connection
 
The last category is multiple D/A conversions. This is manifested by any modem being used on the phone line being unable to establish a call higher than 28.8K. This is NOT a problem for fax calls. The USR Courier modem mentioned earlier can be used to identify this with the ATY11 command. A good explanation of how to do this is located here. For this problem there is no fix. In the United States the phone company is not required to provide a phone line that will support a 56k call. You can call and complain but it is unlikely the phone company will do anything about it.
 
Viewing line quality
 
Line quality can be viewed on many modems. The usual procedure is to dial into a 56K modem bank, then when the call disconnects, issue the ATi11 command. Here is an example using a LSI PCI-SV92EX Soft Modem installed in Windows 7 (A Winmodem plugged into the PCI Express slot). This modem capabilities can be gotten this way:

AT +MS=?
+MS:(B103,V21,V23C,B212,V22,V22B,V32,V32B,V32T,V34,V90,V92),(0,1),(0,300-57333),(0,300-57333)

Testing was done while dialing into a NetZero dialup number for Portland, OR, using Hyperterminal, and issuing ATi11 at the modem command prompt:

Description                         Status
---------------                     ------------
Last Connection                     V.92
Initial Transmit Carrier Rate       21600
Initial Receive  Carrier Rate       28800
Final   Transmit Carrier Rate       21600
Final   Receive  Carrier Rate       28800
Protocol Negotiation Result         LAPM
Data Compression Result             V.44
Estimated Signal/Noise Ratio   (dB) 29
Receive  Signal Power Level  (-dBm) 16
Transmit Signal Power Level  (-dBm) 10
Round Trip Delay             (msec) 93
Near Echo Level              (-dBm) 21
Far  Echo Level              (-dBm) 56
Transmit Frame Count                0
Transmit Frame Error Count          0
Receive  Frame Count                0
Receive  Frame Error Count          0
Retrain by Local  Modem             0
Retrain by Remote Modem             1
Rate Renegotiation by Local  Modem  0
Rate Renegotiation by Remote Modem  0
Call Termination Cause              0
Robbed-Bit Signaling                111312
Digital Loss                   (dB) 00
Remote Server ID                    NA
Connection Time               (sec) 46.24

Notice that this modem only connected at 28.8k. This is because this modem is dialing through a private PBX and there are multiple D/A conversions present in the line. But we are looking at line quality for the rest of this article since this modem does not make the parameters available for us to determine if multiple D/A conversions are present on the line.
 
A detailed explanation of what you should see in these parameters is here, but I’ll quote the operative passage:
 
“…The Tx level is the power in decibels per milliwatt (dBm) at which a modem transmits its signal. The Rx level is the power in dBm of the received signal. The server modems normally transmit at -13 dBm by default. Ideally, the Rx level should be in the range of -18 to -25 dBm. If the Rx level is under -25 dBm, the Signal-to-Noise Ratio (SNR) is likely to decrease, meaning that the speed also decreases….”
 
This particular modem is transmitting quite loudly at -10dBm. This might be because the connection is going through multiple A/D conversions and the remote modem has asked our modem to raise power output level to compensate. But the received signal is good at -16dBm, possibly because the private PBX is regenerating and amplifying the received modem signal. The overall S/N is 29, which is pretty good. Apart from the multiple D/A conversion issue that is limiting connect speed to 28.8k, this is a good quality line. Faxes would work perfectly fine over this line.
 
Unimodem/V diagnostics
 
The ATi11 command is intended to be the “human readable” version of line quality information from the modem. However, as we have seen this command output is not standardized and so is useless for the operating system to attempt to parse. To respond to this problem Microsoft created the “Unimodem Diagnostics Command Reference Specification” which defines a rigid set of quality outputs and codes and formatting for this output. This standard is located here.
 
The Windows modem driver Unimodem has a special command it uses to access this line quality information during the connection phase. It is the AT#UD command. Issuing that command to the LSI modem at the command prompt gives us this:

OK
at#UD
DIAG <2A4D3263 0=10>
DIAG <2A4D3263 1=8 2=0 3=0>
DIAG <2A4D3263 10=10 11=0A 12=2D>
DIAG <2A4D3263 17=005D>
DIAG <2A4D3263 20=FF 22=0D65 24=7A7>
DIAG <2A4D3263 21=FF 23=0D65 25=7A7>
DIAG <2A4D3263 26=5460 34=5460>
DIAG <2A4D3263 27=7080 35=7080>
DIAG <2A4D3263 31=00 32=00 33=01>
DIAG <2A4D3263 40=1 41=07F 42=00 43=00>
DIAG <2A4D3263 44=3 45=07F>
DIAG <2A4D3263 50=2 51=2>
DIAG <2A4D3263 52=00000003 54=0>
DIAG <2A4D3263 53=00000000 55=0>
DIAG <2A4D3263 56=00000000 58=0000>
DIAG <2A4D3263 57=00000000 59=0000>
DIAG <2A4D3263 61=00>
DIAG <2A4D3263 60=51>
OK

Definitely not human readable. But, the Unimodem driver can decode it and create a report that is placed in the Windows modemlog. The problem is that in order for Unimodem to do this, the modem’s INF file must have the proper entries in it, and those entries must be added to the Windows registry when the INF file is read when the modem is installed.
 
The modemlog for Windows is located in c:\windows\modemlogs. The name of the logfile is the name of the modem, so for the LSI Winmodem in the example the log is c:\windows\modemlogs\ModemLog_LSI PCI-SV92EX Soft Modem.txt. When the modem is initialized during boot, and when the modem is dialed by Windows Dialing, this log is created and entries are placed in it and remain there when the call is hung up. When the modem is opened for a new dial, the log is deleted and a new log is created. This is why I used Hyperterminal for the example, rather than just accessing the com port.
 
Here is the modemlog output for a test dial into a modem bank using Hyperterminal:

10-23-2014 00:57:21.029 - File: C:\Windows\system32\tapisrv.dll, Version 6.1.7601   
10-23-2014 00:57:21.029 - File: C:\Windows\system32\unimdm.tsp, Version 6.1.7601   
10-23-2014 00:57:21.029 - File: C:\Windows\system32\unimdmat.dll, Version 6.1.7601   
10-23-2014 00:57:21.029 - File: C:\Windows\system32\uniplat.dll, Version 6.1.7600   
10-23-2014 00:57:21.029 - File: C:\Windows\system32\drivers\modem.sys, Version 6.1.7600   
10-23-2014 00:57:21.029 - File: C:\Windows\system32\modemui.dll, Version 6.1.7600   
10-23-2014 00:57:21.029 - File: C:\Windows\system32\mdminst.dll, Version 6.1.7600   
10-23-2014 00:57:21.029 - Modem type: LSI PCI-SV92EX Soft Modem
10-23-2014 00:57:21.029 - Modem inf path: oem114.inf
10-23-2014 00:57:21.029 - Modem inf section: LSI_PCI_EX
10-23-2014 00:57:21.029 - Matching hardware ID: pci\ven_11c1&dev_0630&subsys_063011c1
10-23-2014 00:57:21.154 - 115200,8,N,1, ctsfl=1, rtsctl=2
10-23-2014 00:57:21.154 - Initializing modem.
10-23-2014 00:57:21.169 - Send: AT
10-23-2014 00:57:21.169 - Recv: AT
10-23-2014 00:57:21.169 - Command Echo
10-23-2014 00:57:21.169 - Recv: OK
10-23-2014 00:57:21.169 - Interpreted response: OK
10-23-2014 00:57:21.185 - Send: AT &F E0 &C1 &D2 V1 S0=0\V1
10-23-2014 00:57:21.185 - Recv: AT &F E0 &C1 &D2 V1 S0=0\V1
10-23-2014 00:57:21.185 - Command Echo
10-23-2014 00:57:21.200 - Recv: OK
10-23-2014 00:57:21.200 - Interpreted response: OK
10-23-2014 00:57:21.216 - Send: ATS7=60S30=0L0M1\N3%C1&K3N1\J1X4
10-23-2014 00:57:21.232 - Recv: OK
10-23-2014 00:57:21.232 - Interpreted response: OK
10-23-2014 00:57:21.232 - 115200,8,N,1, ctsfl=1, rtsctl=2
10-23-2014 00:57:21.232 - Initializing modem.
10-23-2014 00:57:21.247 - Send: AT
10-23-2014 00:57:21.247 - Recv: OK
10-23-2014 00:57:21.247 - Interpreted response: OK
10-23-2014 00:57:21.263 - Send: AT &F E0 &C1 &D2 V1 S0=0\V1
10-23-2014 00:57:21.263 - Recv: OK
10-23-2014 00:57:21.263 - Interpreted response: OK
10-23-2014 00:57:21.278 - Send: ATS7=60S30=0L0M1\N3%C1&K3N1\J1X4
10-23-2014 00:57:21.278 - Recv: OK
10-23-2014 00:57:21.278 - Interpreted response: OK
10-23-2014 00:57:21.278 - Dialing.
10-23-2014 00:57:21.294 - Send: ATDT#,##########
10-23-2014 00:58:01.884 - Recv: CONNECT 28800 V44
10-23-2014 00:58:01.884 - Interpreted response: Connect
10-23-2014 00:58:01.884 - Connection established at 28800bps.
10-23-2014 00:58:01.884 - Error-control on.
10-23-2014 00:58:01.884 - Data compression on.
10-23-2014 00:58:31.895 - Read: Total: 93, Per/Sec: 1, Written: Total: 0, Per/Sec: 0
10-23-2014 00:58:40.335 - CD dropped--Remote modem hung up. ModemStatus=00000030
10-23-2014 00:58:40.335 - Hanging up the modem.
10-23-2014 00:58:41.349 - Timed out waiting for response from modem
10-23-2014 00:58:41.364 - Send: ATH E1
10-23-2014 00:58:41.364 - Recv: OK
10-23-2014 00:58:41.364 - Interpreted response: OK
10-23-2014 00:58:41.364 - Session Statistics:
10-23-2014 00:58:41.364 -                Reads : 114 bytes
10-23-2014 00:58:41.364 -                Writes: 0 bytes

Notice, though, that the Unimodem diagnostic output it NOT included. This is because the computer will not issue the Diagnostics command with just Hyperterminal. Instead we need to use Dialup Networking to get the diagnostics command to be issued and the output placed in the modemlog. We also may need to modify the modem INF file and the Registry.
 
With this example modem, it uses an INF file that is included in Windows 7. Unfortunately, this INF file is missing the entries that activate the Unimodem Diagnostics. This is a very common but very strange problem with modems. Microsoft released the Unimode Diagnostics standard in 1998. Most if not all modems manufactured after that date include support and output for the Unimodem Diagnostics command AT#UD. But the strange thing is that most of the INF files that come with these modems do NOT include the entries needed to actually make use of Unimodem Diagnostics.
 
What is particularly galling is that INF files for modems that are supported under 64bit Windows had to be rewritten to support 64bit Windows. For winmodems that came with 32 bit drivers, the 32 bit driver also had to be rewritten to work under 64bit Windows. So, I do not understand why Unimodem Diagnostics entries were not added to these INF files – particularly for ones distributed with Windows and rewritten by Microsoft!
 
Fortunately, we can fix this. Here are the steps involved for the LSI SV92EX PCI Express softmodem. Note that this procedure is quite a bit more involved than the simple INF edit I outlined in my Modem INF Edit article. This is because unlike the example modem in that article – which never had 64bit Windows 7 support – the driver for the LSI SV92EX has been distributed with Windows 7. In fact 2 versions of this driver came with Windows 7 – the original Agrere Systems driver and the LSI driver distributed with Windows Update.
 
1) Identify the INF file used – the modemlog shows it as:

Modem type: LSI PCI-SV92EX Soft Modem
Modem inf path: oem114.inf
Modem inf section: LSI_PCI_EX

To confirm this, open regedit and do a search for the exact modem name. This will be in the Registry in several places, but one location has all of the prameters. On my test machine it was HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E96D-E325-11CE-BFC1-08002BE10318}\0000. One of the params is “InfPath” and in that is the name of the actual INF file. These INF files are in c:\Windows\inf.
 
2) The next step is to edit this INF file. To do this right click on Notepad, select Run As Administrator, browse to the file and open it then make the following additional entries in the section with entries starting with HKR, Responses:

HKR, Responses, "DIAG ", 1, 9e, 00, 00,00,00,00, 00,00,00,00
HKR, Responses, "OK", 1, 00, 00, 00,00,00,00, 00,00,00,00

Also edit the Properties key if necessary by setting bit 11 of the 6th doubleword to 1, as in the following example.
 
Original:

HKR,, Properties, 1, C0,01,00,00, ff,00,00,00, ff,00,00,00, 07,00,00,00, 0f,00,00,00,
 97,03,00,00, 00,C2,01,00, C0,DA,00,00

Modified:

HKR,, Properties, 1, C0,01,00,00, ff,00,00,00, ff,00,00,00, 07,00,00,00, 0f,00,00,00,
 97,0b,00,00, 00,C2,01,00, C0,DA,00,00

In the original key the 1st doubleword is “C0,01,00,00”, and the 6th is “97,03,00,00”.
 
Bit 11 is identified by converting the second hex-digit pair to a binary value. If bit 11 is not 1, change it to 1, and reconvert the binary value to hexadecimal.

                97,03,00,00  
                   ^^
                0000 0111
                     ^
                    bit 11

The doubleword is xx,  xx,  xx,  xx,  xx,  xx,   xx,    xx     and the bit numbers are
                  0/1  2/3  4/5  6/7  8/9  10/11 12/13  14/15

A handy website that you can use to do these calculations is http://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html
 
3) Save the changed INF and delete the oem114.pnf file in c:\windows\inf. Then in Windows 7, go to the modem in Control Panel, Modems, and delete it. Then go to c:\windows\system32\driverstore, rename the INFCACHE.1, infstor.dat and infstrng.dat files, and restart machine and it will force Windows to rebuild the driver database. Then Add modem again and allow it to autodetect and reinstall the modem. (if needed)
 
Under Windows 7, particularly with Plug and Play devices, Microsoft changed where drivers and INF files are stored (from all previous Windows versions including Vista) to DriverStore. Finding where the modem driver is located is quite tricky – in our example, it happens to be located in c:\windows\system32\DriverStore\FileRepository\lsismv64.inf_amd64_neutral_1f436a72ae6dada9 – but, the INF file with the missing defines is NOT there! I ran “driverquery” at the command line and it gave me a name of AGERESoftMod as a loaded driver, so I was able to guess from that. (since that was the name of the modem before Windows Updates updated the driver) Looking at the setupapi.app.log in c:\windows\inf can also sometimes help. There is also a program available, http://www.drivermax.com/, which purports to be able to handle up through Windows 8 and produce a report of drivers in the system. This may be of use.
 
The change is similar to how it’s done under under Windows XP, on that OS the file to rename is drvdata.bin and drvidx.bin and they are located in c:\windows\inf, then reboot.
 
Under Windows 8 (and later), a lot of things have changed. The Microsoft-supplied PnP INF files don’t appear to exist anymore. (User-installed INF files still seem to work the same way as before) Instead, during installation, after probing for PnP devices the data for discovered devices is read directly into the Registry, apparently from a database %systemroot%\system32\config\DRIVERS database file into the registry keys [HKEY_LOCAL_MACHINE\DRIVERS] and [HKEY_LOCAL_MACHINE\DRIVERS\DriverDatabase]. These keys in the Registry will have to be modified directly with the next instructions.
 
Under Windows 7 64bit when a modem is installed the INF file entries that are saved in the DriverStore repository are stuck into a Registry key. After deleting and re-adding the modem the OLD INF entries may still be present in the Registry, even if the driver database is rebuilt. So, we need to verify 2 Registry keys and if needed, modify them to sync them up to what the oem114.inf file is now saying is supposed to be there.
 
The first key is down in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\, it is a unique Registry key, then under that 0000 and under that key is a Properties key for the modem. To find the specific key for your machine, just search the Registry for the name of the modem – in this case “92EX” will do – and you will find it. The Properties key must match the Properties key you modified in the oem114.inf file. You will need to continue searching the Registry for all instances of the modem name “92EX” as there are several other instances where you will find Properties keys that need to be modified.
 
When that is done the next key is located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Unimodem\DeviceSpecific\LSI PCI-SV92EX Soft Modem::LSI::LSI\Responses. This key lists ALL of the response codes for the modem. The 2 additional codes must be added as binary values. You will be able to see in this key how the other codes have been entered.
 
4) Step four is most important, you must reboot the system. Otherwise the registry changes will not be picked up by the operating system.
 
After these changes are made, and the modem is reinstalled, the modemlog will produce a list of correctly parsed DIAG responses together with a decoded diagnostic report when running Dialup Networking. Here is the report from this LSI Winmodem, the same call as before:

10-23-2014 20:51:51.011 - File: C:\Windows\system32\tapisrv.dll, Version 6.1.7601   
10-23-2014 20:51:51.011 - File: C:\Windows\system32\unimdm.tsp, Version 6.1.7601   
10-23-2014 20:51:51.011 - File: C:\Windows\system32\unimdmat.dll, Version 6.1.7601   
10-23-2014 20:51:51.011 - File: C:\Windows\system32\uniplat.dll, Version 6.1.7600   
10-23-2014 20:51:51.011 - File: C:\Windows\system32\drivers\modem.sys, Version 6.1.7600   
10-23-2014 20:51:51.011 - File: C:\Windows\system32\modemui.dll, Version 6.1.7600   
10-23-2014 20:51:51.011 - File: C:\Windows\system32\mdminst.dll, Version 6.1.7600   
10-23-2014 20:51:51.011 - Modem type: LSI PCI-SV92EX Soft Modem
10-23-2014 20:51:51.011 - Modem inf path: oem114.inf
10-23-2014 20:51:51.011 - Modem inf section: LSI_PCI_EX
10-23-2014 20:51:51.011 - Matching hardware ID: pci\ven_11c1&dev_0630&subsys_063011c1
10-23-2014 20:51:51.135 - 115200,8,N,1, ctsfl=1, rtsctl=2
10-23-2014 20:51:51.135 - Initializing modem.
10-23-2014 20:51:51.151 - Send: AT
10-23-2014 20:51:51.151 - Recv: AT
10-23-2014 20:51:51.151 - Command Echo
10-23-2014 20:51:51.151 - Recv: OK
10-23-2014 20:51:51.151 - Interpreted response: OK
10-23-2014 20:51:51.167 - Send: AT &F E0 &C1 &D2 V1 S0=0\V1
10-23-2014 20:51:51.167 - Recv: AT &F E0 &C1 &D2 V1 S0=0\V1
10-23-2014 20:51:51.167 - Command Echo
10-23-2014 20:51:51.182 - Recv: OK
10-23-2014 20:51:51.182 - Interpreted response: OK
10-23-2014 20:51:51.198 - Send: ATS7=60S30=0L0M1\N3%C1&K3N1\J1X4
10-23-2014 20:51:51.213 - Recv: OK
10-23-2014 20:51:51.213 - Interpreted response: OK
10-23-2014 20:51:51.213 - Waiting for a call.
10-23-2014 20:51:51.229 - Send: ATS0=0
10-23-2014 20:51:51.229 - Recv: OK
10-23-2014 20:51:51.229 - Interpreted response: OK
10-23-2014 20:51:51.229 - 115200,8,N,1, ctsfl=1, rtsctl=2
10-23-2014 20:51:51.229 - Initializing modem.
10-23-2014 20:51:51.245 - Send: AT
10-23-2014 20:51:51.245 - Recv: OK
10-23-2014 20:51:51.245 - Interpreted response: OK
10-23-2014 20:51:51.260 - Send: AT &F E0 &C1 &D2 V1 S0=0\V1
10-23-2014 20:51:51.276 - Recv: OK
10-23-2014 20:51:51.276 - Interpreted response: OK
10-23-2014 20:51:51.291 - Send: ATS7=60S30=0L0M1\N3%C1&K3N1\J1X4
10-23-2014 20:51:51.291 - Recv: OK
10-23-2014 20:51:51.291 - Interpreted response: OK
10-23-2014 20:51:51.291 - Dialing.
10-23-2014 20:51:51.307 - Send: ATDT#,##########
10-23-2014 20:52:32.076 - Recv: CONNECT 28800 V44
10-23-2014 20:52:32.076 - Interpreted response: Connect
10-23-2014 20:52:32.076 - Connection established at 28800bps.
10-23-2014 20:52:32.076 - Error-control on.
10-23-2014 20:52:32.076 - Data compression on.
10-23-2014 20:52:33.282 - Hanging up the modem.
10-23-2014 20:52:33.282 - Hardware hangup by lowering DTR.
10-23-2014 20:52:35.762 - Detected CD dropped from lowering DTR
10-23-2014 20:52:35.762 - Recv: NO CARRIER
10-23-2014 20:52:35.762 - Interpreted response: No Carrier
10-23-2014 20:52:36.776 - Timed out waiting for response from modem
10-23-2014 20:52:36.792 - Send: ATH E1
10-23-2014 20:52:36.792 - Recv: OK
10-23-2014 20:52:36.792 - Interpreted response: OK
10-23-2014 20:52:36.807 - Send: at#ud
10-23-2014 20:52:36.823 - Command Echo
10-23-2014 20:52:36.823 - Recv: 
10-23-2014 20:52:36.823 - Interpreted response: Informative
10-23-2014 20:52:36.823 - Recv: 
10-23-2014 20:52:36.823 - Interpreted response: Informative
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 0=10>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 1=8 2=0 3=0>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 10=10 11=0A 12=2D>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 17=005B>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 20=FF 22=0D65 24=7A7>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 21=FF 23=0D65 25=7A7>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 26=5460 34=5460>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 27=7080 35=7080>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 31=00 32=00 33=00>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 40=1 41=A80 42=00 43=00>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 44=3 45=A80>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 50=2 51=2>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 52=0000014C 54=0>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 53=00000131 55=0>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 56=00000000 58=0000>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 57=00000000 59=0000>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 61=00>
10-23-2014 20:52:36.823 - Recv: DIAG 
10-23-2014 20:52:36.823 - Interpreted response: Diagnostic Info
10-23-2014 20:52:36.823 - Recv: <2A4D3263 60=20>
10-23-2014 20:52:36.823 - Recv: OK
10-23-2014 20:52:36.823 - Interpreted response: OK
10-23-2014 20:52:36.823 - Diagnostics
10-23-2014 20:52:36.823 - Modem Diagnostics:
10-23-2014 20:52:36.823 - Connect Response: ..CONNECT 28800 V44..
10-23-2014 20:52:36.823 - Version 1.0
10-23-2014 20:52:36.823 - Call Setup Result: Data Calling signal detected
10-23-2014 20:52:36.823 - Multi-media mode: Data Only
10-23-2014 20:52:36.823 - DTE-DCE interface mode: Async data
10-23-2014 20:52:36.823 - Received signal power level (in -dBm): 16
10-23-2014 20:52:36.823 - Transmit signal power level (in -dBm): 10
10-23-2014 20:52:36.823 - Estimated noise level (in -dBm): 45
10-23-2014 20:52:36.823 - Round Trip delay: 91 ms
10-23-2014 20:52:36.823 - Don't know to format (0x00000020, 0x000000ff) for tag 0x2a4d3263
10-23-2014 20:52:36.823 - Transmit Carrier symbol rate: 3429
10-23-2014 20:52:36.823 - Transmit Carrier frequency: 1959
10-23-2014 20:52:36.823 - Don't know to format (0x00000021, 0x000000ff) for tag 0x2a4d3263
10-23-2014 20:52:36.823 - Receive Carrier symbol rate: 3429
10-23-2014 20:52:36.823 - Receive Carrier frequency: 1959
10-23-2014 20:52:36.823 - Initial transmit carrier data rate: 21600
10-23-2014 20:52:36.823 - Final transmit carrier rate: 21600
10-23-2014 20:52:36.823 - Initial receive carrier data rate: 28800
10-23-2014 20:52:36.823 - Final receive carrier rate: 28800
10-23-2014 20:52:36.823 - Carrier Rate re-negotiation event count: 0
10-23-2014 20:52:36.823 - Carrier Retrains requested: 0
10-23-2014 20:52:36.823 - Carrier Retrain requests granted: 0
10-23-2014 20:52:36.823 - Protocol Negotiation Result: V.42 LAPM
10-23-2014 20:52:36.823 - Error control frame size: 2688
10-23-2014 20:52:36.823 - Error control link timeouts: 0
10-23-2014 20:52:36.823 - Error control link NAKs: 0
10-23-2014 20:52:36.823 - Don't know to format (0x00000044, 0x00000003) for tag 0x2a4d3263
10-23-2014 20:52:36.823 - Compression dictionary size: 2688
10-23-2014 20:52:36.823 - Transmit flow control: V.24 ckt 106/133
10-23-2014 20:52:36.823 - Receive flow control: V.24 ckt 106/133
10-23-2014 20:52:36.823 - Transmit characters sent from DTE: 332
10-23-2014 20:52:36.823 - Transmit characters lost (data overrun errors from DTE): 0
10-23-2014 20:52:36.823 - Received characters sent to DTE: 305
10-23-2014 20:52:36.823 - Received characters lost (data overrun errors to DTE): 0
10-23-2014 20:52:36.839 - Transmit Frame count: 0
10-23-2014 20:52:36.839 - Transmit Frame error count: 0
10-23-2014 20:52:36.839 - Received Frame count: 0
10-23-2014 20:52:36.839 - Received Frame error count: 0
10-23-2014 20:52:36.839 - Call Waiting event count: 0
10-23-2014 20:52:36.839 - Termination Cause: CCT108 Turned Off
10-23-2014 20:52:36.839 - 115200,8,N,1, ctsfl=1, rtsctl=2
10-23-2014 20:52:36.839 - Initializing modem.
10-23-2014 20:52:36.854 - Send: AT
10-23-2014 20:52:36.854 - Command Echo
10-23-2014 20:52:36.854 - Recv: OK
10-23-2014 20:52:36.854 - Interpreted response: OK
10-23-2014 20:52:36.870 - Send: AT &F E0 &C1 &D2 V1 S0=0\V1
10-23-2014 20:52:36.870 - Command Echo
10-23-2014 20:52:36.885 - Recv: OK
10-23-2014 20:52:36.885 - Interpreted response: OK
10-23-2014 20:52:36.901 - Send: ATS7=60S30=0L0M1\N3%C1&K3N1\J1X4
10-23-2014 20:52:36.901 - Recv: OK
10-23-2014 20:52:36.901 - Interpreted response: OK
10-23-2014 20:52:36.901 - Waiting for a call.
10-23-2014 20:52:36.917 - Send: ATS0=0
10-23-2014 20:52:36.932 - Recv: OK
10-23-2014 20:52:36.932 - Interpreted response: OK
10-23-2014 20:52:36.932 - Session Statistics:
10-23-2014 20:52:36.932 -                Reads : 55 bytes
10-23-2014 20:52:36.932 -                Writes: 0 bytes

Note that the Unimodem Diagnostics report begins after the CONNECT 28800 where it says Version 1.0. Now you can see the additional Received signal power level and other power levels present in the log.
 
You will notice several “Don’t know to format” entries in the log. These are vendor-specific additions
to Unimodem Diagnostics by LSI that Microsoft does not know how to parse.
 
Decoding Unimodem/V Diagnostic output manually
 
For diagnostic-reporting modems, the ATi11 command is the human-readable output, while the AT#UD command is for the Unimodem driver to produce diagnostic reports that are human-readable in the logs. However, some modems might not support the human-readable output from ATi11 but do support the output for Unimodem.
 
With these modems if your unable to get the INF file updated with the correct entries, you can also decode the diagnostic output manually. The program that can do this was written by a Russian programmer and is still available from FTP servers in Russia, here are 2 locations (the first location is an older version of the program):
 
ftp://ftp.atnet.ru/pub/drivers/modem/Tools/decoder’s/ud-1101.zip
ftp://ftp2.nix.ru/download/drivers/only_from_www.nix.ru/communication/idc/soft/ud-1014.zip
 
To use, just go into your terminal program, issue AT#UD and copy the output to the clipboard, then run the Windows version of the diagnostic program.
 
CallerID Info
 
Whiel CallerID is not, strictly speaking, line quality diagnostics, it is a form of diagnosis and you might want to get it to work properly. Just like Unimodem Diagnostics, many modems that support Caller ID do not have correct INF files, so the TAPI system in Windows cannot get this data from the modem. You may wish to add in additional entries to the INF file for caller ID while your fixing Unimodem Diagnostics.
 
The 92EX modem, like many modems, supports caller-ID but the Microsoft-supplied INF file does not contain the entries for it. This will cause problems with TAPI programs like the free Call Trace program from http://www.digitalroom.net/index2.html or YAC from http://sunflowerhead.com/software/yac/ or Phonetray Free version 1.29 (available on many archive sites like http://phonetray-free.en.uptodown.com/). These entries are listed here and they are:

[CID]
HKR, EnableCallerID,1,, "AT#CID=1"
HKR,,CallerIDOutSide,, "O"
HKR,,CallerIDPrivate,, "P"
HKR, Responses, "DATE = ", 1,93,00,00,00,00,00,00,00,00,00
HKR, Responses, "TIME = ", 1,94,00,00,00,00,00,00,00,00,00
HKR, Responses, "NAME = ", 1,96,00,00,00,00,00,00,00,00,00
HKR, Responses, "NMBR = ", 1,95,00,00,00,00,00,00,00,00,00
HKR, Responses, "MESG = ", 1,97,00,00,00,00,00,00,00,00,00

The CID keyword will need to be added to the AddReg= line in the modem’s INF file that is used to load the data into the Registry. If your working with a different modem the lines MAY exist but sometimes they have a bug, where the string is ‘NMBR=’ instead of ‘NMBR = ‘ Note that the AT string may be AT+VCID=1 and you may need to write the keys as such:

[CID]
HKR, EnableCallerID,1,, "AT+VCID=1"
HKR,,CallerIDOutSide,, "O"
HKR,,CallerIDPrivate,, "P"
HKR,,VariableTerminator,, 
HKR, Responses, "TYPE = ", 1,93,00,00,00,00,00,00,00,00,00
HKR, Responses, "DATE = ", 1,93,00,00,00,00,00,00,00,00,00
HKR, Responses, "TIME = ", 1,94,00,00,00,00,00,00,00,00,00
HKR, Responses, "NAME = ", 1,96,00,00,00,00,00,00,00,00,00
HKR, Responses, "NMBR = ", 1,95,00,00,00,00,00,00,00,00,00
HKR, Responses, "MESG = ", 1,97,00,00,00,00,00,00,00,00,00

You should issue the AT command in Hyperterminal then call the modem on a caller-ID line to see
what the modem output is to select the correct INF entries.