Across the manufacturing industry, there are dozens of monitoring solutions that can help identify and notify affected parties about issues with machinery, processes, and more. But imagine if these tools could identify issues before they occur? That’s predictive maintenance.

Please take a moment to complete the form below and gain instant access to this recorded webinar.
 cover page

Recorded Webinar

Preventing Downtime in Manufacturing with Predictive Maintenance

Jun 25, 2024 | Length: 37:00

Across the manufacturing industry, there are dozens of monitoring solutions that can help identify and notify affected parties about issues with machinery, processes, and more. But imagine if these tools could identify issues before they occur? That’s predictive maintenance.

In this recorded webinar, experts from National Control Devices (NCD) and Digi International discuss how manufacturers can use sensors and mesh technology to analyze and predict potential equipment failures to minimize costly downtime, improving reliability and productivity.

To learn more, visit the Digi XBee Ecosystem page, check out our RF modules, or check out our Digi XBee modules using the DigiMesh® protocol.

Connect with Digi

Want to learn more about how Digi can help you? Here are some next steps:


Follow-up Webinar Q&A 

In our recent webinar with National Control Devices, Quinn Jones of Digi had a lively discussion with Travis Elliott of NCD about the benefits of Digi XBee® DigiMesh® technology for predictive maintenance applications. See the insightful Q&A session below. If you have additional questions, be sure to reach out.

Moderator: Mitch Sinon, Senior Marketing Manager, Digi International


  • Travis Elliott, Chief Operating Officer at National Control Devices
  • Quinn Jones, Senior Product Manager of Digi International

You talked about multiple frequency support on the XBee modules with DigiMesh, which makes me wonder, do XBee modules have certifications for different countries?

Quinn: Yeah, that's a good question. So, we do certify our XBee modules for different countries, which is great for customers who don't want to do that. We have designated engineering resources that that's all they do is just focus on country certifications, which is a full-time job. And it's constantly evolving. We do take our modules through different country certifications, so that when you drop it in, you can use those certifications as part of your finished product certification.

I see you pull in raw data, and have great tools for data collection, but how do you transition from raw data to predictive maintenance? How do you differentiate between vibration as an indication of potential failure and a simple issue like a loose screw on a fitting near the object you're monitoring?

Travis: Yeah. So, NCD is a hardware manufacturer. And our goal is to provide this telemetry to our users. But from that point, our users will develop their own software and analytics to actually correlate those vibration readings over to possible issues. But you can actually look up some ISO standards for peak frequency detection that will tell you a possible problem based on the peak frequencies. And it's going to be in multipliers of run time. So, for instance, if you have an 800 hertz motor, you should be seeing your peak frequency at 800 hertz, but sometimes you may see that at 1600 hertz or 2400 hertz, or 3200 hertz, multipliers of that run speed. And based on a lot of the ISO standards and analytics that would be developed, you can determine possible faults, like bearing failure, misalignment, loose mounting, things like that. But just keep in mind, at NCD that's not necessarily our goal, to actually do that part. A lot of our partners who we work with actually do the analytics, and determine fault detection. We just get the telemetry there.

Must a node address another node specifically, or is there a form of publish/subscribe system?

Travis: I'm going to assume that that is based on the perspective of the sensor. So, the way that our sensors work by default is they're in broadcast mode. So, the sensor wakes up and it just sends out its telemetry. However, the sensors do have configuration for unicast, so, you can set the destination address of the sensors, and you would typically set that to one of the enterprise gateways. And then the mesh mapping can take place at that point, to actually go through repeaters and things of that nature. But by default, we ship it in broadcast. We find that for most customers, that works very well, and it keeps deployment very simple.

Regarding scalability on XBee modules, what is a typical size of a network, and how large can a DigiMesh network scale?

Quinn: I'll give a DigiMesh answer, kind of what we've seen, and then it would probably be good to get some feedback from Travis on what he's seen in the real world. So, a lot of this depends on your application, how much data you're sending, and then how frequently you need to communicate. So, we have customers running networks from handful of modules to hundreds of modules, just depending on their communication requirements.

One example that comes to mind is we have a large outdoor lighting application, that has over 500 nodes in a network. They don't communicate very frequently; once a day or a couple times a day. But you may want communication with their complete network in seconds, and obviously, that size of that network is going to be much smaller. So, it just depends on your application, but it can scale from some handful to hundreds. And Travis, what do you guys typically see with your products?

Travis: Yeah. Typically, I tell customers it's not necessarily about really the actual number of devices or the number of nodes. It really has more to do with bandwidth. So, if you're working with a vibration sensor that's, say, it's in raw data mode, and it's sending a significant amount of data, and there's a lot of those devices, then you may want to curb it back to maybe 50 nodes in that network. And then you can separate them with network IDs, to kind of keep things cleaner, where you might have one gateway managing this group of sensors in an installation, and a separate gateway managing this group.

That network ID kind of really acts like a SSID of a Wi-Fi network. You're just kind of separating them, and keeping them in two different networks. But if it comes to something like a temperature/humidity sensor, where you're not sending that much data, yeah, you could have hundreds of units operating in a facility, all coming back to the gateway. So, it really depends on bandwidth more than actual number of devices, from my experience.

Quinn: Yeah, makes sense.

Does NCD offer white labeling on the Enterprise series sensors?

Travis: Yeah, we sure do. And I touched on that briefly early in the presentation. Most of our customers do utilize our white labeling capabilities, and we actually do all of our branding in-house. So, it makes it really simple. If you send us your logo, we can just print that logo right on the top of the enclosure. And since we do it ourselves, quantity's not a big deal. You just need a couple of units for proof of concept, we're happy to white label for you.

Can NCD develop custom sensors?

Travis: Yeah, absolutely. Most of our large-scale clients come to us because of the broad offering of the Enterprise series. But typically, they'll find one or two little things that we don't currently offer that they need, and we end up custom developing that for them. And what we like to do is whenever we custom develop those products, we like to put it on the store for other people to purchase it as well. And that's actually been a big contributing factor with how fast we've grown the Enterprise line of products, up to 120 unique devices. Customers come in, they ask for something we don't currently offer, we work with them to develop that solution, and then we're able to offer it to everyone. So, yeah, that's very important to us, to do custom development with our customers.

Get Our White Paper
Learn about the differences between DigiMesh and Zigbee Mesh and how to choose the right protocol for your use case

Have a Question? Connect with a Digi Team Member Today!