How Will LPWAN Impact IoT?

On this IoT For All podcast episode, the senior team from CoreKinect (Assar Badri, CEO and Co-Founder; John Horn, President and Chief Strategy Officer; and Mitchel Kelley, Principal Engineer) discuss building custom hardware and how LPWAN will impact IoT.

The CoreKinect team explains the process of building custom IoT hardware and discusses how they manage the production of IoT products from engineering design through assembly and manufacturing. The team also shares roadblocks of the custom development process and explains when it makes sense for companies to build custom as opposed to buying off the shelf.

We discuss the hot topic of LPWAN and the impact it will have on IoT. The episode concludes with advice for companies when analyzing what hardware and software partners are best suited for their solutions.

If you’re interested in connecting with Assar, check out his LinkedIn!

About CoreKinect: CoreKinect is an innovative startup specializing in the development of hardware solutions for a wide range of customized products in IoT. From initial design down to the assembly line, we take care of it all. We are redefining the IoT space by creating products at market disrupting prices.

Key Question and Topics from this Episode:

(2:08) Introduction to CoreKinect

(2:57) What does it mean to build custom hardware for an IoT deployment? What does that process look like? 

(6:09) What is CoreKinect’s secret sauce that allows you to accelerate hardware development and time to market? 

(10:27) Insights into the software behind the hardware

(16:43) Custom vs. Off-the-shelf hardware for IoT solutions. How do you decide which is best for your Applications? 

(25:28) What are common roadblocks associated with IoT hardware development? 

(33:32) How is security handled in IoT device development? 

(38:18) From a hardware perspective — how will LPWAN impact IoT? 

(41:03) From a software perspective — how will LPWAN impact IoT? 

(44:36) When searching for an IoT hardware partner — what questions should companies ask themselves and be prepared to answer during the process? 

(46:58) When searching for an IoT software partner — what questions should companies ask themselves and be prepared to answer during the process?

---

Transcript:

– [Ken] You are listening to the IoT For All Media Network.

– [Ryan] Hello, everyone, and welcome to another episode of the IoT For All podcast on the IoT For All Media Network. I’m your host, Ryan Chacon, one of the co-creators of IoT For All. Now, before we jump into this episode, please don’t forget to subscribe on your favorite podcast platform or join our newsletter at iotforall.com/newsletter to catch all the newest episodes as soon as they come out. So without further ado, please enjoy this episode of the IoT For All podcast. Welcome to the IoT For All podcast. I’m your host, Ryan Chacon, and I’m here today. with a nice little group of people. My co-host today is Eric Conn, the CEO of Leverage. I’m gonna have Eric quickly introduce himself.

– [Eric] Hey, everyone out there. We’re super-excited today ’cause we have some friends of ours from Arizona joining the podcast. So I’ll let Ryan continue the introductions.

– [Ryan] Yes, those people from Arizona, the CoreKinect team, Assar, John, and Mitchell, would you guys mind just goin’ around introducing yourselves real quick, a little background on kinda how you ended up in the field and in the position you’re in now?

– [Assar] Awesome, yeah, thanks for the introduction. My name’s Assar Badri, I’m the CEO of CoreKinect. Been in the industry two decades, specific in IoT, the better part of last decade or so. And yeah, just always been around, in and around technology, and last five, six, seven years has been really interesting for IoT and really excited to be in the space, and let’s see how it evolves from here on out.

– [John] Hi, this is John Horn. I’m the President and Chief Strategy Officer here at CoreKinect. I have 20 years IoT-specific. I helped build and launch the M2M IoT channel at T-Mobile. I’ve been a carrier guy. I have been a platform guy. I’ve had some successful exits in the industry, and now I get to be part of the exciting CoreKinect strategy of what’s gonna move forward here. And I have a unique perspective, ’cause I was their customer before joining the company. So I know what it looks like on the inside and the outside.

– [Mitchell] Hello, my name is Mitchell. I’m the Principal Engineer at CoreKinect. I’m still working on my first decade of experience, but I’ve been on the software side, the hardware side, and the firmware, and definitely like the low level and the intersection really where I can do the firmware and the hardware design at the same time, and really complete the full solution instead of just being in one part of a much larger implementation.

– [Ryan] Thank you, appreciate it. It’s great to have you guys on today. One of the things I wanna start out with is, Assar, if you wouldn’t mind kinda just giving a little insight to our audience about CoreKinect, kinda what you guys do or the space you play in, just for anyone who’s unfamiliar.

– [Assar] Yeah, absolutely. So CoreKinect is a full service IoT hardware/firmware product development firm. We specialize in everything from electrical engineering, RF engineering, firmware development. We do mechanical industrial design, and really end-to-end product development down to the manufacturing level. So we actually shepherd a product all the way from ideation down to, it’s on the factory floor being produced. So that’s what CoreKinect does.

– [Ryan] Very cool. So can you talk a little bit more about what does it mean to actually build, let’s say, custom hardware for an IoT deployment? Like, what is that process like at a high level? Not necessarily has to be specific to how you guys operate, but just like if a customer’s listening to this, or anyone in the IoT space, and they’re curious about how the devices get made, what does that look like on the custom development front?

– [Assar] So it all starts with understanding what the customer’s needs are. Is it a strategy they’re going for? Is it a Applications they’re trying to develop to? Is there some kind of operational gain that they’re tryin’ to take advantage of? That’s really where it begins, is identifying those key core bits of information. From there, we try to sit with the customer, do an ideation session, understand where are they going long-term. Can we develop hardware that might take advantage of something else in the future? Is there other maybe groups that could take advantage of that within their company, or other processes that can be leveraged there as well? That’s the second part of the equation. Once we identify those key pieces of information, we can then go on to developing a concept of what a custom piece of hardware might look like. And that’s really all about identifying constraints. Is there a size constraint? Is there a battery constraint? Is there a particular technology, like an LPWAN technology constraint? Is it gonna be on a factory floor setting? Is it gonna be on a contained lot? Is it gonna be a citywide-type project? So that’s where we identify those key parameters that help drive what that solution looks like. And then from then it goes to a design phase where we sit down with a customer and review what our overall system looks like. Internally, we might be doing simulations or doing a design review, doing a schematic review, looking at to what our electrical standpoint makes the most sense. And then from there, it goes on to prototyping or we might look at an actual hardware build. So a quick-turn build of a circuit board, build it all out, actually put some firmware on there and test out the Applications. Does it work? Does it meet the customer’s needs? At that point, we call the customer back in. We review that with them, show them an actual demo of that custom piece of hardware, and then determine what changes need to be made. And from then on out, it would be kind of an iterative process, right? Making those changes, then closing them down, locking it, and then going into manufacturing. So that’s the whole kind of life cycle, if you will, from ideation, concepts. We have a problem, I need to solve X issue to I now have a piece of hardware in my hand that solves that problem. It’s all you can do.

– [Eric] And so basically you guys have kind of figured out how to decompose from a hardware and module level, and even on a board layout level, I’d assume, at some level, the ability to modularize these different subsystems that go into basically every type of device, and then swap in and out different, say, connectivity, a SIM chip for cellular versus a LoRa module for a LoRa deployment versus something else. Yeah, you seem to be, just have figured out that secret sauce that allows you to reliably, quickly, and with high quality, deliver hardware for a solution that, you know, hardware that really is not available in the market, that to solve a very specific customer pain point. That’s been a very unique experience we’ve had in working with you guys that’s been, I think, a secret to our joint success with some of the customers we share.

– [Assar] Yeah, modularization is definitely the key. I think you just said it, right? And that’s been goin’ on in a lotta markets for a long time. And it just seems like, for one reason or another, technology just hasn’t caught up in a way that can take advantage of that. Like if you look at automotive, for example, automotive industry’s been doing that for decades, right? Having a skilled architecture using, building different cars with the same frames or same engines, and swapping things in and out. At the end of the day, we’re doing something very, very similar. You’re just not having to reinvent every piece of the pie every time.

– [John] And as the one engineer in the room, I like to call ’em Legos, just because I can visualize that very easily. And one of the other advantages not only is speed, but reliability. If you’re not redesigning everything from scratch every single time, you get somethin’ that works.

– [Eric] Yeah, yeah, and sort of for Mitchell, since I know Mitchell’s kind of the man behind the curtains a lot in terms of writing the firmware, Mitchell, do you also have sort of libraries of things that you’ve done or techniques you’ve built that you can also apply to the hardware?

– [Mitchell] Yeah, so for the firmware, all of the firmware is very, very closely tied with exactly which piece of hardware you’re using. And one of the things that makes it really easy or easier, kind of the secret sauce, is the ability to have a large portfolio of tools to choose from. So that way, when the customer says, I need this level of sensitivity for motion, you don’t say, “Okay, cool. “Well, our accelerometer doesn’t really do that, “but we’ll try our best to make it get there.” We make sure that our firmware and our drivers to run all these things, we keep just bringing in random things. So even if we don’t have an immediate Applications, we spec some time out to say, let’s bring on a new piece of a new accelerometer, a new moisture level sensor, just something new to try and increase our portfolio. So when the customer comes in and says, I need to do X, you already have the tool, as opposed to you have one hammer and everything looks like a nail, so you just keep using it even if it’s not the right thing. It makes the development much, much harder, because you have to work around constraints that wouldn’t be there if you just used the right tool.

– [Eric] Yeah, yeah, so you’re doing a lot of IRAD kind of like a product development or product investment to sort of foretell what a customer might ask for. So when they ask for a solution ahead of time, it may not be the first time you’re hearing of it or at least thought of it and experimented with certain aspects of it. So then you use your modular approach to put the pieces together, but you have kinda well-known and well-characterized subcomponents.

– [Assar] That’s what really what bridges the gap. And I think if I could step into the next part of the secret sauce, if you will, is using the toolkits that are available in the open market, right? There’s a lot of open source hardware right now that does a very, very good job of allowing you to iterate quickly on hardware. A lotta platforms like ESP32, for example, I know that’s a favorite of Mitchell’s. Mitchell, I don’t know if you wanna talk about that a little bit, some of the benefits that you have from using hardware like that to iterate on.

– [Mitchell] The nice thing there is you can, so there’s all the libraries and stuff, and just work with the actual manufacturers, the people who build the thing. So like ESP32, for example, Xpresso did a good job in setting up a platform to make it easy for people to develop. And sometimes with certain products like that platform’s already there, you just have to go ask ’em for it, find the right person to say, “Hey, your examples are awful online.” They go, “Oh, well, we have a better example.” And they’ll give you the firmware example to enable their hardware.

– [Assar] Yeah, and they’re very open.

– [Mitchell] They’re very open with it because they wanna sell hardware, so they’ll help you to be able to make your full product. They’re just giving you a certain driver to get maybe Wi-Fi, Bluetooth, or Spy or whatever your connectivity is you’re trying to get done. It’s in their best interest to help you. And just reaching out to them, so if something’s not clear in a data sheet, the quickest way is usually get on a conference call with ’em and say, “Hey, let’s walk through this.” Get an FAE or somebody on the line so we can figure out exactly how to bring this online, and then other things. So another possibility is if you’re at the lower level where you don’t have the experience to be able to do all this and bring it online quickly, you could even start at the Arduino level, and then say, okay, we know we cannot mass produce this with Arduino, but you can do a quick and dirty test. You can make something work real quick just to say is this possible? Microchip is another partner we use a lot. And their dev kits are fantastic. You can just go online and say I wanna use this sort of family, or you want a PIC30, a PIC24. And they have dev kits for just about every single one of their parts or something in that family. So if you need to bring a new driver online or something like that, a lot of the code you write for one can be ported over to the next one. And then you just do little changes, so it’s incremental changes as you do a new project or a new product, as opposed to starting from scratch every time.

– [Eric] Yeah, that seems to be a key enabler for you guys, ’cause you do have very strong relationships with a lot of the semiconductor companies and module makers. And as you say, it’s in everyone’s best interest. They wanna sell modules, they wanna sell ’em at scale. And so the easier they can make it for you guys, and ultimately for an SI or a software platform like ours, to help them sell more, they wanna do that. So there’s relationships with the Microchips and the Nordics, and that entire industry I think are really important. And you guys definitely seem to know a lot of those, a lotta that space, and have a good relationship with ’em.

– [Assar] Yeah, it’s just engagement, right? Early and often engagement with these different semiconductor manufacturers is key. Like you said, everyone wants to sell you hardware at the end of the day to be an ingredient within your application. So understanding what, even if it means just sticking with one to start with, Cyprus, Microchip, Nordic, whoever, just sticking with one and understanding what their key offerings are and building that relationship, that goes a long, long way.

– [Eric] Yeah, yeah, and you are in the, what do you call it out there, a desert, a Silicon desert?

– [Assar] Silicon desert.

– [Eric] Yeah.

– [Assar] Silicon desert.

– [Eric] Silicon desert. So, yeah, yeah. I learned that directly from those guys last time I visited, how many semiconductor companies were all like within five-mile radius of where their office is.

– [John] Well, when it’s 115 outside, we can make our own silicone out there. Exactly.

– [Ryan] I do wanna kinda step back for a second and talk a little bit, so we just kinda went over a lot of detail about the custom development process. But then on the opposite end of the spectrum, you have kind of the off-the-shelf options. And I wanna kinda ask both sides this question, but I’ll start with Eric. Just as like a systems integrator and more of a software company, how do you kinda decide when you’re working with a customer on the custom route versus the off-the-shelf route? Is it a certain stage of development makes sense? Is it really specific to Applications? Is it cost-oriented? Kinda what’s that thought process around it and advice that you give to companies that you’re helping make that decision?

– [Eric] Yeah, generally, if a customer comes to us first, and they don’t have hardware in mind, and we don’t have hardware, ’cause we’re not a hardware company, we’ll first look to see, are there things in market that may be able to solve at least immediate problem? Generally, I’d say about half the time, there’s nothing out there that actually will do the job, which seems amazing ’cause there’s literally hundreds of companies producing sensor hardware now for various ilks and connectivity options. But about half the time, there is nothing out there that will actually do exactly what the customer needs. So you have a choice on the front end. You can either take the existing hardware, which again, has built-in margins that have been stacked across the board to get to that final product. So you’ll generally be paying a premium price to get an asset tracker or a fill level monitor or something like that, which may serve you for a pilot if you’re only buying 100 or 50, then you can afford to pay that premium per sensor. But if the customer really wants to scale, and that’s what most customers ultimately want to do, it generally, just the economics don’t work. And so that’s where you get into, okay, as sort of helping the customer decide what is the best fit for them, the customer hardware solution really becomes your only choice, because it’s only when you do that that you can really control every element of the BOM and build up the cost basis. And you know what your bogie is. Like, you know that sensor has to be $30 or less for the economics to work on this Applications. And you generally can’t get that kind of flexibility in off-the-shelf stuff. So when I look at it just in general, sort of wrapping it up, I look at off-the-shelf stuff if it’s available and it’s easy to integrate, and relatively inexpensive for a pilot, we’ll try to use that just to prove out the value. But, ultimately, I think most of the scaled deployments you’re gonna end up with a custom solution. The thing that CoreKinect has been able to do because they’re so fast at it is they actually have added a new wrinkle to it, because they, instead of sort of doing that high-cost pilot with off-the-shelf hardware, a lotta times we’ll go to CoreKinect and say, hey, there’s not exactly the thing we need, but we need this in like 60 days. Can you actually build something somewhat custom to meet this pilot? And they’ll say yes, and they’ll actually deliver. So it’s kind of, it’s unusual to be able to have that option. And so as an SI and cloud platform, we really enjoy working with companies like CoreKinect, because it allows us more flexibility to actually deliver the right solution at the right cost right upfront instead of sort of a placeholder solution. And then having to start this phase two when they’re ready to go, and now you have to start all over with a totally new hardware design.

– [Ryan] Yeah, that’s something, just in talking with other guests and other people around the IoT industry, just the hardware is always a very daunting part of the project. And you guys, everyone here has kind of alluded to that at times, but what CoreKinect seems to be doing is taking that kinda fear and that time to market out of the equation, or at least bringing it down. And that’s great. So I’m curious on the CoreKinect side, how do you guys kind of, I guess, work in those situations where, do you ever have clients that come to you that there maybe is an off-the-shelf version that you kind of push them to to kind of get the pilot off the ground? Or is every engagement that you work with usually something custom, and that usually works and kinda suits their needs?

– [Assar] You know, at the end of the day, IoT’s all about time to market, right? If you start with a off-the-shelf solution, which we have done in the past, said, “Here, here’s an off-the-shelf product. “We’re gonna add some sensors to it,” and you’re gonna pilot this for five or 10, 15 units, more of a POC, really, than a pilot, we’ve done that. But at the end of the day, a customer wants to have something specific. So let’s take asset tracking, for example. If you want just an asset tracker, there are plenty of asset trackers you can buy on the open market that utilize some form of LPWAN. But if you want one that lasts for more than three years, or it’s at least IP68 rated, or it becomes, you know, is very small or works 600 temperatures, then the pool is incredibly small to which devices are actually available on the open market. And that’s back to the requirements, understanding what the customer’s requirements are. So if a customer goes from a POC to a pilot, oftentimes when they like what they see in the pilot, they wanna jump to production quickly. That’s all about, that’s everything. That’s everything for them, is getting to market quickly, getting the product out there, and realizing the values, the gains that they get from IoT. So that’s where having a custom bit of hardware actually helps because it’s, again, as Eric alluded to, it’s all about scale. If you want scale, you’re oftentimes gonna need custom hardware, because ultimately, that’s how you drive costs down. It’s not the other way around, as some people may assume.

– [Ryan] Gotcha.

– [Eric] Yeah, and you also get exactly what you need based on the customer’s real requirements. So every nuance of the implementation affects the hardware decision, and the software decision at some level, but definitely the hardware decision, and imposes new things that they have to think about as they’re designing it. And that universe of potentials is so big that no matter what non-customer standard stuff’s out there, it will never meet all the constraints like temperature, range, precision, latency. There’s just so many dimensions, and they all, the universe becomes gigantic. There’s hundreds of thousands of combinations of things that have to be traded off. And that’s why, custom hardware, you can get exactly what you want. And if you can deliver it at the speed at which CoreKinect has demonstrated, that is a real competitive advantage for a customer. And then, also, they know what their true cost is, and they can manage that on the CapEx side, which is usually where all the hardware goes, right upfront, and they, instead of, “Oh, I’m gonna pay $100 for my asset trackers for the POC “or the pilot, but I only need 100 of ’em, “so that’s 10,000 bucks. “Okay, I can live with that.” But then they think about a million, they’re not gonna spend $100 million on asset tracking hardware. So now they’re gonna be like, “Hey, can you get this thing down to 20 bucks or less?” Havin’ a partner like CoreKinect, you can actually have those discussions upfront, so that they’re not scared to even think about scaling because you don’t wanna get in that pilot purgatory stage where a lot of IoT ends up, where you show that it can actually be done. You can solve the business pain point, but then the economics of scale just work against you and you can never get there. And what I’ve noticed is a lot more customers are a little more educated about that now than they used to be. So it’s not just about the pilot. They start asking us upfront questions about, “Well, I have 1,500 stores. “How much is it gonna cost me at scale to run this thing?” How much is the CapEx, what is the OpEx? So a lotta times they won’t even greenlight the pilot or the POC until they feel comfortable that they can scale. That is a nuance to the conversation that I’m noticing a lot more in 2019 and going into 2020 than I certainly didn’t see in 2018 and 2017.

– [Assar] Yeah, That’s a really good point, Eric. We’ve seen that quite a bit with customers who just have a lot of, it’s information overload, right? They hear a lot on the open market about do I use cellular, do I use narrowband, do I use CAT-M1, do I use LoRa in this case? Is it Bluetooth, is it Wi-Fi? And they get lost in the shuffle of all these things that are available, right, out there in the open market for them to integrate with. And that’s what I feel like causes the most heartache for customers when they go to integrate, is not understanding or not having a good grasp as to what actually is the best solution for them, right? And it all begins back at requirements, understanding what you actually need to accomplish. What is your real end goal? Don’t focus on what you may read online from this place or that place. What is your real end goal, and just working down what technology actually is the best fit.

– [Eric] Yeah, absolutely.

– [Ryan] One of the things I think that’d be interesting to talk about, we have a couple different topics I know we wanted to bring up here, but one of them that I’m curious about is, in the custom development process, as a customer, what are some roadblocks that you guys have seen your customers go through or that have encountered on throughout that process, that maybe going into an engagement as a customer, they might not expect?

– [Assar] That’s a good question. I mean, there’s definitely the cost aspect, right? Oftentimes customers are really scared of what a custom hardware solution may end up costing them, not just in the long run, but in the short run NRE. And oftentimes it’s, well, I don’t have budget, right? I need to prove this out. I’m a large company or a mid-sized company, whatever the case may be, and I need to prove this out to our management chain or Board of Directors, or whatever the case may be there, to ensure that there’s actual value here, right? There’s a return on our investment. So cost is a large determinant of whether they go down this path or not. And ultimately, cost goes hand-in-hand with development time. The more development time you have, the more expensive something gets. And if you have something worked out to a point that you don’t need to spend an inordinate amount of time, like Eric mentioned earlier, six months, right, I think it’s a very typical thing we hear in hardware development, the amount of time it takes to go from an idea to actual hardware, five months or four months. It’s a long amount of time to be putting engineers on a project to develop something. And that often ends up costing a fair amount of money. If you can get something done in five weeks or six weeks, then the cost comes down. There’s less pressure on the business unit to actually make a decision to go into pilot, ultimately realize the value, and then take it to production. So cost is a big one.

– [John] And also being able to move from your POC to your pilot to your deployment quickly is a better use of their resources all the way around. Because they’re trying to get an ROI. And the faster you get to that ROI, the better the overall solution is for everybody involved. So every step of the way, it saves resources, whether it’s money, people, whatever it is they’re trying to do.

– [Ryan] Right, yeah, any time you’ve got that custom word out there, people start thinkin’ it’s gonna be expensive. But not always the case is what you’re saying?

– [John] Yeah, absolutely.

– [Eric] Yeah, and there’s also just the idea of project momentum. When things drag out, people lose excitement. And so speed to market just keeps the whole team energized, and focused and excited to actually see the things and demonstrate that ROI, the business needs.

– [Assar] Yeah, we try to drive the team here to have a mindset to iterate hardware like you iterate software. We work in sprints similar to how you would work to develop software. And that’s the key, right? Getting through those sprints and then showing that immediately to the customer. “Hey, this is what we’ve accomplished in this sprint. “This is what’s done. “This is where your project’s headed,” right? Maybe it’s mechanical designs. Maybe it’s a board layout. Maybe it’s a high level Bill of Materials that you can take back to the Finance Department to say this is roughly what the project may cost. Having that happen early, that engagement early and often in the the customer relationship’s huge, ensuring that the customer succeeds and gets all the way through to the pilot, and then ultimately through production.

– [Eric] Yeah, and one of the things that, and this is a small but I think it’s an important thing, kinda going back to customer engagement and momentum is, you guys readily produce like 3D printed kinda models. Even if the electronics are not inside, you’re able to put that in a customer’s hands, so they actually can tactically feel the size, the weight. They kinda see, hey, it’s kinda cool-lookin’. It looks stealthy or whatever. So that sort of the hardware design aspect I think is a really cool thing that you guys do in leaning forward, and really sort of that agile process of hardware, which is definitely unusual. A lot of traditional design companies, they’ll get their requirements upfront, and I’m not saying they don’t do a good job, but they kinda go dark. And so the customer’s like, for four or five months, not really sure what’s happening. It’s all a black box, there’s not a lot of disclosure in between that time. And so the customer gets a little anxious. They’re waiting for five months for something to come out, which may be functioning at that point, but they could have taken the opportunity maybe two or three times in between that five-month period to show prototypes or just the casing or various other components and demonstrate, keep the momentum. And you guys seem to get that from a BD and just from a corporate culture standpoint of keeping the customer engaged on the hardware, and spinning it around really, really quick, I think is a real key thing for your end customers to feel confidence.

– [Mitchell] You’re absolutely right, Eric. And the other thing from the engineering standpoint, is it makes our lives easier to get feedback early and often, ’cause it’s much, much harder to change a design after you’ve done four months of work, and you’re like, it is ready to go. We have molds gettin’ created. Then you put it in their hands and they’re like, this doesn’t feel like what I thought that picture you showed me on the email that one time, it’s not what I thought it would feel like. It needs to be lighter. And you’re like, whoa, we’re past that point. We can’t change that very quickly in another four months. But if we send you a thing and we say, this is the design, this is what we think it’s gonna weigh, we don’t have the components exactly to make it weigh that. We put some lead weights in it, seal it up. So this is almost exactly what you would feel. You can have a 3D printed case, it won’t be the same plastic, but it’ll get you the same look and feel. And then the customer can give you your feedback right away and say, “No, that was not what I was picturing “when you described it to me “and showed me those CAD models.” ‘Cause that’s the thing a lot of times the engineers will forget that other people don’t see the same thing. We work with CAD models and PCB layouts all the time. So when we look at it, we know what that means in real life. But then you give it to somebody who they’ve never done this before, they’re gonna look at it, they’re gonna get a completely different picture, and we’ll be talking about the same thing but picturing completely different things.

– [Eric] Seeing is believing.

– [Mitchell] Yeah, by getting it there real early, we can get our reality check as engineers and say, “Oh, yeah, I need to change how I describe this and make sure that they really get to feel it.

– [Eric] Yeah, that’s important. I mean, everyone can look on a piece of paper and say, oh, it’s two and 3/4 inches long and an inch thick, but until you actually hold it in your hand, you don’t really realize what that means. ‘Cause you don’t put a ruler on your hand in your palm, like you need the physical thing, the weight, the touch. And, yeah, I think that’s really important sort of aspect of kind of your business practices, just what you do for all your customers. And I think it really helps you form that tighter relationship with your end customer. And everybody, I mean, just modern society, people want to be connected more frequently and more often, and have update about everything, our relationships, everything we’re doing. So bringing that sort of thought process to hardware design is a really good idea, and I think customers really embrace it.

– [John] I don’t think you can communicate too much. When I was their customer, they were constantly communicating with us, and that’s why they got it exactly right the first time.

– [Eric] Yep.

– [John] There was no question when that product deployed.

– [Assar] Going dark on a customer for weeks on end, months on end, and just saying, well, when we’re done, you’ll get it, you’ll get it on this date, never, never works, ever.

– [Eric] Yeah, not a good idea for anybody, yeah.

– [Assar] Never a good idea.

– [Ryan] Mitchell, you said something a second ago about that iteration process and kind of as you get further along, it makes it more difficult to change the hardware. And that’s something that I think is a big fear of people when they go down that hardware route, or a custom hardware route, is feeling like they’re gonna get a little bit further, they’re gonna learn something new about their Applications or their situation, and they’re gonna have to change it, and that’s gonna be expensive. In addition to that fear, there’s always a fear of security. And I’m curious how on the firmware side, kind of more on the technical elements, you guys handle security. We’ve had a lot of guests on here to talk about device security and how expensive it is to kind of incorporate device security later on down the line rather than trying to focus on it from the beginning, where it’s actually more, or it’s a bit cheaper to be thinking about it. How do you guys handle security in your devices when you’re building them for customers? Kind of what’s that process look like? Or what is your overall philosophy on that?

– [Mitchell] So to answer the first part, that’s why we try to do the requirements very quickly and precisely, and do that feedback as often as possible, so that way we don’t have to make changes later on. Usually what we found, though, for when they wanna add additions to hardware and it’s not a miscommunication on what they wanted to begin with, the changes aren’t as hard to make it hardware later. So we got the core of the product exactly the way they want, they wanna make a change to a part of it, that’s not hard. But if you miss what the core of the product was supposed to be, that’s where it becomes very hard to do the change later on. But for the security, you’re absolutely right that security needs to be designed into the product from the very beginning. Security as an afterthought never works well. I think most people will have seen all the news articles about the IoT webcams, and just IoT devices turning into botnets. Those are ones where, yes, you built the product for what it was supposed to do, but you didn’t consider how people are going to abuse it. So secure elements is one of the things that we look to in our design. I mean, it all comes down to what the customers, what their decision is. And we’ll say, this is where we would prioritize security, and we always put it very high up. So we work with companies like Kudelski Security and Microchip. They also have a secure element. They’re paired with, Google has a backend for it as well. And just making sure that security is something that we tell the customers this is important, especially with depending on what your connectivity option is. But even if you have very little connectivity, there’s always the possibility that your software can only be as good as the devices feeding it. And if you can’t trust the devices feeding it, then essentially, your application becomes questionable. So you have to make sure that the device level itself, the device that reports the data, is who he says he is.

– [Ryan] Right.

– [Mitchell] And so building it and just making sure we’re on top with the latest security trends, and making sure that we don’t incorporate anything that has bugs in it already, and making sure that they’re not broken encryption standards or things like that, that we use.

– [John] Goin’ back to the first part of the question, though, something that CoreKinect does an amazing job of is trying to find out what the customer’s plans are in two, three, four, five years. It’s not just about this device, this solution. Because people do have an idea where they wanna go, and CoreKinect can design that future into the device. Maybe they don’t use it now, they don’t spend it now, but the footprint’s there, as Mitchell said. And so changes don’t have to be huge cost changes because there’s an understanding of their roadmap into the future. So and I think that’s a real critical part. It’s not just about this product.

– [Assar] And it doesn’t always, and John brings a good point. That doesn’t always have to have, carry a cost, either. I mean, we may design something in, for example, but just not install it at factory time, right? So when you get to actual production, you determine that this release doesn’t have this particular feature on. Maybe you just don’t install hardware, and we’ll do, we’ll have strategies, DNI strategies, Do Not Install strategies at the factory to say, well, this customer is gonna install or deploy at these sites. They don’t care to have this feature, do not install these chipsets or these sensors on this product. But maybe later on, they’re gonna leverage that same piece of hardware with those sensors, with those chipsets, and then you reinstall them back into at factory time and allow them to continue. So just a SKU strategy for sensors is also pretty big potentially for future-proofing your products.

– [Eric] Yeah, and I know you can also sort of disable what you, like at the hardware, if you don’t do a DNI at the hardware level, you can, through the firmware, disable certain features and then enable them later when the overall solution can support it, like Bluetooth or some other types of applications over and above the specific Applications. And that can be done like over the air. So that is another layer of flexibility which won’t necessarily save you upfront on the hardware costs ’cause you still have to put the module on the device, but the solution can actually involve without ever changing anything on the hardware side. You just enable it through firmware over the air.

– [Ryan] So as we kind of get to the end here, I have two questions, that one of them we were actually talking about before this episode started, which I wanted to bring up, I think is important and Eric kinda hit on, which is on the connectivity side. So just generally speaking, LPWAN, we’d love to kind of hear your thoughts from a hardware perspective on just kind of the impact, and just overall based growth of LPWAN and its impact on the IoT space. And then, Eric, anything you think worth adding.

– [John] Well, I’ll start off on that having been the carrier guy and been dealing with connectivity almost my entire career. There is an alphabet soup today of so many different choices, and you have LPWAN technologies like LoRa that are independent of the cellular configurations. And then you’ve got mBIoT, CAT-M1 and others that are being designed and developed and deployed on the carrier side. Here’s the bottom line today is, if you don’t have a box where you’re trying to push a certain level of connectivity, because you already have a box, then you’re free to design anything you want to meet the customer’s needs for that particular solution. And it might be LoRa, it might be CAT-M1, because you need texting to wake up the device, or whatever the needs are. The key is to be completely connectivity-neutral and agnostic, and be able to support it all. Because no one-size solution from a connectivity standpoint solves all problems. It just doesn’t exist. It’s either too expensive or too much battery drain, or not enough coverage or whatever it happens to be. So you have to have the flexibility of going in of any type of connectivity and supporting it all.

– [Assar] Yeah, and touching on that a little bit from the actual module cost, right? There are a lot of options, as John said. It is an alphabet soup of options. But at the end of the day, you have to look at your customer’s needs. If it’s going to like a, let’s say a segregated area like we talked earlier, it’s a factory floor environment, LoRa’s a really good choice for that. If you know it’s gonna remain within a contained environment, having a local LPWAN environment backhaul, either through ethernet or cellular, is a very, very good option. It’s very inexpensive. The cost of modules have come down dramatically. Chipsets have come down dramatically in the last few years, and oftentimes sub-$3 range, sub-$2 range even. That’s always a good option. Conversely, if you’re gonna be in a situation where you need no bounds on your coverage, you want nationwide coverage, CAT-M1 and narrowband, for that matter, through multiple carriers has been very, very good. They’re effective. Implementing them has been pretty straightforward. And the cost of the modules themselves have come down dramatically. I think we’ve seen narrowband modules now get south of $7 per unit. So you can get a custom cellular solution with relatively inexpensive coverage, monthly fees sub-$1, sub-70 cents, even in some cases, 50 cents even, for under $7 a unit. So it’s a pretty major shift from where it was even three or four years ago where putting cellular on a device meant 10, 12, $15 BOM cast solder. So that’s gone away now, and it’s much more level playing field with all these different options.

– [Eric] Yeah, and I’m super-excited from my lens or from where I sit that I think really next year, you’re going to see the LPWAN. And for the audience out there, LPWAN, we’ve said it a lot and probably haven’t defined it, but it’s Low Power Wide Area Networking. And it’s typically IoT-specific connectivity. It’s not the stuff you would, you read about the headlines, all 5G. It’s all the stuff that devices can connect to over long ranges, battery-sensitive and inexpensive connectivity. But you’re not gonna stream a YouTube video over an LPWAN type of connectivity. But for the reasons that Assar and John both mentioned, being kind of connectivity-agnostic is important, but the combination of LoRa modules, mBIoT, M1 modules, the module cost coming down, the certification from the carriers, ’cause they have to be both FCC and carrier-certified, that’s all happening. You have the whole ecosystem is building devices around them, so you’re getting more and more devices that are available. Now these are more off-the-shelf devices, but it also enables companies like CoreKinect to very quickly assemble a custom solution using those same low-cost components to meet Applications. So I feel like going into 2020, we’re gonna see an explosion on the IoT side of LPWAN type of deployments. And because they’re low cost and wide area, you’re going to start seeing the scale that IoT has been promising for a long time in the enterprise space. I think it’s gonna finally enable and unlock a lot of those Applications that heretofore have essentially been a little too expensive to do on both the connectivity side and on the hardware CapEx side. I think all of a sudden it’s gonna drop below this key threshold, and it’s just gonna enable an entirely new universe of solutions for every industry. So I’m super-excited about going into next year, although sort of the backdrop that we’re all working in within the IoT ecosystem of how this is gonna really start really growing.

– [John] Well, and you make some great points, Eric. I mean, we keep talking about the Internet of Things and there’s gonna be billions and a trillion devices out there, and it’s not gonna happen until the things are simple. And that’s why we believe that things need to be simple, and that’s an important part of what we’re doing here. Because this is the missing link. This is the final piece that will make IoT simple enough to hit major scale.

– [Eric] Yep, totally agree.

– [Ryan] Yeah, it’s gonna be very exciting. Just, one of the biggest things we’ve learned at IoT For All is how complicated people believe IoT is, hence why we kind of started this whole thing, which is simplifying all the different components of an IoT solution from end-to-end. And now we’re actually seeing it actually happen in the real world, like the hardware is getting more simple, the software’s getting more simple, making it more achievable for people to deploy these solutions and reach those goals that we’ve kind of been promised for many years. So the last question I have for you guys before we finish up here is kind of more of a general piece of advice I’d like to have you guys just share with the audience. As a company that’s out there looking for hardware, whether it’s custom or whether it’s off-the-shelf, or they’re just kind of going through that phase of their development, what kind of questions should they be asking themselves? And what kind of questions should they come prepared to ask or answer, I guess, when they go out and look for a hardware partner to work with?

– [Assar] I think first and foremost, the question they should answer is, what do we really need? What is a real problem that we’re trying to solve? It’s easy to get wrapped around the axle when you start talking about hardware or custom hardware, about all the things that are possible, and impossible, really, for that matter. But identifying what it is you actually need as a company, as a group, as a business unit, whatever the case may be, to solve your problem, that’s first and foremost. Once you get that down, understanding where you’re going as well, not just where you’re at today. Where do you wanna be in two years and four years, and six years? What problems do you wanna solve then? And how do you want this solution, this hardware, to be a part of that equation, right? End of the day, you don’t want a bunch of disjointed solutions as a company or as a business unit when you’re trying to solve these problems. You want a cohesive solution that makes sense, or cohesive set of solutions that make sense for you. So I think understanding, first and foremost, what you need and where you’re going. And only then can you address what you actually need from a hardware standpoint.

– [John] My feedback on that is start early. People wait too long on hardware. They get their business model. They figure out this is what they wanna do. They start writing software, they start creating the solution, and then they go look for hardware six, 12 months later. Start early, make hardware a key part of your process from day one.

– [Assar] And it can be-

– [John] Yeah, yes, it can.

– [Mitchell] And another thing I’ve seen with that is making sure you don’t limit your connectivity options and say, we read this buzzword, everybody keeps talking about Zigbee, LoRa, CAT-M1 or mBIoT, and we’re gonna definitely use that for our implementation. And then you talk with them and they’re like, “Where are you gonna deploy this?” And they’re like, “In our building “that has Wi-Fi everywhere.” So then why are you paying to implement another connection when you already have it built into your infrastructure? So just making sure that you’re open when you go into these things to not just say this is how it has to connect. Have some other abilities, ’cause there are limitations on each one of these connectivity options.

– [Ryan] Yeah, that’s a great point. And Eric, on the software side, how does kind of what they mentioned relate to that software decision-making process? Is it very similar? Are there different components or different pieces that customers should kind of come to, with really thought-through, that apply more to the software than the hardware side?

– [Eric] I think the general philosophy is I think the customer needs to really focus on their business and their pain points. And so if they really understand what is the problem they’re trying to solve or the efficiency they wanna gain. ‘Cause that’s where their expertise lies. We, as a software company or CoreKinect as a hardware company, do not necessarily understand their business. We don’t live and breathe it. We don’t know how operations work. We don’t know what drives their profitability or customer satisfaction. We know how to build IoT solutions. We know the software side, they know CoreKinect as a hardware side. So I really like customers that come to us and they say, “Here’s my problem. “This is something I would like to solve. “I have too many people doing this task “and I would like to eliminate some of them, “and so they can work on something else “that’s more rewarding.” Or I need to know, I don’t wanna be having troubles to go check and look physically at something in the ground when I could sort of remotely see what that value is and save myself on the cost of transportation back and forth. So I really try to get our customers to tell us their actual business pain points with no implementation whatsoever, and then let CoreKinect and Leverage imprint the right solution that solves those business pain points at a particular ROI. So if a business knows what they wanna solve and they know about how much they think it’s worth to solve that, like what is their cost of not solving it is usually what they should come prepared with. Then we can really, together, jointly, create the solution that actually meets all their requirements. It solves their business problem. It does it at the price they need it to be done at, and it can be delivered practically and supported from a technical standpoint.

– [Ryan] Right, that’s great. Now, this is all wonderful advice I think our listeners would really appreciate. The last thing, I guess, CoreKinect, on your guys’ side, if people out there listening are more curious to learn about what you guys are doing, ways to connect with you, ask additional questions on the hardware side, what’s the best way for them to kinda do that?

– [Assar] Absolutely through our website, CoreKinect.com. So drop us a line, send us a note, and we’re happy to have a conversation with anybody that has any questions in the field. Like, this is what we do, and we do it because we love doing it, so.

– [John] And that’s C-o-r-e-k-i-n-e-c-t.

– [Ryan] This has been great. I really appreciate you guys for jumpin’ on and doing this episode. Eric, you as well. This has been a lotta fun. But other than that, we really appreciate your guys’ time, and hope to have you guys back on in the future.

– [Assar] Absolutely, thank you.

– [Mitchell] Thanks.

– [Eric] Thanks, guys.

– [Ryan] All right, everyone. Thanks again for joining us this week on the IoT For All podcast. I hope you enjoyed this episode. And if you did, please leave us a rating or review and be sure to subscribe to our podcasts on whichever platform you’re listening to us on. Also, if you have a guest you’d like to see on the show, please drop us a note at ryan@iotforall.com and we’ll do everything we can to get them as a future guest. Other than that, thanks again for listening, and we’ll see you next time.