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 TodayDo 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").
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...
In 2016, Digitize upgraded their System 3505. The same core functions remained, but the box received important new modernizations.
Compared to the previous version, the Digitize System 3505 Prism LX includes:
That last one created the need for a new T/Mon function.
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.
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.
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:
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.
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.
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.
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.
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.
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
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...
