Monitoring Radio Strength (RSSI) in Railroads and Subways

In 2019, we finished our NetGuardian ADP, which is a specialized audio distribution panel to prioritize radio traffic in an underground railway system. Completing that project built confidence with this long-time DPS client, and we were approached to handle a different radio project.

The goal: Find areas of low radio RSSI in the rail network

This time, the goal was to map the radio strength across the network. This included both below-ground and above-ground sections.

Of course, to monitor radio levels, we needed a way to move throughout the rail system. There was one obvious way to do this: install a measurement device on board the track geometry car (TGC).

This was the proposed initial architecture for the radio level (RSSI) monitoring and mapping system. Although some details have changed (Wi-Fi became cell modems, for example), this diagram reflects the overall design and operation.

Track geometry cars are used worldwide by railroads to find problems before they grow. In that sense, their job is quite similar to the static remote site monitoring that DPS equipment performs most commonly.

Track geometry cars can measure:

• Rail wear (including with thermal imaging)
• Rail flaws (ultrasonic)
• Third rail gauge & height (for subway/metro systems)
• Flangeways
• Tunnel clearances (sometimes with a 3D point cloud)
• Video recordings of track sections for later review

In this case, the track geometry car was made by Plasser.

Monitoring and mapping the radio levels required a few devices working together

We would be given AC power and a small amount of rack space on board the Plasser track geometry car. Our job would be to ingest two primary inputs:

1. Geopositioning data from the built-in Plasser systems. This can be GPS above ground, but is based on known landmarks and distance traveled when underground.
2. Radio levels from a spectrum analyzer.

The NetGuardian RFL connects to a spectrum analyzer and the Plasser onboard systems. Some of the hardware has changed since this virtual prototype was proposed, but the basic design is the same.

These two devices give our NetGuardian logger all the data needed to construct a radio map, but our job isn't done yet.

The NetGuardian RTU platform is rugged and reliable, but it doesn't have tremendous long-term storage. It has a small web server to power its web browser interface, but it was never intended to build maps or other graphics from scratch.

The NetGuardian RFL device must send map data to a static companion device located next to a T/Mon master station. Initially, we thought we'd use point-to-point radio communication whenever the track geometry car was parked in a depot (it spends most nights parked in one location). As it turns out, we were able to get approval for cellular modems attached to both devices. This can theoretically present a security risk, but our client took extensive precautions to secure the connection.

The NetGuardian RFL has a straightforward algorithm for sending data to its companion unit. If we've had 3 minutes of uninterrupted wireless connectivity, we can assume that we're above ground and able to transmit. We then initiate a data transfer, which takes just a few minutes.

It's possible that we'll have to start over if we're only above ground for a few minutes, so the algorithm may evolve in a later firmware revision. It seems very possible that the NetGuardian could learn which time windows are long enough to complete a data transfer.

Once the NetGuardian RFL has sent geographic and radio signal strength (RSSI) data to its companion, the companion forwards that data to a T/Mon LNX unit for archiving and construction of a visual map.

We flew from California for the first field trial

DPS is an essential business serving telecom, power, rail, governments, and other essential organizations. As such, we never stopped working due to COVID. That said, we did see a dramatic drop in the number of clients willing to accept visitors for in-person field trials, installs, and trainings.

That's what made our visit in May 2021 so exciting. We were glad to be back in the swing of visiting DPS clients for field trials, as it's a tremendous "win-win". When you invite DPS for a field trial, you get a device that's a perfect fit for your network and your monitoring requirements. We, of course, end up with a new device that's actually useful for you and (perhaps with a few tweaks) others in your industry.

We took the required Track Safety class before beginning work

Compared with our previous visits to this rail client, we had an extra step to complete. Although we are extensively escorted by agency staff when visiting communication rooms, there's no specific safety certification required. For this project, every member of our four-person team needed a track safety certification to ride on the track geometry car.

My required hard hat during the track safety class. There's really nothing quite like a train rushing by at 15 inches past your face.

We arrived mid-week, then took a full-day course to learn the safety rules for working on and around the tracks. If you've never tucked yourself into a trackside niche with a train passing about 15 inches in front of your face, let me assure you that it's fairly thrilling. Barring an emergency situation, I don't expect to spend any time on the rails, but the class was a great experience regardless.

We started testing the RSSI mapping system on Monday

After a weekend in a fantastic city, we started bright and early on Monday morning. We visited a rail yard where the track geometry car was parked.

We tested our prototype device in a stationary but very real track geometry car during our visit. DPS engineer Bennie Johnson is here, evaluating whether the NetGuardian RFL was collecting data as expected.

Following our standard practice, we had created simulators for both the Plasser geolocation data and the radio levels from the spectrum analyzer. With weeks of testing under our belts, all that was left was fine-tuning when our system first encountered the actual working environment.

With this complete simulation setup at our headquarters in Fresno, CA, we worked out many kinks before our actual site visit. This saved our rail-agency client a massive amount of time - and delivered a finished product faster.

Because of our preparation, we finished on the first day within a few hours. That pattern repeated on Tuesday and Wednesday. In fact...

On Thursday, I visited another rail agency under the same umbrella

Everything was going so well, I was able to separate from the main team on Thursday to visit a related rail agency. I even rode on their trains to do it!

As I mentioned earlier, it's common to develop something that other DPS clients find useful. Seldom has it happened so quickly, though:

After discussing an upcoming remote monitoring upgrade with this client, I explained the basic premise of the NetGuardian RFL for monitoring RSSI. This second client immediately asked for more detail, creating a further opportunity to deploy and improve the NetGuardian RFL system.

What do you want DPS to build for you?

Do you work for a rail agency? I'd be happy to speak with you about the NetGuardian RFL for monitoring and mapping your radio signal strength (RSSI).

Maybe you work for a telco? A power utility? No matter what your industry, I'm interested in speaking with you about your remote monitoring (and control) requirement.

Give DPS a call at 559-454-1600 or email us at sales@dpstele.com to discuss your project. We can talk at length about your project goals, send you a proposed application diagram, and (eventually) visit you with a prototype and create your perfect-fit solution.

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