1018

Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

DPS is here to help.

1-800-693-0351

Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

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 Today

How DPS Integrated the Digitize System 3505 Prism LX via CAPS IV CAD Protocol

By Andrew Erickson

June 25, 2021

Share: 

Do you monitor multiplex, telegraph (McCullough) codes, digital dialer, polling radio, or serial input alarm signals? If you do, you might well be doing it with the Digitize System 3505 Prism LX (or its predecessor, named simply "System 3505").

T/Mon remote monitoring display of alarm lists, analog gauge clusters, and a geographic map view.
T/Mon can display alarms in a variety of views, but the data must first be captured via a specialized Device Module (template).

With the help of our T/Mon (central master station) engineering team, I just wrapped up an important project for a major DPS transportation client. Digitize devices were (and still are) used to monitor important door alarms in secure facilities. Let's take a quick look at the initial problem, the procedure for solving it, and where we've ended up...

A Digitize device upgrade required a T/Mon upgrade for alarm collection

In 2016, Digitize upgraded their System 3505. The same core functions remained, but the box received important new modernizations.

Digitize System 3505 device (pre-2016)
This older version of the Digitize System 3505 communicated with T/Mon via NetGuardian serial port (backhauled to T/Mon via IP).

Compared to the previous version, the Digitize System 3505 Prism LX includes:

  • Phone tethering, which allows you to get remote tech support by connecting your smartphone with a USB cable. A support technician from Digitize can then remotely access and troubleshoot your system.
  • Test mode, which hides nuisance alarms that match a user-specified filter. This way, you can test your setup without creating a distraction from any real alarm events.
  • "AlarmLan", which effectively links a network of Prism LX units together across a network.
  • ...(many other functions)...
  • LAN-based alarm reporting via CAPS IV CAD protocol.

That last one created the need for a new T/Mon function.

Digitize System 3505 Prism LX device
This upgraded new version of the Digitize System 3505, called the Prism LX, required a T/Mon update to re-enable monitoring support.

In the past, older Digitize devices used in our client's sites would report back to T/Mon via a NetGuardian serial port. That worked well for many years, but that serial port option was going away in the new Prism LX model.

Instead, LAN-based reporting would now be available - through the CAPS IV CAD protocol.

We flew to the NY/NJ area to visit our client and Digitize

As we like to do for all major projects, I hopped on a plane to visit the client site and our fellow manufacturer Digitize in person. This goes a long way toward making projects go smoothly.

We were actually already scheduled to be in town for another large radio/transit project, so it was very convenient for me to break away from the primary team and visit the people involved with the Digitize transition.

DPS Engineering created a new Device Module for the Prism LX

One part of recent T/Mon development I'm particularly proud of is Device Modules. For the first 20 years of T/Mon's existence as an alarm management platform, it used what was then a reasonable way to set up new polled RTUs:

You would create polling "Jobs" for each polling leg, then assign one or more RTUs to each leg. Often, a polling leg matched the topology of the system, often a serial or POTS/dial-up connection.

Today, in an IP-centric world, we think in terms of each device being independent. That's because, in a standard network star topology, each device is directly accessible via IP address.

That's where Device Modules come in. With the appropriate Device Module loaded on your T/Mon, you have a ready-built template that understands the fixed and customizable alarm events associated with that device. T/Mon understands which protocol to use to poll, listen, and respond to messages. All of that is contained in the Device Module.

Today, there are over 100 Device Modules available in T/Mon, including templates for:

  • Cisco
  • Cummins
  • Eltek
  • Fujitsu
  • Motorola
  • Nokia
  • RuggedCom
  • Siemens
  • And many more...

To make the new Digitize Prism LX communicate properly via IP with T/Mon, a new Device Module was needed. So, we set out to build that. The first step? We needed to understand the full breadth of the protocol specification.

The protocol specification was very thorough

Fortunately, it didn't take long to understand the core formatting of the CAPS IV CAD protocol used by the Prism LX.

At the Digitize offices in New Jersey, I got detailed information about this IP protocol. As it turns out, the data is very well structured. T/Mon would only need to parse essentially one format of key-value pairs.

Alarms from the Prism LX device would be parsed by description (ex. "Door #219 Open") and state ("Alarm" or "Clear"). T/Mon would then filter anything that was not a door alarm, because the team using T/Mon is solely focused on security.

We built the Device Module template within one week of work

Although it took some time to coordinate all of the teams involved across multiple companies, it didn't really take very long to code the T/Mon Device Module for the Prism LX.

T/Mon display of security alarm (door) data from Digitize Prism LX
Once we saw this successful display of Alarm and Clear messages, we knew that the new Device Module in T/Mon was complete. Everything was working perfectly.

We start from a core "skeleton" of a Module, then adjust it to suit each unique device. Digitize staff were very helpful in providing remote access to their office and piping alarm messages into the T/Mon to test the new module.

As always, a few iterations were inevitably required before we had something that appeared flawless.

In the first revision, we got stitched up by the Prism's use of ephemeral ports to send messages. After compensating for that, we successfully received messages from that device.

Beyond that first revision, there wasn't much else to do. We made a few slight tweaks. We cautiously reviewed the log files for Alarms and Clears, and we had both - in exactly the right proportions. The T/Mon was working.

T/Mon was then returned to our end-user client

After development was complete at the Digitize offices in New Jersey, we alerted our client that we would be returning the T/Mon for reinstallation in their production environment. It would then resume its monitoring of secure door alarms via telegraph lines.

Many T/Mons have been in use in many of this client's departments for decades. Over time, their network has inevitably evolved and improved. T/Mon has consistently evolved to keep up with that growth.

What do you need from your central alarm server? What kind of support do you want from your manufacturer?

This story is just one example of DPS custom-tailoring equipment to suit a specific user requirement. Do you expect that responsiveness from your suppliers?

What would you like DPS to make for you? Call me and tell me.

Give me a call at 559-454-1600 or email the office at sales@dpstele.com

Share: 
Andrew Erickson

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...