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?