In the age of Amazon shopping, it's natural for you to expect everything to be deliverable to you within 48 hours (if not sooner).
But what does that mean for the business-oriented world of RTU purchasing?
Like most products, RTUs are available in a range of customization levels. If you want something totally off-the-shelf, there certainly are options that can ship out to you within one day.
If you happen to find an alarm remote that's both (1) ready to ship, (2) built by a proven manufacturer, and (3) a perfect fit for your network, go for it!
Unfortunately, you're unlikely to magically find a perfect-fit solution that's already boxed and ready to ship. There are simply too many different networks in the world. No RTU design can possibly be "just right" for any but a lucky few.
So, where does that leave you? In my work with DPS, we've settled on a lead time of 14 days or less as a good balance of speed vs. customization for our clients.
Advantages gained from a 14-day lead time:
Of course, good vendors can rush things along when you absolutely need it (DPS has crunched it down to 7 days when requested). This sometimes involves a rush fee, however, so it's always a good idea to plan your ordering in advance whenever possible.
I always recommend customization for my remote-monitoring clients when the situation is right.
High customization is valuable when:
Customizing an RTU design that's specific to you can be a tremendously rewarding experience. It's not just something you bought. You worked with your manufacturer to help design it.
It's a perfect fit for your network. It will serve you and your coworkers reliably for years to come.
Of course, customization of an RTU design necessarily involves extending the lead time at least 1-2 weeks.
When added to the 14-day built-to-order lead time described above, you can expect something like 30 days of total lead time from a capable manufacturer. This is true for new custom features that are not exceedingly complex and don't require extensive real-world testing.
For example, if I was taking two of my existing NetGuardian RTU designs and mashing up their feature sets, I'd be able to ship that to you without much additional delay. Both features set were field proven. I was just "repackaging" them together for you.
Remember that, whenever possible, you should take delivery of a single first article and hold a field trial.
If everything goes well, you can authorize manufacturing of the remaining units with a 14-day lead (at that point, the design is done and ready to build).
If something is wrong and the design must be changed, you'll be glad that you caught it early. Your manufacturer can then engineer a new revision.
I recently completed a great sequence of field trials for a long-time client in New York City. Although the total lead time was quite long, I was able to provide an amazing experience for that client. Telling you the story now should help you understand the amazing advantages of an extended development process.
We've had about 150 RTUs deployed in this client's network since the early 2000s. While we were in town doing a week of regional product training, we had a meeting with senior leadership.
They were wrestling with a legacy radio product that manages multiple inputs being fed into a radio. This product wasn't an RTU by any stretch of the imagination, but the thinking was that we could design them a new box that would handle the radio function and act as an RTU by remotely monitoring and controlling radio levels.
We'd eliminate the labor cost and wasted time required for technicians to visit a site and manually tune audio levels with a screwdriver. Everything would be accessible and controllable remotely via web interface.
We did extensive design work for several months at our HQ in California, then flew out to NYC in late September. Our plan, as usual, was to spend a week on-site trying to find flaws in our design.
The running joke at DPS is that Mondays are always terrible. Your dreams of a perfect field trial get shattered in ways you never imagined. Tuesdays are no picnic, either.
This is why we stay for a week. We need time to shatter our bad assumptions and refine our design.
We noted hardware changes (to be done back in California after we returned) and executed 2-3 firmware revisions each day. We'd phone home to the programmers, get a firmware file via email a few hours later, and test it out.
We returned to New York in November with brand new hardware. It was beautiful.
We had incorporated dual hot-swappable power cards. We knew our power-supply circuit was bulletproof, but there's nothing like redundancy to really nail reliability.
The web interface was reorganized to be easier to use. Working with our client's technicians taught us a lot about how this RTU + audio box would actually be used.
For "extra credit", we also built an oscilloscope right into the web interface, which allowed on-the-fly testing of all sorts of incoming audio signals. There were hundreds of potential uses for this feature, but the most important ones were the uses we couldn't anticipate.
Everything was going great, but we saw an opportunity to really hit it out of the park: automatic tuning.
In January, our hardware was solid. We added a resistor to some of the circuits to eliminate a little bit of cross-talk, but that was about it.
Our challenge in our third week of field trials (aside from fighting the cold weather in Brooklyn), was to dial in the auto-tune algorithm.
We had conducted testing back at HQ, but there's nothing like the real-world to stress your designs.
New tone and noise factors were confounding our tuning algorithm, causing unnecessary fluttering. It took several cycles to tune when it should really only take one.
Following our usual pattern, we made incremental improvements all week. By Friday, we made a final presentation to the senior leadership team.
The meeting went very well, and it was clear to both sides of the table that we had gotten the job done.
Between late September and the middle of January, we went from an off-target prototype to a perfect-fit auto-tuning RTU-audio hybrid box. The client was thrilled. We never could have delivered anything close to the quality we achieved without extensive field trials.
4 months is certainly a lot longer than the "2-Day Shipping" that's common in our modern retail world. After reading this story, I hope you can appreciate how - if you really want the perfect RTU - there's value in investing your time. You just need to start early and work with a manufacturer who will also invest with you.
As you now know, you have a huge spectrum of lead times available to you:
There's certainly no right choice here. You could make a justification for any of these options.
What I hope you take away from this discussion is an understanding that your required quality, not last-minute urgency, should drive your decision.
It's unfortunate when you have to choose something off-the-shelf because you're in a hurry. When you do that, you deny yourself an experience like the real-world example I described above.
I wish you the best of luck as you try to balance lead time vs. customization. If you have any questions, drop me a line. I'd love to chat with you about your RTU goals.
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 16 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
You need to see DPS gear in action. Get a live demo with our engineers.
Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
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