SimpleBLE & Lessons from Neuralink | Mr. Beacon Podcast

Table of Contents

1. Introduction
2. Introduction to SimpleBLE
3. Challenges in Bluetooth Development
4. SimpleBLE as a Solution
5. Functionalities and Use Cases
6. Industry Examples
7. Central and Peripheral Modes
8. SimpleBLE's Business Model
9. The Future of Open Source
10. Kevin's Neuralink Experience
11. Technical Requirements at Neuralink
12. Neuralink Job Application Process
13. Bluetooth in Neural Implants
14. High-Performance Team Methodology

---

Introduction

Host: Welcome to the Mr. Beacon podcast. This week we have an amazing, unexpected conversation where we explore the questions: what's it like to work for Elon Musk? How do his companies achieve so much with so few people in such a short amount of time? And how do you get Bluetooth to work inside someone's body as part of the Neuralink system?

This is actually not the main subject of the podcast; it's kind of a gem that I fell upon in my conversation with Kevin Dewald, who's the founder and principal at SimpleBLE. I agreed to interview him, was approached by him and his team, and what he's working on is a really cool project for anyone that's building Bluetooth Low Energy systems. SimpleBLE offers a great way of getting things done faster, and it leverages the experience that Kevin got working as part of the Neuralink team, fusing the sensing and motor functions from human beings with Bluetooth.

I love this you go into a conversation, you expect one thing, and you get something completely different. It's one of the reasons why I love doing this podcast. This is kind of a bit of an Easter egg in the interview. The first part of our interview does focus on SimpleBLE, which if you're a geek and interested in Ambient Internet of Things and how to connect the physical world to AI and the cloud, that'll be of interest. If you are fixated on how Elon Musk runs his companies and how Neuralink works, then you'll need to fast forward into the second part of the podcast to get that.

In the meantime, I'm enjoying my life post-Wiliot. Wiliot was a wonderful company pushing back the boundaries of battery-free Bluetooth technology, and I left it after almost 8 years to start Ambi. Things are going well, tons of people engaging us about this AI app and network. We're fundraising if any of you have contacts in the VC community that you think would be interested in fusing the real world with LLMs and making AI omniscient, understanding everything everywhere all at once, then point me at them or point them at me.

That's it. I'll let you listen to the conversation with Kevin. It's a great one, including his music selections, his three songs that have special meaning to him. So do stay till the end, and thanks for listening.

Host: So Kevin, welcome to the podcast. It's great to have you on.

Kevin: Oh, thank you for having me.

Host: I noted that your marketing budget is... well, what was it? A sandwich and a paper?

Kevin: Three bucks, yeah.

Host: Three bucks, yeah. Very good. Well, I'm pleased to be part of that. Let's do our bit and ask you to tell us: what is SimpleBLE? What's the company that you're heading up?

Introduction to SimpleBLE

Kevin Dewald introduces SimpleBLE, a project he started almost five years ago, to simplify Bluetooth low-energy development, especially for cross-platform systems (0:56-1:07).

Kevin: Yeah, so this is a project that started almost five years ago at this point. To give a bit of background, I've worked with Bluetooth since I was a college student because it's a great protocol; you can do great things with it. Unfortunately, what happened was that every time I wanted to develop something with it, I was running into some limitations around the availability of good software libraries to use Bluetooth, in particular when it came to desktop environments. There were no good solutions around it, and most of the ones I could find online were either abandoned or in the process of being abandoned, or wouldn't use the technologies I needed them to use. Most of my programming is C/C++, and there were no good libraries that were also cross-platform and would be helpful. There was basically none of that. After dealing with these problems for so long, I decided, "Okay, you know what? I'm doing it myself. I know what I want, I know what I need, and I'm going to start working with that."

Host: I think so much of what entrepreneurs do is that it's like frustration. The world should be this way, it's not, no one else is going to fix it, I guess it's going to be me. I'm going to do it.

Kevin: Correct. I mean, yes, and that's how it started. It's not a project that was born out of love; it was born out of spite. It's like, it can't be that something this simple is so complicated. It just can't. It drove me crazy. And yeah, it took a lot of effort. The initial implementation was Linux-only. I had done some past attempts as part of one of my previous jobs, but the whole vision was born a bit after that. The goal here was mainly to think: what are the reasonable use cases you would have for Bluetooth? Basically scanning for devices, connecting, interacting with services and characteristics, and having a simple way of doing it without having to worry about all the abstractions of the operating system.

Challenges in Bluetooth Development

Kevin explains the difficulties of different Bluetooth implementations across various operating systems like Linux, Mac OS, and Windows (6:00-6:45). He highlights the complexity arising from different API and architectural layers.

Every OS implements it differently, not only at the API layer but also the architectural layer is a little bit different. For example, Linux has this concept of an adapter and a peripheral, and the adapter connects to the peripheral. On macOS, for example, you have the adapter, you scan, you find peripherals, but then you tell the adapter, "Hey, connect to this peripheral." The notification that the peripheral successfully connected comes from the adapter as well, not from the peripheral. Windows as well has its own mess around WinRT, and every OS has its own layer of abstractions around that. The way they implement it is completely different. It didn't seem and for me it was like, "Okay, there's no reason for this to be so hard. There has to be an easier way to deal with this."

SimpleBLE as a Solution

SimpleBLE's core aim is to provide a unified, simple API that abstracts away OS complexities, making it easier for developers to handle Bluetooth tasks like searching, connecting, and interacting with devices (7:00-7:13).

In the end, it was just about: let's design the API first, let's think about what I need as a user, and then handle all the painful abstractions in the backend to make it completely transparent. Again, this was a project that I was doing for myself to help me at work, solving my own need. But interestingly, I wasn't the only one. More people started getting involved, and it became a thing. If you're looking for a cross-platform library, especially for desktop, we're the only ones actively maintained right now.

Functionalities and Use Cases

SimpleBLE supports multiple platforms (Linux, Windows, Mac OS, iOS, Android coming soon) and offers bindings for various programming languages (C++, C, Python, JVM) (7:40-8:00). The primary audience includes companies building SDKs for their products that need consistent Bluetooth communication across different platforms (11:00-12:02).

We have Linux, Windows, macOS, iOS; we're finishing Android support. We have bindings for C++, C, Python; we're adding bindings for JVM and thinking about expanding to more languages. It's only because we thought about this very thoroughly early on that we designed a very simple API where everything else can be built upon easily. One thing I did notice is that engineers, when they're building products, usually push complexity to the user. "I don't want to have to deal with this, so I'm just going to give you all the options and you figure it out." In reality, I think that's actually a bad thing because turns out 80-90% of use cases would work pretty well with sensible defaults. You just need to think what those are, which is not a trivial task. Once you have a very simple thing that everybody can understand and use, adoption becomes easy.

Host: It seems like one of the things that you bring is uniformity, consistency across different operating systems. What are the potential users or customers for this?

Kevin: I think the sweet spot comes when you, as a company, are building an SDK for your product. Right now, most companies that build Bluetooth products are only focused on mobile, so they have to maintain an Android version and an iOS version of the SDK. You can tell by using both apps they're different codebases, and sometimes features available in one are not in the other. If you just integrate the communication part into your library and then handle everything else, it becomes a lot easier. That's the primary use case generalizing that logic. But also, this opens up the possibility of using your device on a computer. You can now have a desktop app, more powerful use cases. There's an interesting example: Nordic Semi. All their firmware upgrade (DFU) libraries are built separately as Android and iOS packages. If you use their client on desktop, it doesn't work; you have to get a specially flashed adapter. One of our early-stage products is to package this so your device just works on desktop. Why is the desktop environment so neglected? I think because it's hard to do these kinds of things.

Host: And who's using it? Any specific examples?

Kevin: There are quite a few medical device companies using it. That shocked me the most by year four, I realized, "Oh crap, there's a lot of companies using this for medical devices." Also entertainment, security (scanning passports), automotive. On the website, you can see Fender.

Industry Examples

Examples of SimpleBLE's use in medical devices, entertainment (Fender), security, and automotive are mentioned (14:23-14:40). Fender's success with SimpleBLE for their amplifiers highlights how the tool allows musicians to focus on music creation rather than Bluetooth complexities (15:07-15:34).

Host: Fender! What do they use it for?

Kevin: It's for one of their amplifiers. They've been very happy because they're musicians first, engineers second. They care about building great musical products. For them, Bluetooth is just a thing they need solved. They don't want to spend months maintaining multiple apps.

Host: Tell me a bit more about the facilities you offer. You use a word familiar to BLE experts: GATT. What's GATT?

Kevin: GATT is the Generic Attribute Profile. Basically, the way Bluetooth works is when you connect to a device, you present a series of services and characteristics. Think of them as endpoints or URLs where you can interact and send data. For example, a heart rate monitor has a service for heart rate features, and one characteristic is the heart rate value itself. For standard services, the units are already defined, so your phone's health app can automatically grab the data and show it to you.

Central and Peripheral Modes

Kevin differentiates between central mode (the device initiating and controlling the connection, like a phone connecting to a heart rate monitor) and peripheral mode (the device accepting connections and offering services, like a heart rate monitor or a Bluetooth beacon) (17:43-20:01).

Host: And what is Central mode vs. Peripheral mode?

Kevin: Central mode is when the device you're operating initiates the connection. The central device sets the timing for communications. Peripheral mode is the other side the device that accepts connections and provides a service, like the heart rate monitor. The main difference is that as a central, you expect services to be provided to you, while as a peripheral, you are the one presenting them to the world.

Host: So a Bluetooth beacon is an example of a peripheral?

Kevin: Correct. A beacon is a peripheral where you usually don't connect to it; you only rely on the advertising process to exchange information.

SimpleBLE's Business Model

Kevin discusses the transition from an open-source project to a commercial model to ensure sustainability and quality. He explains that monetization allowed for more resources and time to be dedicated to the project, leading to significant improvements and the addition of new features (22:25-23:44).

Host: I noticed you offer consulting as well as licensing. How did you decide to package and price that?

Kevin: SimpleBLE started as a fully open-source project. Once I left Neuralink and switched to a company not focused on embedded devices, my focus on SimpleBLE faded. Quality started to decay. A friend suggested, "Usually if you get paid to do something, you'll feel more motivated." So I switched the license to be more restricted for commercial use. It's been an interesting journey. SimpleBLE is not a big software corporation; it's more like your corner bakery handmade, organic. The commercial offering allowed us to bring people in part-time. This past year, we dedicated almost another thousand hours of work thanks to companies that trusted us. Consulting was something we threw on top. We have two tiers: SimpleBLE Consulting (integrating the library) and Advanced (research, reverse engineering APIs). Revenue-wise, it's been about half and half. Ideally, I'd like to focus more on licensing because it's more stable. We have a startup tier that is free the idea is for you to get used to it, and as the company grows, we have tiers that follow that growth.

The Future of Open Source

Kevin shares his insights on the future of open source, predicting a trend toward commercialization for more niche projects. He argues that this commercialization is crucial for the survival of niche open-source projects that don't attract sponsorship from large companies (26:51-28:20).

Host: Any observations on where open source is headed?

Kevin: It's definitely not static. One recent trend is more projects going the commercial route, and I think that's positive. For niche projects like SimpleBLE, there isn't enough interest from large companies (Microsoft, Google) to sponsor them. Their bottom line isn't affected. Because of that, lots of projects end up as "abandonware." We found around 60% of similar projects have been abandoned for more than a year. Unless they find funding, they die out. Our parent company, the California Open Source Company, aims to help projects go from fully open source to commercial so developers can manifest their vision.

Host: Kevin, I'm interested in your connection with Argentina. Did you spend your entire early life there?

Kevin: Yes, I was born there in 1991. I graduated high school and university there, then moved to the US just before the pandemic. It's been an interesting journey from "humble beginnings" to being involved in cool things happening all over the world.

Host: What was it like seeing the Silicon Valley ecosystem from afar?

Kevin: It's a very different experience actually living here. It's still a weird thought to drive past Facebook or Oracle. You recognize the brands that seemed so far away. If you're born here, you don't understand what a privileged position it is to be close to where things happen. Seeing autonomous robots on the street they're not just a video clip; they're there. It still blows my mind after four years.

Host: Was it difficult to get into the States?

Kevin: I was lucky. A project from my first startup ended up being the hook. I found a company in 2020 building the same thing and reached out to the CEO/CTO: "I know exactly what you're building, I have the expertise, bring me over." There are interesting visa programs, especially collaborating with universities. I was helping as a guide for practical assignments at UMass Boston while working for the startup.

Host: What was your first startup working on?

Kevin: Measuring electrical signals from the forearm to recognize hand gestures (up, down, open, close). Despite the technology being available, there haven't been many commercial deployments. Meta has been pushing it after buying the IP from a company called Myo. The company I joined in the US was doing something similar but measuring signals at the wrist.

Kevin's Neuralink Experience

Kevin's experience working at Neuralink is highlighted, addressing questions about Elon Musk's work culture and how his companies achieve impressive results with small teams (0:09-0:19).

Host: This seems like it put you on a trajectory to work at Neuralink.

Kevin: Yes. Most of my experience has been embedded devices, Bluetooth, and biological signal processing. Neuralink liked that I was a "good generalist" who wasn't afraid of difficult problems.

Technical Requirements at Neuralink

Kevin emphasizes the necessity for Neuralink engineers to have broad knowledge across various fields such as RF, control systems, biosignal processing, statistics, electromagnetism, and thermodynamics (43:53-44:39).

To work on a brain implant, you need to understand RF, control systems, signal processing, statistics, physics, electromagnetism. You don't have to be totally proficient, but you have to be "conversational" in all those topics.

Neuralink Job Application Process

Kevin describes the rigorous interview process, including a practical weekend assignment that required designing a temperature sensor driver while accounting for potential hardware failure modes in a safety-critical scenario (47:50-51:41).

Host: How did you get the job?

Kevin: I applied online! I knew nobody there. A friend told me they were recruiting embedded engineers. I applied, had a call with my boss, and then did a practical assignment over a full weekend. It ended up being thousands of lines of code and 12 pages of documentation. Then more interviews, meeting the team, and I started just after the "Three Little Pigs" demo in September 2020. The assignment was: "Here's a temperature sensor; write a driver for it." But the constraint was that it's a safety-critical scenario where hardware can fail. You have to think through all possible failure modes and how the software can detect and mitigate them. Any fresh grad can write a driver, but what sets candidates apart is how far they think along those lines.

Host: What did you end up doing at Neuralink?

Kevin: Embedded systems engineer for the implant. I worked on the code running within the implant and the tooling around it. There's a lot of testing required. I was involved in the entire lifetime of an implant from manufacturing to destructive testing. You have to test at scale to find rare failure modes (like 1 in 10,000).

Bluetooth in Neural Implants

The challenge of making Bluetooth work inside the human body is discussed, highlighting the importance of antenna design to overcome signal attenuation issues in tissue (52:50-53:50).

Host: Were you working with Bluetooth there?

Kevin: Yes. The idea is for the implant to be the "Fitbit for the brain," and Bluetooth is the only protocol that is power-efficient with enough throughput.

Host: But Bluetooth frequency doesn't go through flesh well. How do you overcome that?

Kevin: Making sure the antenna points out, not in! The team that designed the antenna is out of this world. Antenna design is like magic or alchemy.

High-Performance Team Methodology

Kevin explains that Elon Musk's companies achieve high productivity due to small, focused teams, simple communication, clear responsibilities, and a shared overarching goal that guides all decisions (57:49-58:20).

Host: How does the team get so much done? Elon's projects seem to do the impossible.

Kevin: Two factors: 1) Hiring people where the "skill to ego ratio" is much greater than one. You want smart people who are easy to work with and can admit when they're wrong. 2) Personal accountability. A specific person is responsible for a component, not a "team." If something breaks, you know who to go to. This avoids diluting responsibility. We would have a huge problem, everybody would focus on it, and in two weeks it was a done deal.

Host: What about project methodology? Sprints?

Kevin: Not much structure. Just one-on-ones with the manager. There was a global priority: "We need to get to human." Every decision was filtered by that. If what you were doing didn't help achieve that goal, you should be doing something else.

Host: Did you meet Elon?

Kevin: Yes, at several meetings. He's very tall! As a boss, he's very reasonable a "non-bullshit" person. He'll ask, "Have you thought about this?" He sets ambitious goals asking for a 4-month project in 2 months. You might not get it in 2, but you get it in 3 because of that forcing function.

Host: We need to talk about your three songs. What's the first one?

Kevin: A song by Essa the cover song Neuralink used for their first promotional video. I played that video over and over before joining. It was a reminder that "I made it." My engineering skills improved so much being surrounded by those people.

Host: Song number two?

Kevin: "Something Just Like This." That's the song that made me realize I wanted to propose to my wife. I was on a trip, friends told me I was an idiot and should just propose. I heard that song at a hotel and it clicked. We've been married 5 years now and have a 7-month-old daughter.

Host: And song number three?

Kevin: "Basket Case" by Green Day. It symbolizes my "crazy nature" always wanting to do things. I've developed a very direct, "brutal honesty" approach. I don't like things sugarcoated. I mentor startups and sometimes have to tell them, "Your idea sucks." Some people like it, some don't.

Host: Kevin, this has been wonderful. Thanks very much for coming on the show.

Kevin: Thank you very much.

Host: Thanks for watching the Mr. Beacon podcast. Subscribe for more!