Preventing Downtime in Manufacturing with Predictive Maintenance

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.

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.

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.

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.

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.

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.