Remotely Monitor & Control Conductive Concrete (Snow Heating) at Bus Stops

What a trip! I just recently returned from a two-week-long romp to perform field trials for two DPS clients, both in the public-transit space: one large metro railway and one transit bus operator.

I previously described in detail my first stop: monitoring radio strength in underground subway tunnels on the East Coast.

After this 10-day segment ended, I spent 5 more days in an urban center in America's heartland. The goal? Monitor and remotely control snow-melt systems at downtown bus stops.

In this diagram, described in more detail below, I've proposed a proven solution for remotely monitoring and controlling conductive-concrete heating at any number of city-center bus stops. (See photo below showing the actual cabinet)

Our equipment will be a very important addition to this transit system, as several key problems must be solved...

The 3 Problems: Low heat output, blown fuses, temperature swings

As I knew from my prior phone calls, and I learned in more detail during my trip, the city agency (and their contractor) working on these bus stops had 3 primary problems to address:

1. The conductive concrete snow-melting system was designed using the 5-watts-per-square-foot standard, which is a specification intended for constant always-on operation. For selective on/off operation during snowy periods only (which saves electricity), the concrete must preheat for at least 10 hours prior to predicted snowfall. Currently, this requires a technician to visit every bus stop, open a locked cabinet, and press a button.
2. Fuse blocks were specified and installed instead of circuit breakers, so replacing blown fuses takes extra time and expense. Excessive current draw happens when concrete is warmer, as current draw is proportional to heat of the conductive concrete. Power is wasted. Fuses blow, shutting down heating operation to the affected zone - or an entire bus stop.
3. These cabinets can hit -20 F during the bitter cold of winter and 110 F during the heat of summer. Whatever monitoring box we install, it needs to survive the conditions.

The Goals: manual remote control, prompt alerts

To solve the problems about, we needed 3 primary elements in a NetGuardian or other RTU:

1. Remote ability to trigger a heating cycle. This could be either "continue heating until stopped" or a standard 10-hour duty cycle. This would need to be logically "OR'd" with the existing Snow Switch, as snow accumulation clearly should still trigger heating. Tying the RTU into an internet-based weather service to allow automatic pre-heating would be a dream, but manual control would be a great place to start.
2. Monitoring the current draw (amps) of the system. Tracking each circuit (10-27 per cabinet) separately would be great, but even a "total cabinet power draw" figure is way better than nothing at all. This will enable detection and remote deactivation of the system before a fuse blows and requires replacement.
3. An industrial temperature rating. At DPS, RTUs built for uncontrolled environments are commonly rated for -22 F to 158 F, while some can go even colder.

A Site Visit Uncovers All the Specifics

Of course, you don't know what you don't know. That's what made my recent site visit so important.

We had a general idea of the project before we arrived: remotely monitor and control snow-melt controllers at bus stops. We have past experience with snow-melt monitoring from an earlier project in the Midwest.

What we didn't know, however, was exactly what equipment was in each cabinet, how big the cabinets were, and the specific concerns of each person on the team. Most of the detail in the two lists above were things I learned during my visit.

Here's an example: We knew that we needed to remotely activate conductive concrete heating. What we didn't know until the visit was that the Snow Switch (model EUR-5A) has discrete inputs to trigger two different timing variants:

• Bridge pins 10 & 11 for "always-on" operation
• Bridge pins 21 & 22 to activate a 10-hour cycle based on knob setting (or bridge pins 10 & 12 force heater to remain off)

It's amazing what looking at screw-terminal labeling and Googling a quick user manual will teach you...

Ultimately, I learned enough to construct a detailed diagram (see above).

For clarity, I also annotated a photograph of the cabinet interior. The NetGuardian DIN and rCell modem were inserted digitally as a proposed solution:

In this augmented photo, the NetGuardian DIN and rCell wireless modem have been added to provide web-based remote monitoring and control for the EUR-5A Snow Switch.

The Proposed Solution: NetGuardian DIN & T/Mon

In its proposed form, this solution includes the following functions:

1. Control for one EUR-5A Snow Switch per site. For any multi-cabinet bus stops, the other cabinets do not have a Snow Switch. They are controlled by the Snow Switch in Cabinet #1.
2. LAN-based control/monitoring for snow-melting systems. The primary need is to remotely activate a heating cycle ahead of known snowfall.
3. Wireless communication between the RTUs at many different sites - including cabinets at the same site where we don't want to depend on existing, partially full conduit and pulling cables.
4. The ability for RTUs to monitor AC and DC current for different devices at each site.

Specifically, the following equipment will be used:

1. Our NetGuardian DIN RTUs, which will be used for controlling the snow-melt system via web interface or integration with a central master server (ex. DPS T/Mon device). The NetGuardians will also monitor the current (amps) being supplied in order to prevent the heating-circuit fuses from being overloaded.
2. Cellular modems to allow communication from each individual cabinet without having to run additional cables between them. Each cabinet will be its own logical NetGuardian device for current monitoring purposes, while only the NetGuardian in the main/first cabinet will need to control the site's single Snow Switch (EUR-5A).
3. AC and DC transducers that will allow the NetGuardian DINs to monitor the current being supplied throughout the system. The DINs will poll the transducers repeatedly via analog circuits and send the information over the cellular modems, where it can be saved to a history log file and viewed through the web interface.
4. (Optional) T/Mon, which is used as a central monitor/controller for many different RTUs. With the T/Mon, you can view the alarm states of all the NetGuardians at once in one single place - both in list and map/photo views.

Remote Monitoring & Control for Your Project

Whether or not you have conductive concrete, bus stops, or cold winters, I can help you with your remote monitoring and control project.

Just tell me what you're trying to accomplish. I've accumulated a good foundation of knowledge in my 15 years, and I can connect you with any DPS engineer as necessary to address your particular project needs.

We try to use off-the-shelf designs whenever possible. Sometimes, we'll take 90% off-the-shelf functions and add something new. That can be a new protocol, and new communication interface, or a modified physical form factor and mounting style. To start your project, just call DPS at 559-454-1600 or email me 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...