Networking the Unnetworkable in Rust
The following is my interview with Nate Gray, Co-founder of MeshComm Engineering. I had a lot of fun learning about how MeshComm is enabling a diverse set of users to get data out of the most remote locations. If phrases like "Agtech" and "Electric Tractor Telematics" catch your attention, this interview is probably for you. It was also interesting to hear what its like to start a career in the military and support other veteran entrepreneurs. Additionally, with the end of the year fast approaching, I want to take the chance to thank each of you that uses filtra and engages with our content. We always strive to provide a platform that adds real value and to market it in ways that are also additive. But, as humans, we sometimes fall short. I'm always so encouraged by the many people that take time to give us helpful feedback or help us along in other ways despite our imperfections. Thank you truly. As always, feel free to check out our extensive rust job board.
Drew: So how did you start programming?
Nate: I started programming when I was probably nine or ten years old when my dad brought home a Timex Sinclair computer, which had 8K of RAM and an expansion pack that's bigger than my phone to give you 16K of memory. He had it all hooked up to an old black and white television. I was fascinated by the little programs that my dad was writing to get words to go across the screen and stuff like that. Later on, probably a year or two later I think, my dad brought home an Atari 800XL computer, which was the competitor to the Commodore 64. Both of those had 64K of memory. The other cool thing that happened with that is my dad bought a bunch of Compute! magazines. Those Compute! magazines had all kinds of games and programs in them, so you could try programs from there. I remember there was a Joust program in there. There was an original Zelda game that we programmed in and a bunch of things. So we would sit there, my brother and I, and one of us would read the lines off. The other one would type them into the console. We would get all the way through the program, save it to the tape drive, and try to run it. Invariably, there was at least one mistake. We would have to go through the entire program again to find the mistake. It usually turned out to be something like a zero versus an O or an L versus a one or something like that. The Atari 800 also came with a How to Program book that I basically memorized. That was how I learned to program. I spent hours as a young kid teaching myself how to write programs. In fact, I remember the first thing I wanted to do was program the Star Wars theme song. I was a Star Wars addict at that point. Later on, with science projects and things like that, I just continued to build on those skills. That kind of set the trajectory for the rest of my life.
Drew: I feel like that's a somewhat common story with people around your age. A parent brought home one of the early PCs and you just got interested. Was your dad involved with computers at all or how did he end up bringing them home?
Nate: So he's always been kind of interested in that stuff. He was working for Hewlett Packard in the Disk Memory Division there, which was also pretty fascinating for me. I remember taking tours at the site where he worked and visiting the clean rooms. He actually had to put on a full white suit and everything! At the time, I think they were working on the Eagle hard drive that had 100 megabytes of memory and weighed about 100 pounds. I remember like a year later he brought home a Coyote hard drive and it was also 100 megabytes, but it was about the size of a brick. And he had it partitioned into 10 megabyte chunks because the operating systems at the time couldn't handle 100 megabytes. I think we were actually running an operating system called GeoWorks, which I bet almost nobody has ever heard of. Also, we were playing games like Space Quest and things like that that were really popular at the time.
Drew: What was it that most captured your imagination about computers? What gave you the spark to stick to it and figure out how to make things work?
Nate: Really the spark was certain science projects at school where I could use the computer to actually touch the physical world. In one case, we needed to monitor and record the temperature of the classroom for 24 hours. We had a friend from church that worked for Honeywell. He was able to acquire a bunch of Honeywell thermostats for me. So, I set them at different temperatures that were roughly in the range of where I expected the room to be. Then I wired them up into the joystick controller on my Atari and developed a schematic for all of this. I wrote a program to monitor those ports and to log every time one of the thermostats was tripped. So, I could tell whether or not the temperature was 65 or 66 or 67 degrees or whatever it was. I ran that thing for the whole weekend and then came back, pulled my output, and built my report. So that was one of the projects that really captured my imagination.
Drew: So you're saying that your first big interest was in taking environmental readings with computers!?
Nate: I guess so. And it probably hasn't changed because if you look at what we're doing as a company today, it's about the same.
Drew: That's exactly what I was going to say. I thought you were doing some intentional foreshadowing!
Nate: I'm not sure I put that together before this conversation, but it clearly was an interest even then.
Drew: That's got to be a good thing if you're still pursuing an interest that you had as a kid. Before we dive deeper into that, I did want to ask about your military service. You're an Army veteran. What were you doing for the Army? Were you doing tech stuff for them as well?
Nate: I was. Yeah. So, after high school, I took two years to go serve a mission for my church, the Church of Jesus Christ of Latter-day Saints. I came back from that and I planned to go to school, but I realized I had no cash and my parents were not super wealthy. So I needed to find a way to fund college. I was working but I realized it was just going to be a really difficult path. So, I ultimately decided to join the Army. At the time they were offering some pretty nice bonuses for joining. What they don't tell you is that you're going to be in the field and deployed a lot. It's really hard to go to school when you are in the field (no internet access at that time). But I did get into a pretty technical MOS, or Military Occupational Specialty doing electronic warfare. They put us through all the schooling. I learned circuits and how to build them, how to maintain and troubleshoot them, which actually extended an interest that started in high school and middle school as well. I had taken circuits classes and pre-engineering courses during that time and was building my own communication circuits, and just experimenting with a lot of that stuff as a kid. It really was exactly what I wanted to do. I actually took a test when I was going through the process of joining the military called the DLAB (Defense Language Aptitude Battery), which is a language aptitude test. I thought at the time that maybe it would be good to be a linguist. Well, I failed that test. That was probably the best thing that happened because then I went full on into electronics. I maintained all of the equipment that our linguists and other folks in the intelligence community were using to do their jobs. This actually became a heavy influence for why I started the company we have today. When you get out there in the field, you realize pretty quickly that there's just not a single method that will get you connected. And so that really kind of stuck with me. For me, it was just a great opportunity to learn the technical aspects of communications but also the real world applications. You really got to see what worked well and what didn’t.
Drew: It sounds like overall it was a really positive experience.
Nate: Absolutely.
Drew: Was that kind of your first formal training, the stuff that they exposed you to there?
Nate: Yeah, and the curriculum was pretty stringent. There was a 66% attrition rate in fact. So if you started your class with three people, two of them weren't going to be there when you graduated. I think we started with six or seven people and about three of us graduated. A lot of the tests, you know, you could miss one question, but if you missed two, you were recycled. And if you got recycled twice, you were done. You had to go find a new MOS. It was tough. But, I did well. I graduated top of my class. I also went to school at every duty station. At that point in time, online school wasn't really a big thing. It wasn't available in a lot of places. So, I would take a class, but then I would end up out in the field. Then I'd spend two weeks trying to get caught up just to go back out in the field two weeks later. That didn't work so well. My second duty station was not a tactical unit. So, I had the opportunity to really go to school there. I would get up and do physical training at five in the morning, work all day, and then go to school between six and ten p.m. that night. I was trying to get my homework done during the day at lunchtime and things like that. For two years I did that and graduated with my associate's degree from ITT Technical Institute. They’ve now gone bankrupt. So there's no proof of that anymore! But, I did graduate as valedictorian from there. Ultimately I never did graduate with my bachelors. But, it just came to a point where I realized that I had the knowledge that I needed. I was very competitive with my peers. I managed people with bachelors and masters and PhDs. It's never held me back. I've always had a thirst for knowledge and an ability to go out and learn what I needed to learn.
Drew: Having gone through the experience of using the military for a lot of your formal education, would you have advice or thoughts that you would share with someone that was thinking about going that route?
Nate: At the end of the day, no matter what route you pick, you have to have a thirst for knowledge. No one can hand that to you. You can go through college and get good grades, but if you don't have a thirst for learning your learning will stop at that point. So, you have to have something that drives you from within. If you don't have that, I don't think it matters what path you pick. For me, the military route worked out. It gave me a way to gain a lot of real world experience and gain some technical knowledge. That worked for how I tend to operate in life. But I think there's other ways to do that, and I think they're just as valuable. But at the end of the day, no matter what, you have to have that passion.
Drew: Yeah, I couldn't agree more. I think it's all about figuring out how to self-educate and having the motivation to learn things on your own.
Nate: I would definitely say that about 90 percent of the stuff that I know today isn’t really taught in school. You just have to dive in and figure it out.
Drew: With technology, it's especially that way because of the rate at which things change.
Nate: The stuff you learn in school is a good foundation, but it's a foundation. That's it. You have to still build the walls. You do that by learning and diving into the things that are interesting to you.
Drew: So, let's switch over to Meshcomm and hear about that a little bit. What's the founding story? What gave you the idea? And how did you start the company?
Nate: Starting a business had always been one of those things in the back of my mind that I wanted to do at some point. For years, I tossed it around. But, I didn't know what I wanted to do. After I left the military, I did a lot of contracting work for the DOD. I ultimately took a job in Boulder, Colorado at a company called Freewave Technologies. Their main focus was building M2M (Machine to Machine) radio systems. It's kind of the pre-IoT era way of getting data out of the field. We worked with a lot of oil fields, weather stations, and that kind of stuff. That was really fascinating. One of the things that I noticed during my time there is that we could set up these point to point radio systems, but they became really expensive to maintain. Somebody had to go out on site and figure a bunch of stuff out before you could even sell anything. The whole time I was there, I just thought there had to be a better way. Well, about the same time, the technology for low earth orbit satellites and low bandwidth, low cost communications really started taking off. Companies like Swarm, Hiber, and Myriota were all starting to experiment with and deploy some of these technologies. I started thinking a lot about combining the ability to do satellite connectivity with something like cellular that is pretty available in a lot of areas, but not 100 percent available. If we could do that, somebody could just go out and deploy a system without worrying about connectivity. That's the premise that Meshcomm Engineering is founded on. So, I left Freewave and went to NetApp and worked there for a couple of years while I was starting to get Meshcomm off the ground. And then when we really started to see some traction and prove things out, I went full time on MeshComm. And so August of 2021 is when I went full time into Meshcomm Engineering.
Drew: Do you have co-founders?
Nate: Yeah, we originally started as a consulting firm with four co-founders and then over time not all the co-founders wanted to stick out the company. So, we bought two of them out. Scott Kenyon, my current co-founder and I, are the ones that are really pushing the company forward at this point.
Drew: So it sounds like from consulting, you've now gone in more of a product direction. Though, I imagine you still do a lot of integration work. Is that right?
Nate: Yeah, we are developing our own products. But there's a significant amount of integration that occurs as well. We typically integrate with somebody else's system. Those systems each tend to be somewhat different. While the core features are pretty standard, there are some unique things that do happen on individual systems. That's part of what we bring to the table when we start working with somebody. We can really solve a problem and not just try to fit a square peg into a round hole.
Drew: So one of the things I was curious about is how the satellite and cellular connectivity work together. Is it cellular first and then it fails over to satellite or how does that work?
Nate: Correct. And, we're actually still experimenting with this because some of the technology we're using is very new. But, that is the way things are architected at the moment. We will first search for a cellular network. We actually also have Wi-Fi available too. So we default to those two areas, Wi-Fi being the cheapest. So we'll try to connect there first. If cellular is available and Wi-Fi is not available, we'll fall back to cellular. And then if that's not available, then we'll fall back to satellite. It’s this least cost method of connectivity that we're trying to achieve. Satellite, even with all the advances, is still a relatively expensive route. So, we want to minimize satellite usage as much as possible.
Drew: I imagine you're not putting up your own satellites. Are you connecting to an existing constellation or something like that?
Nate: Yeah. Today we're using Inmarsat. There's other options that we're looking at for future product variants.
Drew: You mentioned there was a lot of growth in that space. And obviously there is. You hear all the time about this stuff these days.
Nate: Yeah, there’s lots of cool innovation happening on that side of things. One of the reasons why we're utilizing Inmarsat right now is it does have an advantage over certain other low Earth orbit constellations out there. We can get lower latency with Inmarsat. In the event that we need to send an alert out, we can get that alert out in a timely fashion instead of waiting for a satellite to pass overhead before you can finally get that data out.
Drew: I remember reading that kind of near real time performance is what you're targeting, right?
Nate: Yeah, not every application needs that. But, if you're in an environment and you're trying to alert for specific types of activities that could be detrimental to human life, for instance, a flash flood or something along those lines, you want to be able to make sure that alert gets out. You don't want to wait 15 minutes to send that alert because the next satellite pass isn't going to happen for another 15 minutes. You want to get that out immediately.
Drew: Right. So are you attaching some sort of off the shelf type hardware to an existing sensor and then adding your software to it? How does that all chain together?
Nate: It depends on the customer and their needs. Oftentimes the customer will have an existing sensor or system. But, they don't have a reliable way of getting the data out. So we work with them to integrate our platform and set up the specific types of alerts they want. Sometimes they ask us to provide a whole solution for something. So we've got the flexibility to go both ways on that. But, I think the sweet spot is really for us to work with somebody else. You know, we're not going to be experts in every domain out there. And so what we'd rather do is really work with somebody who's developing a system in this area that really just needs a reliable way of getting the data out. Maybe they want to do some analytics on the edge and combine that with some analytics in the cloud.
Drew: I was curious about a couple of the domains that you're working in. One of those is electric vehicle telematics. What are the questions that people are trying to use your system to answer about EVs?
Nate: Well, there's several different characteristics and it kind of depends on which type of electric vehicle. For us, it's electric tractors at the moment. And so, the questions are along the lines of if I'm utilizing the equipment with this particular implement and I'm pulling this much power out of the battery pack, how much usage am I going to be able to get? Can we predict that? Am I going to be able to complete the job before the battery dies? You don't want to let the tractor die in the middle of a field or you’ll have to tow it back to the shop. Charging infrastructure isn't as ubiquitous out in rural communities, so there's some things that have to be accounted for in that regard. There's also a lot of data about the tractor itself that the manufacturers want to know. For example, if a diagnostic is triggered, they want to understand what's going on, how it was triggered, and what are the events that led up to that? I think a lot of people don't realize that electric vehicles are fundamentally a digital platform first. They're not as much of a mechanical platform as traditional ICE (Internal Combustion Engine) vehicles are. Those vehicles have a lot of electronics, but they're a mechanical platform first. But there is a large amount of software that runs inside an electric vehicle. And, you know, companies want to be able to track and update different things that are happening on the vehicle.
Drew: So tractors themselves are agricultural, but I know you have a lot of other agricultural applications. What are some of those and what are some of the problems you're solving there?
Nate: This is something we're slowly moving into. We're not heavily involved in this area yet, but there are some initial applications that we're piloting right now in irrigation and well monitoring. Those are probably the two biggest ones that we're piloting at the moment. As part of that, we’re developing a more specific sensor platform for these more agricultural or environmental monitoring applications. That platform can be connected to many things like weather stations, irrigation systems, wells, and things like that.
Drew: Yeah, that's interesting. I've always had an interest in ag tech.
Nate: One of the first projects we did when we were still prototyping our systems was with a dairy farm. They needed to know how often the “push-up” operation was happening. If you're not familiar with dairy farming, the push-up operation is where they push the feed back up to where the cows can actually get to it. So, imagine a fence inside a barn and the cows are kind of on one side and they put the feed down right in front of the fence. The cows put their heads through the fence and eat. They push the feed around while they’re eating and eventually all the feed is out of reach. So, somebody has to come back and push the feed back up so they can get to it. We put a unit on the tractor they were using to do the push-up operation. And, we set up geofencing around the barn. We could tell when they entered the barn, we could tell when they left the barn, which direction they were headed, that kind of stuff. This project was done in partnership with another company who developed an algorithm that would actually alert the general manager of the farm if a push-up operation didn't occur when he was expecting it to occur.
Drew: I'm kind of amazed by some of the technology that exists on farms. People think about farms as being sort of low tech, but it's almost the opposite. I toured a farm once where they showed me their milking infrastructure and they had it basically fully automated. The cows knew to go to this one gate when they felt like they were ready to be milked. And, there was a sensor that would measure them and would either push them back out or bring them in to be milked.
Nate: Yeah, it really is crazy. The first time I went on a dairy farm, I was amazed. I thought the workers had to lead the cows from point to point to get them to do what they needed to do. They weren't doing that. They just opened a gate automatically and the cow would just go and follow a path and show up where they needed to show up.
Drew: I guess you and I initially connected over the fact that you use Rust. What was the path that led you to Rust?
Nate: So, Rust was definitely something that we discovered along the way. We did a lot of prototyping of our systems using Python. That might surprise people. It’s not really what you want to use for this, but Python is a great language. You can do a lot of stuff with it. But it has its weaknesses. We knew long term that we were never going to stick with Python. We were probably going to end up writing a lot of our code in C or C++. But, I had really some big concerns about that. Obviously, C and C++ are notorious for memory safety problems. When you're putting your product out on systems that are safety critical or where down time would cost a lot of money, you really need to be able to depend on it. Rust doesn't solve all of these problems, but it certainly gets you on the right path. And, it really forces you to write good code. So, I ran across Rust in the process of figuring out what to use. At first I wasn’t sure if all the claims were true. It was kind of a new language, and I wasn’t sure if it was even mature enough for me to use. So I had to go answer all of those questions for myself. After a few months worth of research, we decided Rust was really going to work for us. And, there's definitely a learning curve associated with Rust. It's not one of those languages that you just pick up in two weeks. But I would absolutely hands down say that our code base is much more maintainable and reliable because of the fact that we moved to Rust.
Drew: You hit kind of the main things that you hear over and over again about why people pick up Rust. And, it just makes a ton of sense for your particular use case.
Nate: Yeah, it really does. You know, a lot of our applications are threaded. We're doing a lot of concurrent operations. So, you've got to be able to handle things safely. It just really made sense to utilize the features that Rust has for that. We basically needed the safety from Python and the performance from C++. That was ultimately the deciding factor as to why we moved forward with Rust.
Drew: When we initially talked, you said you have Rust running on the edge. Do you have it elsewhere as well?
Nate: At the moment, it's on the edge on our embedded devices only. We ultimately will be moving the software that we have running in the cloud also to Rust. But, we're a small company, so we have to take things one step at a time. Though, I’m really excited for the day when we can do that.
Drew: So, those pieces are Python still, I guess.
Nate: Yeah, a lot of it's Python. Obviously, the web front end, we've got a lot of JavaScript and stuff like that running as well.
Drew: I can relate. We have tons of stuff we'd like to put in Rust. But, when you have something that's working and doesn't necessarily need Rust right at the moment, you have to make a careful decision about the investment.
Nate: Yeah, moving to rust is not a is not a zero cost game, right? And, it definitely takes a little bit of time to get your skills up to where you can write good code. But the benefits on the other side are really good.
Drew: So, zooming out a little, I wanted to give you the chance to give some of your vision. What does the future hold for Meshcomm Engineering?
Nate: Well, we started the company with the idea that we wanted to solve complex human and environmental challenges. We wanted a company that really put the employee first, and that put customers' problems at the forefront. Now we're at a point where we're really starting to scale that. We have some unique new opportunities in environmental monitoring coming up. For example, we’re working to help reduce carbon emissions in the mining industry. I would have been so excited if you told me we’d be working on this stuff even just two years ago. The idea here is that we really just want to leave the world in a better place than when we found it.
Drew: Since you mentioned the thought experiment of talking to yourself from the past. What's the journey been like mentally and emotionally?
Nate: I think it's probably similar to what many founders go through. You have your highs and you have your lows. And there are days where I’ve felt like, man, what am I doing? Why am I doing this? Why is it me that has decided that this is the challenge that I needed to take on? And there have been points where I kind of felt like, no, maybe this isn't worth it. Maybe I need to walk away from this. But I go back to asking myself why we are doing this. And, I’m reminded of the good things. We've had really awesome opportunities to involve my kids in the process of building some of the units as we send them out to customers. We’ve worked with local high schools and colleges for internships. We have incredible customers. Those are things that I think are super valuable and have allowed us to not only grow the business but also be able to give back to the community. Ultimately, there's a lot of good. And, that's what keeps me going.
Drew: I think that’s important to find ways to give back along the way and bring positivity in so that you don't get disheartened by the inevitable setbacks.
Drew: We've talked about your nonprofit work a bit. I wanted to give you a chance to talk about that. So what is Bunker Labs and what do you do with them?
Nate: Bunker Labs is a nonprofit organization set up to help veteran entrepreneurs. I learned about them while I was looking for some help with our business a couple of years ago. When you start a business, there's a pretty steep learning curve, and I realized that we needed to reach out and start finding some other resources to help us. During that time, I ran across Bunker Labs and applied for their Veterans in Residence program. I got into it in July 2022 and really gained a lot out of it. Once we graduated from that program and moved on, I wanted to be able to give back to the same community. So, I started volunteering with them the following year. I'm currently one of the Denver Ambassadors for the local Veterans in Residence program. That has been a really, really awesome experience to work with other veterans and offer insight and encouragement to others based on my own learning.
Drew: So lastly, is there anything you wish that we had talked about?
Nate: I'll put a shameless plug in that Bunker Labs has a showcase in Denver on December 8th, 2023 for the current cohort. It's at The Commons on Champa, from 5-7 PM. Anybody who’d like to attend is welcome. I’m also always willing to chat with people who are looking to start a business and might want some help or advice.
Drew: If there's anything I've learned about you from our little bit of interaction, it's that you're always trying to serve. I really appreciate that.
Nate: Thank you!
Drew: No, thank you.
Know someone we should interview? Let us know: filtra@filtra.io