Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayAs a manufacturer of monitoring equipment, I know you need more than just RTUs and central-master devices. You also need practical guidance when something doesn't look right on your alarm screen.
Recently, I got a call from my primary client contact at a large transit agency. He was troubleshooting a puzzling issue.
They had NetGuardian RTUs in the field, a T/Mon master at the central hub, and alarms that just weren't showing up as expected.
Reviewing this email thread now will give you insights into fundamentals of remote alarm troubleshooting and the level of support you should expect from vendors in 2025 and beyond.
Let's begin.
The transit authority was running NetGuardian units at remote sites and polling them with T/Mon, our alarm master. The problem? Alarms triggered at the (NetGuardian) RTU never appeared in T/Mon's alarm windows.
My client confirmed a few key points:
Still, no alarms appeared. They were scratching their heads, and understandably so.
I got an email. My client wrote:
"A window/alarm group has been created as seen on the T/Mon grid. I can ping the NG from [T/Mon's network location]. IT states there are no firewall issues and has verified IP address handshake between the T/Mon and NG. However, I don't see alarms come in on the selected window. Your thoughts?"
This was a good problem report and a strong starting point. ICMP ping worked, the window was created, and IT cleared the firewall. It was time to check the finer points of T/Mon and NetGuardian configuration.
In a separate email, I explained:
"Is the NetGuardian sending active alarm(s) in its poll response? (verify that the NG web interface displays active alarms) ... and make sure that the 'Monitor Mode (Log)' checkbox is set for every alarm point for that NG in T/Mon... Those two things together is enough to cause the alarm to at least appear in Window/AlarmGroup 1: ALL ALARMS."
This highlighted a key step: Confirm that T/Mon is actively set to show alarms from those points.
Sometimes, the trouble comes down to alarm polarity settings. NetGuardian RTUs can treat an alarm as Normally Open or Normally Closed. T/Mon can also invert alarms.
As you can imagine, if both devices are reversing the same input, you might never see the alarm.
Here's what I wrote in another email:
"Yes, double-reversing on both NG and T/Mon might be doing something weird... I recommend disabling the reversal in T/Mon for reduced confusion while we do this troubleshooting."
If we simplify logic - turn off reversals in T/Mon and just trust the NetGuardian's native state - we can see if they start to appear. If not, then we consider other factors.
Right after sorting out the polarity, another crucial piece of the puzzle came into view: how T/Mon organizes alarms using device modules and alarm groups.
Each alarm point in T/Mon needs to be assigned to at least one alarm group (often called a "window") for it to appear onscreen. Without that final routing step, even a correctly detected alarm can remain hidden.
As Jordan from DPS Tech Support explained in an email:
"For each alarm of the device, there should be a 'window' or 'alarm group' option. If you don't have that option, my guess is it needs a new device module that has those features (provided free for any DPS RTU, and many third-party devices). You can just upload that under the Edit menu -> TMON -> Upload. Make sure that you set the alarm group for each one you wish to see in that window."
This simple insight often closes the loop. Once alarms are assigned to an alarm group, they become visible in T/Mon's interface in that group (and not just in the "ALL ALARMS" group that can often be crowded with alarm activity).
By uploading the right T/Mon Device Module, you gain the flexibility to bring alarms from many different types of devices (both made by DPS and other major manufacturers).
After we confirmed alarms at the RTU and checked fundamental T/Mon settings, I encouraged my client to explore some of T/Mon's built-in diagnostic tools.
These tools let you verify IP connectivity and run DCP poll tests right from the T/Mon interface - no need for an external laptop or third-party utilities.
In a previous email, I wrote:
"One of the nice diagnostic functions of the new 'Devices Tree' is an automatic ping test and DCP poll test."
By momentarily changing and restoring a device's IP address or DCP Device ID, T/Mon reveals red/green indicators that confirm whether ping and DCP polling are each active and healthy.
If both tests show green results, you know T/Mon is effectively communicating with the NetGuardian.
If alarms still don't appear, you can move on to more nuanced checks - like configurations and group assignments - knowing the network path itself is solid.
Fortunately, my client reported "green" positive results for both pings and DCP test polling.
At this point, everything in T/Mon looked correct based on the screenshots my client was sending me.
To be absolutely sure of where we were, I suggested simulating an alarm right at the RTU inputs:
"Having someone at site short alarm pins together OR remove all alarm input wires and setting alarm point(s) to 'Rev' (reverse polarity, aka Normally Closed) will cause alarms in NetGuardian... At that point, we'd be confident that the NG is sending alarms to T/Mon..."
If the NetGuardian's web interface shows the alarm, and T/Mon is actively polling, then T/Mon should pick it up. If T/Mon still doesn't display it, that narrows down the problem.
What made this scenario work out was a methodical approach:
Check Polling: Confirm T/Mon can ping and poll the NetGuardian. My client wrote:
"I can ping the NG from [site name]... IT states there are no firewall issues and has verified IP address handshake."
This meant the network path was open.
Check T/Mon Setup: Ensure that the alarm points are set to "Monitor Mode (Log)" so they appear in the default alarm window. As I said:
"If Monitor Mode (Log) is set for that alarm point, it will appear in the ALL ALARMS window."
Yes, we eventually solved the problem after gaining access to the RTU's web interface, but this wasn't just about making the alarms show up today.
This process helped the client learn more about how T/Mon and NetGuardian configurations work together. They learned:
They now know more about their system's inner workings, so the next time something looks off, they can zero in faster.
Working through these steps, my client didn't just solve a one-time problem - they learned how to handle similar issues in the future. This is a core part of the DPS approach: We don't just give you a product. We give you the product know-how to manage your system confidently.
When questions came up about Sync from Device/Sync to Device buttons, T/Mon "commit" steps, or the finer points of alarm configuration, we walked through them together.
My client sent emails, shared screenshots, and got timely feedback. Each exchange firmed up his understanding of how T/Mon polls devices, displays alarms, and routes data to different alarm groups.
Ultimately, this approach saves time and reduces frustration. Instead of guessing at solutions, you get clear steps and explanations directly from the people who build and support the equipment.
Over time, you develop the skills to tackle everyday challenges on your own, while still knowing we're just a call or email away if something unusual pops up.
When you buy from DPS, you don't just get some electronic box. You get the support that backs it up. We design the gear, we know how it works, and we don't leave you guessing when something doesn't behave as expected.
Consider whether your various vendors today often give you this level of troubleshooting guidance:
"If both [ping and DCP poll tests] are green, polling is good. Then, is there actually an active alarm on the NetGuardian?"
When you call me (or anyone in DPS Tech Support), we'll always go step-by-step until we reach the root of the issue. For a major transit authority that can't afford guesswork (or any of our clients worldwide), that level of support makes a difference every day.
If you've been frustrated by invisible alarms, puzzling polarity settings, or confusing alarm group assignments, let's talk. DPS can help you configure, test, and fine-tune your remote site monitoring system until every alarm that should appear actually does.
Give us a call at 559-454-1600 or email sales@dpstele.com to start a conversation.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
