The DPS Telecom Remote Site

Troubleshooting Guide

• 11 hot tips for solving tough problems

• Quickly diagnose and repair common remote site
problems with everyday tools
• Simple, step-by-step instructions to achieve solid
results

Version 1.0
Released December 14, 2004

www.dpstelecom.com • 1-800-622-3314
“We protect your network like your business depends on it”TM
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

© Copyright 2004 DPS Telecom

All rights reserved, including the right to reproduce this white paper or portions thereof in any form without written permis-
sion from DPS Telecom. For information, please write to DPS Telecom 4955 E. Yale Ave., Fresno, CA 93727-1523 • Call:
1-800-622-3314 • Email: info@dpstele.com

Printed in the U.S.A

2
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

How This Troubleshooting Guide Will Help You

Troubleshooting remote site equipment failures can be tedious and frustrating. It’s difficult to even know
where to start. Even a simple monitoring problem can have several possible causes. And how do you
know you’ve brought the right tools to even diagnose the problem?
This guide will help you cut through the tedium, the frustration, and the uncertainty of troubleshooting.
Step-by-step instructions will show you how to isolate and identify common equipment problems, using
the ordinary tools that are always in your toolbox.

Contents
Before You Start: What Tools Do You Need for Troubleshooting? . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Section 1: RTU Doesn’t Report Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Section 2: Wiring Problems — RTU Doesn’t Detect Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Section 3: RTU Sends False or Fluctuating Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Section 4: How to Test RS-232 Connections with a Screwdriver or Paper Clip . . . . . . . . . . . . . . . . 7
Section 5: How to Test 202, FSK and RS-422/485 Connections with a Butt Set. . . . . . . . . . . . . . . . 7
Section 6: Intermittent Polling on 202 and FSK Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Section 7: How to Identify Pinouts, with or without a Blinker Box . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Section 7a: Identify Pinouts with a Blinker Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Section 7b: Identify 202, FSK or RS-422/485 Pinouts with a Butt Set . . . . . . . . . . . . . . . . . . . . 9
Section 7c: Identify Serial Device Pinouts with a PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Section 8: Serial Remotes Can’t Connect to Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Section 9: IP Remotes Can’t Connect to LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Section 10: SNMP Remotes Don’t Report Alarms to SNMP Manager . . . . . . . . . . . . . . . . . . . . . . 11
Section 11: Dial-Up Remotes Can’t Dial Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

Before Your Start: What Tools Do You Need for Troubleshooting?

The goal of this guide is to provide you with the knowledge to troubleshoot remote site problems with-
out extra equipment. Most of the procedures described here can be performed with basic tools:

Screwdriver: Besides its ordinary uses, a screwdriver is also handy for

shorting wires and looping port pins.

Paper Clip: An ordinary paper clip can also be used for looping pins,
and it has the advantage that you can bend it into place and keep your
hands free.

Butt Set: A butt set can be connected to 202, FSK, RS-422 and RS-485
lines and be used as a rough-and-ready way to check data transmission.
If the line is carrying a signal, you’ll hear a series of tones in the ear-
piece.

You’ll need a few extra tools to perform some of the procedures described in this troubleshooting guide.
You might not carry these tools every day, but they’re still easily available:

Blinker Box: This small and cheap device will identify the transmit pins
on a port, which makes identifying mystery pinouts easy and quick.

VF Meter: Problems with 202 and FSK lines can often be fixed by
adjusting the decibel level, so a VF meter is a good thing to have. Some
voltmeters have built-in VF meter functions.

PC: A PC is an increasingly common troubleshooting tool. Most mod-

ern equipment can be accessed and controlled through a Telnet or soft-
ware interface.

4
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

Section 1: RTU Doesn’t Report Alarms

1. The first step to troubleshooting a failed RTU is to isolate the problem. There are three possible
reasons why an RTU isn’t reporting alarms:
a. The RTU isn’t working.
b. The RTU isn’t detecting alarms from the sensor.
c. The RTU can’t report alarms to the master.
2. Verify that the RTU has power.
a. Is the power LED on?
b. Make sure the power supply is working.
c. Check for burned-out fuses.
3. Verify that the RTU is detecting alarms.
a. Look for some kind of local indication that the RTU receiving data.
b. Does the RTU have LEDs that indicate that an alarm has been triggered?
c. Is there a software interface to the RTU that you can use to monitor locally?
d. If you can’t verify that the RTU is detecting an alarm, follow the troubleshooting instructions
in Section 2, “Wiring Problems,” page 6
4. Verify that the RTU can transmit data.
a. Check for an LED or a software interface that can give you a local indication that the RTU is
transmitting.
b. If you can’t verify that the RTU is transmitting, troubleshoot the RTU’s communication link to
the outside world. Depending on the type of RTU, follow the troubleshooting instructions in:
c. Section 8: “Serial Remotes Can’t Connect to Master,” page 10.
d. Section 9: “IP Remotes Can’t Connect to LAN,” page 10.
e. Section 11: “Dial-Up Remotes Can’t Dial Out,” page 11.

5
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

Section 2: Wiring Problems — RTU Doesn’t Detect Alarms

1. Make sure the alarm doesn’t have a qualification time.
2. When you’re troubleshooting wiring, the first question to ask is “Is the wiring new or old?”
3. If the wiring is new, check for pinched wires, broken wires, bad soldering and pinout errors.
4. If the wiring is old and it was working OK before, check if anything has changed. Have cables
been moved? Has there been bad weather? A lightning strike could have zapped a component.
Check for broken wires. Check the connectors and see if they’re loose or corroded.
5. Test the wiring: Take the sheathing off the cable and test it with a voltmeter. You should see
approximately the same voltage as the voltage powering the RTU.
What’s going on: Most RTU alarm connections are contact closure to ground. (But see Step 9 of this
section for an exception.) If an alarm point is not sending an alarm, the potential voltage in the wire is
approximately the same as the RTU’s power voltage, or possibly 1 to 1.5 volts less.
6. Trigger an alarm, and the voltage on the wire should go to zero. If it doesn’t you most likely have
a nicked wire or a broken sensor.
7. Check the continuity of the wire by shorting both ends. (Connect a voltmeter at one end of the
cable and short the other end; your voltmeter should show approximately zero ohms.)
8. You might also have a problem where the sensor is sending a ground, but the potential voltage
stays on the line. Test this by connecting a wire between the RTU’s ground pin and the pin pow-
ering the alarm. If the RTU then shows an alarm, the wire is defective.
9. If the wire is OK, but the RTU doesn’t sense an alarm, check to see if the alarm connection is actu-
ally a contact closure to battery. This kind of closure will have the same voltage as the potential
voltage on the wire, so no current will flow.

Section 3: RTU Sends False or Fluctuating Alarms

1. If the alarm fluctuates over a short period, check if the RTU is repeatedly rebooting.
What’s going on: Sometimes RTUs get locked into a cycle of recurring rebooting. Every time the RTU
reboots, all alarms are cleared. And then the RTU detects an alarm, reports it … and then reboots, start-
ing the cycle all over again.
2. If the alarm connector can be disengaged, remove it, and see if the alarm continues to fluctuate.
What’s going on: Loose connectors make off-and-on contact, creating the intermittent alarm. To
correct the problem, just screw the connector down tighter.
3. If the alarm still fluctuates, short the connector.
4. If the alarms stop when you short the connector, you’ve isolated the problem to the wiring. Check
the wiring, following the instructions in Section 2, “Wiring Problems,” on page 6.
Note: If the wiring is OK, but the sensor regularly fluctuates, you can fix the problem by setting an alarm
qualification time.
5. If the alarm fluctuates over a long period, you obviously don’t want to disconnect the alarm all
day. Move the alarm sensor wire to a different point, and see if the alarm continues to fluctuate.

6
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

Section 4: How to Test RS-232 Connections with a Screwdriver or

Paper Clip
1. Remove the cable from the near-end port of the problem connection. Take a paper clip or screw-
driver and loop the port’s TX pin (typically Pin 2 on RS-232 ports) to its RX pin (typically Pin 3
on RS-232 ports).
What’s going on: Creating a loop with a paper clip may seem silly, but it’s actually a great
troubleshooting tool. By looping the transmit and receive pins, you can test whether the ports and
connectors transmit and receive valid information. This is called a loopback test.
2. If the device will support it, make a Telnet or proxy connection to the near-end device.
3. Perform a loopback test: Type any character. You should see the character echoed on the screen.
Now remove the paper clip from the port and type a character. Without the loopback, you should
not see the character echoed.
4. If the result of the loopback test is exactly as described in Step 3, the port is physically OK. If the
result of the loopback test is different, the port may be defective.
5. The next step is to test the problem port’s cable.
6. Unplug the cable at the far end and loop the TX pin to the RX pin.
7. Make a Telnet or proxy connection to the near-end device and perform a loopback test.
8. If the cable fails the loopback test, you might need to replace the cable.
9. But before your replace the cable, double-check your pinouts. The near-end and far-end ports may
have identical pinouts, so using a straight-through cable will result in one TX pin being connect-
ed to another TX pin. You may need a null-modem adapter, which reverses the TX and RX signal.
10. If the cable is OK, the problem might be on the far-end port. To make sure, loop the far-end port’s
TX pin to its RX pin, make a Telnet connection to the far-end device and perform a loopback test
there.

Section 5: How to Test 202, FSK, and RS-422/RS-485

Connections with a Butt Set
1. Connect an ordinary butt set to the transmit leads of the problem port. Force an alarm and listen
for a series of tones.
What’s going on: If you connect a phone handset to a 202, FSK or RS-422/485 line, the digital data
signal will make audible sounds in the earpiece. This won’t tell you anything about the quality of the data
transmission … but it will tell you if there’s a signal on the line.
2. Do you hear any data coming from the transmit port?
3. If you don’t hear any data, you may have a cabling issue. Double-check the transmit port pinout.
4. If you do hear data on the transmit port, clip your butt set to the transmit leads of the receive port
and listen. If the receiver device is receiving information, it should also be transmitting
information.

7
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

5. Do you hear any data coming from the receive port?

6. If you don’t hear any data, double-check the RTU’s address.
7. If the address is OK, you may have a cabling issue. Double-check the receive port pinout.
8. If you believe that the pinouts are OK, and data is being transmitted at both ends, but the connec-
tion still isn’t working correctly, double-check the configuration of both the transmitter and
receiver device.

Section 6: Intermittent Polling on 202 and FSK Lines

1. Bad connections on FSK or 202 lines may be caused by decibel levels that are set too low or too
high. Connect a VF meter to the line and adjust the signal level.
2. If there is no level problem, the bad polling is most likely caused by a wiring problem.
3. When you’re troubleshooting wiring, the first question to ask is “Is the wiring new or old?”
4. If the wiring is new, check for pinched wires, broken wires, bad soldering and pinout errors.
5. If the wiring is old and it was working well before, check if anything has changed. Has anyone
moved anything? Has anyone cleaned up any wiring?

Section 7: How to Identify Pinouts, with or without a Blinker Box

If you have problems connecting devices together, it’s always a good idea to double-check your pinouts.
But sometimes the pinouts are unknown — either the pinout documentation is missing, or the port
doesn’t actually behave the way the documentation says it’s supposed to.
In those cases, you can identify the pinout with just a little bit of detective work.
Section 7a: Identify Pinouts with a Blinker Box
Testing pinouts is easier if you have a blinker box, a small electronic device that connects to a port and
lights an LED for each pin that transmits a signal.
1. Most blinker boxes only light LEDs for pins that transmit data. For RS-232 ports, these are TXD,
DTR and RTS. However, some blinker boxes will light green for transmit pins and red for idle and
receive pins.
2. Plug your blinker box into the near-end port of the problem connection and write down the status
of the LEDs.
3. Then plug the blinker box into the far-end port and double-check the LED status there.
4. Note: even with a blinker box, it will still take some detective work to identify for certain the var-
ious transmit pins — for example, if you have two transmit pins, which one’s DTR and which
one’s RTS? You can use trial and error to match each transmit pin with its corresponding receive
pin on the other side, such as RTS to CTS.
5. You may find that the near-end and far-end pinouts don’t agree. But now that you’ve identified the
real pinouts, you have a guide for rebuilding your cables.
Blinker boxes are convenient, but they’re not absolutely necessary. You can also identify pinouts with
more common tools.

8
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

Pin Signal Function

DCD RX TX DTR GND
1 DCD Data Carrier Detect
1 2 3 4 5 2 RX Receive Data
3 TX Transmit Data
4 DTR Data Terminal Ready
5 GND Ground
6 DSR Data Set Ready
7 RTS Request To Send
8 CTS Clear To Send
6 7 8 9 9 RI Ring Indicator
DSR RTS CTS RI

Figure 1. Standard PC COM port pinout.

Section 7b: Identify 202, FSK and RS-422/485 Pinouts with a Butt Set
If you’re working with a 202, FSK or RS-422/285 connection, you can use a butt set to identify transmit
pins.
1. Connect your butt set to the pin you want to identify.
2. If it’s a transmit pin, you’ll hear a series of tones in the earpiece.
3. For more information on testing ports with a butt set, see Section 5, “How to Test RS-422 and
RS-485 Connections with a Butt Set,” page 7.
Section 7c: Identify Serial Device Pinouts with a PC
If you’re having problems connecting to a serial device, you can use a PC HyperTerminal connection to
identify its pinouts.
1. Connect the COM port of your PC to the serial device’s port and try establishing a HyperTerminal
connection.
2. If you can connect via HyperTerminal, you know the device can connect to a standard PC COM
port.
3. Since all PC COM ports have the same standard pinout, you have a reference for identifying the
pinout of the serial device’s pinout. (See Figure 1 for a standard COM port pinout.)
4. Note: Your connection problems may also be caused by an incorrect baud rate. If you can suc-
cessfully connect via HyperTerminal, check your PC’s baud rate and apply it to all equipment that
connects to this device.
5. Note: Your serial device may require handshaking signals. If you can successfully connect via
Hyperterminal, check to make sure that all equipment that connects to your serial device supports
handshaking.
6. If you can’t connect via HyperTerminal, the serial device’s port may be broken.

9
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

Section 8: Serial Remotes Can’t Connect to Master

Troubleshooting a problem serial connection between a remote site and the NOC is not too different from
troubleshooting a local serial connection, as described in Section 4, “How to Test RS-232 Connections
with a Screwdriver or Paper Clip,” page 7.
Note: you need two techs for this: one at the NOC and another at the remote site.
1. First, verify that the device at the remote site is OK. At the remote site, unplug the serial cable to
the NOC and loop the port’s TX pin to its RX pin with a paper clip or screwdriver.
2. Make a Telnet or proxy connection to the problem device.
3. Perform a loopback test: Type any character. You should see the character echoed on the screen.
Now remove the paper clip from the port and type a character. Without the loopback, you should
not see the character echoed.
4. If the loopback test is successful, the port is physically OK. If the loopback test fails, the port may
be defective.
5. If the remote site port is OK, next test the connection between the remote site and the NOC. At the
NOC, unplug the serial cable from the remote site and loop the cable’s TX pin to the RX pin with
a paper clip or screwdriver.
6. At the remote site, perform a loopback test from your Telnet connection to the problem device.
7. If this loopback test fails, there’s a problem with the serial connection between the sites.
8. If the long-distance connection is OK, the problem might be on the master port. To make sure, loop
the master port’s TX pin to its RX pin, make a Telnet connection to the master and perform a loop-
back test there.

Section 9: IP Remotes Can’t Connect to LAN

1. Check the LAN link LEDs on both the remote and the master.
2. If the LEDs are lit, you can use a PC connected to the network to ping the network elements
between the remote site and the NOC.
3. Ping the remote, the gateway for the remote site, the gateway for the NOC, and the master.
4. If you can’t ping all four of those elements, you have an IP network problem. Ask your network
administrator for help.
5. If all pings are successful, unplug the remote and ping it again.
6. The ping should fail — but if it doesn’t, you have two devices with the same IP address. Check
the remote’s configuration and make sure it has a unique IP address.
Check for this likely cause: The Address Resolution Protocol (ARP) table of your router may need
to be flushed. The ARP table associates IP addresses to MAC addresses. If another device has used this
IP address — for example, if a turn-up tech used his laptop to verify the address — then the ARP table
might still associate the IP address with an old MAC address. If the ARP table doesn’t associate the
remote’s MAC address to its IP address, the router won’t let packets get through.

10
Remote Site Troubleshooting • DPS Telecom • 4955 East Yale Avenue, Fresno, CA 93727 • (800) 622-3314 • Fax (559) 454-1688 • www.dpstelecom.com

Section 10: SNMP Remote Doesn’t Report Alarms to the SNMP

Manager
Note: You need two techs for this procedure: one at the remote site and another at the NOC.
1. At the remote site, find out what kind of local indicator you have that the remote is receiving and
transmitting data — ideally this should be a software interface to monitor the device, but even a
blinking Ethernet port LED will do.
2. The NOC tech should send a GetRequest from the SNMP manager and the remote site tech should
watch the local indicators at his end.
3. If the remote site tech doesn’t see any communication happen, the GetRequest isn’t getting
through. Ping the SNMP manager from the remote site to verify the IP connection.
4. If the ping is unsuccessful, double-check that the SNMP remote has the correct IP address and port
for the SNMP manager and try again.
5. If the ping is still unsuccessful, you may have a network problem. Ask your network administra-
tor for help.
6. If the communication between the remote and the SNMP manager is OK, but no traps are getting
through to the manager, there may be a configuration problem.
7. Double-check the community strings databased on the SNMP remote. Community strings are case
sensitive, so watch out for case mismatches.
8. Make sure that the SNMP manager has compiled the correct MIB for the SNMP remote. If the
SNMP manager is using the wrong MIB, it will request invalid OIDs and the remote won’t
respond.

Section 11: Dial-Up Remotes Can’t Dial Out

1. The most reliable tool for troubleshooting a dial-up connection is a plain old phone. (Note: You
need two techs for this: one at the NOC and the other at the remote site.) Have the remote site tech
dial into the master with an ordinary telephone and listen:
2. Does it ring? If it doesn’t, check your phone line.
3. Does the master pick up?
4. Do you hear the modem? Or do you hear a “This call cannot be completed” message?
What’s going on: Remote sites often aren’t allowed to call long-distance. If the remote site and the
NOC are in different area codes, you may not be able to connect.
5. If the phone line is OK, try dialing into the master using a PC running HyperTerminal. The
master will try to resolve the HyperTerminal connection as if it were the remote dialing in to report
an alarm.
6. Watch the HyperTerminal window. Check if you get a connect message. Check if you’re connect-
ing at the correct baud rate.
7. If you still can’t connect, troubleshoot the master’s modem.

11
Alarm Monitoring Solutions from DPS Telecom
Alarm Monitoring Masters Remote Telemetry Units

NetGuardian 832A: RTU monitors 32 alarm points,

8 analog inputs, 8 control relays, 32 ping targets, 8
terminal server ports; reports to any SNMP
manager, T/Mon NOC or T/Mon LT

T/Mon NOC: Full-featured alarm master for up to 1

million alarm points. Features support for 25 proto-
cols, protocol mediation, alarm forwarding, pager
and e-mail alarm notification, Web Browser access,
multi-user access, standing alarm list, alarm history
logging.
NetGuardian 216: RTU monitors 16 alarm points, 2
analog inputs, 2 control relays, 1 terminal server
port; reports to any SNMP manager, T/Mon NOC or
T/Mon LT.

Remote Alarm Block 176N: Wire-wrap alarm block

monitors 176 alarm points, 4 controls; reports to any
SNMP manager, T/Mon NOC or T/Mon LT

T/Mon LT: Light capacity SNMP-only alarm master.

Supports SNMP Trap Processor software module,
up to 10 SNMP devices, and up to 20 DPS Telecom
remotes. Features pager and e-mail alarm notifica-
tion, Web Browser access, standing alarm list and NetGuardian 480: RTU monitors 80 alarm points, 4
alarm history logging. control relays; reports to any SNMP manager,
TL1 master, T/Mon NOC or T/Mon LT

www.dpstelecom.com
1-800-622-3314
DPS Telecom
“Your Partners in Network Alarm Monitoring”

“We protect your network like your business depends on it”