You need to see DPS gear in action. Get a live demo with our engineers.
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 Today
DPS equipment is frequently used in life-and-death scenarios, but few are so immediate as in aviation. When NetGuardians monitor telecom networks, it's possible that someone might not be able to dial 911. In instrument conditions (zero visibility), a malfunctioning ILS (Instrument Landing System) can quite literally send airplanes into mountains.
"Life and death importance" was the context that brought this particular project to my doorstep. It all started with a nonspecific request for information on my website:
"Hello, Interested in RTU and monitoring software. In preliminary research. I am familiar with Asentria SiteBoss 550 in a previous position. Thank you."
This message led to a long phone call, where we reviewed the goals of the project. As I noted during the call:
Working for a state government, this particular new client has had a long career in the industry since the mid 1990's. In the past, in another department, there used to be more staff than absolutely needed. In his new department, there are fewer people.
Where he used to work, Asentria equipment was being used for a statewide emergency radio network. It was based around SNMP for all of the tower sites. It was "like a network monitoring type tool".
This client had a system that "seems to be stuck in another era."
The ILS is inspected on foot with hand equipment regularly. Every 18 months, there's a flight check to confirm that the ILS is correct and can turn itself off when it's significantly wrong. If the gear is left in "Bypass Mode", it can't turn itself off. That potentially puts pilots at risk.
For this project, the site count would probably be around 40 sites. The client would have to decide which ones we want to monitor and which ones we don't.
After you deploy RTUs and a central master station for remote monitoring, your next step is to use it effectively by monitoring everything you can. That includes many standard items that aren't specific to, in this case, airports or aviation.
Important items to be monitored include:
According to my client here, "We're preliminary. We're just figuring out what we can do. The phone lines in a lot of places are gone. We can't repair cable because it's on an airfield, so it becomes beyond economical repair because it's not the local telco's responsibility."
He's working on this project for Q2. Other projects are ahead, but he wants to get the ball rolling ("this is the stuff I love to do").
We planned a conference call a few days from now. The installer-contractor might be on next call to share his perspective. Currently, it's ungainly to access the system remotely.
Here's what I wrote in my first proposal to this client:
Thank you again for contacting us regarding your upcoming project. Based on our conversation, I have prepared this proposal to include pricing for the T/Mon SLIM G2, the NetGuardian DIN, and accessory sensors.
By deploying the NetGuardian DIN, you will immediately gain the following benefits:
- The ability to collect 1200-baud 202 data from aeronautical equipment, then transmit the information to T/Mon for display, alerting, and history logging. This will bolster your case to demonstrate readiness to be a "monitored" airport that may be used as a bad-weather backup by pilots.
By deploying T/Mon, you will gain the following benefits:
- The ability to monitor up to 64 devices (including DPS NetGuardians) in a single, unified interface. Many users can connect simultaneously and navigate independently.
"At this point, DPS is the best solution we've come up with. It's a very reasonable price for the amount of equipment involved."
"I sent Ron the basic code that devices use. I wonder if it's a possibility for DPS RTU to run script in background and connect to actual code of equipment on site. It only needs to poll maybe once an hour. It would be the same method as over POTS but without POTS. The RTU is local."
(DPS co-founder Ron had a detailed conversation with him about technical methods of collecting alarms from 202). The client had proposed using the POTS connection locally as an option, but this would be delayed data compared to a real-time 202 method. I explained the DPS guarantee, even for custom work. We won't leave him hanging.
"Our timeline has most likely shifted to fall as we are working on a Airport WiFi and ADS-B solution for multiple sites."
Waiting for the project to get funded, my client did extensive bench testing to further ensure success:
"I now have a working RCSU on my test bench connected to a MK10 Outer Marker System via a simple 2 wire connection. I have bridged a 600ohm audio transformer into the circuit to record the FSK audio for review. The RCSU polling rate was changed to 1 sec. from what I think was a 600ms default. This was to make recordings in Audacity easier to read. The timing had no effect on the response."
"The polling address has a value of 0-7 for this test I set the value to 1 and then matched the radios address to 1 as well. Attached are the Audacity audio files from recording the FSK from each style of event we are interested in reporting."
In particular, the Audacity recording was very helpful for DPS Engineering to verify that the 202 modem was putting out the signals we expect.
That style of communications would account for approximately 25-30 of RTU's and equipment we plan to monitor.
Do you work with airport navigation systems like ILS and VOR? Do you need to monitor something different?
Whatever you need to monitor, I can help you sort it out. Everything I've described above is pulled from my project notse, so you can tell I'm quite thorough. I'll do the same when you tell me about your project.
Just call me at 559-454-1600. You can also send me a quick email at firstname.lastname@example.org