The Amp Hour #603 - An Interview with Ray Ozzie (Blues Wireless)

I'm very well, thank you. Good to be here, Chris.

Absolutely. I mean, what it is is a very small cellular module. Somebody might look at it and say it's just a modem, but really it's a new composition of function that is supposed to enable developers, hardware engineers, firmware engineers, to treat cellular as a data pipe, as opposed to the mystical nature of what it is right now. Currently, people have to deal with AT commands and crazy things.

Exactly. I had a personal experience with a non-profit post-Fukushima that gave me a much closer to the metal understanding of the impediments to this cellular IoT future that we've been talking about for so long. I took it upon myself to ask what we could do if there were no limits, no constraints, to make things easy for developers. Both designed for scale, economic scale, manageability, but make it very easy for hardware developers to put a cellular data pipe into their designs, so that all they had to think about was what they were building and what kind of data needed to be sent to the cloud. Inject it into this little data pump.

Well, people want a very simple analogy. I think if you spoke to any of the developers who've used it, it kind of fulfills that promise. You have to worry about what kind of device you're building, what you're going to do on the cloud side with the data when it comes in, but what you inject into the Notecard via I2C or USB or UART appears in your cloud, and there's very little you have to manage in between. It's an infrastructure-as-a-service product that's supposed to be something that hopefully developers will grow to love.

Absolutely, at the very beginning. In March 2011, many people in the tech industry, and outside, wanted to help after the natural disaster. A group of about 30 people gathered in Tokyo the first week of April 2011 to decide what we could do. At the time, a week or two after the meltdowns, people were being relocated without being told why. People throughout Japan and the world were wondering if they were safe, and there were no numbers being released. The government and TEPCO had their hands full. We concluded the best thing we could do was to measure data and publish both the way we measured it and the data itself, without saying if it was safe or not, but as open data that let people who knew what they were doing help citizens understand the threat. Initially, we went to Akihabara, got a commercial GPS unit, used someone's laptop, borrowed a commercial Geiger counter, and drove through the exclusion zone, covering as much territory as possible, correlating time, location, and radiation readings. We published them in little segments we called journeys or trips. By uploading those segments from SD cards to a map, it started to take shape. You can go to safecast.org today and see that a plume had gone north-northwest from the plant. Sadly, people were relocated from safe areas to unsafe areas because they didn't have that big picture. So we set it up as a non-profit, sustainable based on citizen data, to set a baseline elsewhere outside Japan so that if something ever happens again, we have a baseline and are prepared to deploy devices and know-how.

I had done hardware probably from 10 years old through college. I was a double E major at the University of Illinois, but I switched to software early on. I hadn't soldered a thing until the first months after we started. The initial things we tried to build were based on simple SparkFun, Adafruit, Seeed Studio modules, like the SIMCom 800s. At the very beginning, there was no cellular service in the area, so we recorded data on SD cards. The first wireless devices tried LoRa. I built a LoRa concentrator based on what was at the time resin.io, now Balena, managing Raspberry Pis. Then we built these things called Solarcast boxes, which were solar-powered with dual particle counters for air quality, dual Geiger counters, and LoRa backhaul. We were fortunate to get these devices into the exclusion zone once a year, when people who were sent away were allowed to visit their homes. Initially, we backhauled by LoRa, but as cellular service came up, we looked forward to that because building your own LoRa network can be challenging. I went for Adafruit FONA modules, which worked really well on 3G. The challenge was that every time we tried to build a prototype, we could never meet the current budget goals based on the solar panels. We had beautiful Voltaic solar panels generating a lot of energy and nice battery packs, but cellular, whether 2G or 3G, was probably a two-amp pulse. GSM is unforgiving. You didn't know what network you'd hop onto. So I stepped back and said, how hard can this be? I started with a Nordic nRF51 chip, thinking if someone's doing Bluetooth, they must have a decent firmware stack to let the firmware sleep. I started dealing with PSM on the modules, realizing it was a pain and I couldn't achieve the current budget in the datasheet. So I just stuck a low-side N-channel MOSFET in there to shut the power off to the whole modem. Then we had to write firmware to measure the voltage in the pack, modify the measurement frequency and upload frequency based on available power. Eventually, we ended up with a really great device that operated standalone and was very reliable over time. But it was a real learning experience because I didn't understand the complexity of doing well what I was familiar with: state machines, controlling sensors, controlling cellular, realizing this was going to be a multi-module world. Just because we could deploy a module in one region didn't mean it worked in another. The AT commands were different for each one. The carriers required PTCRB certification, which brought different challenges. The cellular plans required dealing with local carriers and temporary roaming, whereas we wanted permanent roaming. Many different challenges. The Notecard really emerged from that project: the concept of making a completely different developer experience, both hardware and software, where a hardware developer could not worry about cellular data plans. They could get a cellular card from a distributor like DigiKey, Mouser, Avnet, treat cloud connectivity as part of their BOM, and just assume that as soon as they plugged it in, it would work, auto self-provision, and be good for 10 years, working anywhere there's coverage in 137 countries.

Sure. In 2005, one of my startups was bought by Microsoft. Bill Gates, who I've known since probably 1982, told me he was thinking of leaving to start a foundation with Melinda and wanted to devote full time to it. He asked if I would take over his role. His concept was that I would divide his job with another guy, Craig Mundie. Craig would take over all external-facing aspects of his job, and I would give inward guidance to the development teams and try to steer the company forward. My view at the time was that the biggest challenge Microsoft had was that it was a box company—servers, Xboxes, PC operating systems—and it had to shift to a world of services. So I took over Bill's job as Chief Software Architect and tried to shift the course of the supertanker by a few good degrees. That laid the groundwork for many of the things you see today that are connected versions of what in the past were not connected. I had a pretty direct role in initiating the Azure project.

It depends on your personality. Bill would fly from country to country, meet with ministers, deal with customers. I am an engineer, a little more on the introverted side, so I enjoyed myself.

It was a pretty surreal experience for me because I'd spent most of my career competing with Microsoft. I entered the industry in the late 70s, starting in operating system development at Data General. I saw the microcomputer thing was going to be something, so I went to a small company in Cambridge called Software Arts, about 29 or 30 people at the time. They worked on a product called VisiCalc. My first job there was porting VisiCalc to the TRS-80 Model 3.

No, it wasn't. I started programming back in 1969 on a GE 400 mainframe. In college, I was an electronic technician in the Department of Nuclear Engineering, building little devices for grad students. One guy brought in an Intel 4004, then 8080, and we would have so much fun integrating them into experiments. It was all assembly language, no OS, just bootstrapping it. I did that for the Model 3, which was a Z80. After I left school, I wanted to start a company with my friends to do something that hadn't been seen: a collaboration system where computers were used as communication terminals. But we were still in a microcomputer era with no networking. My previous boss and friend started a company with Mitch Kapor called Lotus, trying to take down VisiCalc. They tried to convince me to go there, but I said no, I want to do the startup. They said if you just do one version of what was then called Lotus 1-2-3 for us—the development group was about eight people—then we will get you funded to do what you really want. So I went to Lotus and did a product called Symphony, about a quarter million lines of assembly language. Three of us did it in nine months from first day to ship. After that, Mitch followed through on his commitment and said how can we get you set up with your startup? So I started a company with my buddies called Iris Associates, and we started working on what eventually became Lotus Notes.

It was an amazing experience. With Lotus Notes, this was at the dawn of local area networking. 3Com had just come out with the Ethernet card, IBM had Token Ring. It was tremendous. We had no idea what we were doing, didn't know how to sell it. Lotus didn't understand enterprise because it was an era of shrink-wrapped software. Eventually, after 10 years, we were acquired by Lotus, then Lotus was swallowed by IBM. When I left, it was probably 120 million users. We were competing head to head with Microsoft Exchange. We took half the market, they took half. We won all of the Global 2000, they won most small to medium business. Eventually they ate up the whole thing. But the point is, even though I'd known Gates and Ballmer from the VisiCalc days—Microsoft was only 30 people at the time—they were the enemy. After I did another startup, Groove, and they bought that, I was the enemy. So it was like, let's say Bill Gates is a philanthropist now with a soft image, and the Ray Ozzie I've met is very kind. Was there a past version of Ray that was also very cutthroat? Was this endemic to the 90s, with pleated khakis and hatred for your enemy?

No, the old Ray is the current Ray. I hope. Find people who work for me, they'd probably confirm the same. Anybody who is in a position of incredible success, surrounded by people telling you how smart you are, and is asked to keynote CES and this and that, you grow. Bill had to scale at a personal level, from being the techie CEO of a 30-person startup to somebody who had 70, 80, 90,000 people reporting to him in a cutthroat competitive environment. Lotus had 1-2-3, we wanted to take Excel down. It was very competitive. Bill is one of these rare individuals who understood technology, business, customers, and market, and could foresee how to mix those to create a big company. Companies led by pure techies or pure sales people lost over time. By the time I got to Microsoft, the culture was very divisionalized with a lot of internal competition. Trying to shift that company towards services was challenging, but obviously many people stepped up, and that's why the company is what it is today.

What helped for me and my co-founders at Iris was we had a picture from something we dealt with in college called PLATO. We had a tiny peek of what it was like to have thousands or tens of thousands of users using a single system, creating interactive games, building chat tools, electronic forums. We had this picture of the end game in our minds in the early 70s, well before the internet. When we left, we all went to system software shops. We worked on operating systems, honed our skills in complex code and source management techniques. We knew what the end game was. Pre-internet, the only way to create a virtual image of a unified system worldwide was to weave together distributed systems. The best thing out there was UUCP, a Unix-to-Unix copy program that would dial up a phone periodically and swap newsgroups. When you looked at newsgroups or mail, you had this visualization of a unified chunk of data. With Lotus Notes, we built a system that used PCs as servers and clients, modems at 1200 or 2400 baud, dialing each other. We built what today you call a NoSQL database, doing bi-directional synchronization over phone lines. The end user had this view of what was going on throughout their organization. There were other efforts like bulletin board systems and FidoNet.

It's easy to say it must have been cool back then. I'll counter with two things. Number one, it was also extremely frustrating because there were many impediments, and things took much longer to mature. You knew where it was going but not how to get there. For example, one of the biggest impediments to getting Lotus Notes deployed in big offices like Merrill Lynch was that it was a union job to drill holes in the walls. It took them 18 months just to get the LAN installed. There were all these impediments. Today we're standing on the shoulders of each previous generation of technology. Every time in my career has been the best of times and the worst of times. Right now, there is so much opportunity to innovate. I hadn't coded since 1996 because of leading a company. I stopped coding until Safecast.

Some people decide to make that choice. Dave Cutler at Microsoft is older than me and still probably the first one at work every day, working on the Xbox kernel. If you decide to stay technical, you can. But I made the choice to move on and didn't code again until Safecast. When I started working on the Notecard, it was working on something by yourself for two years before bringing other people in. It was so great. The very first thing I did was start with a Raspberry Pi or BeagleBone to mock things up at a high level. I knew I wanted to make a little card, so I picked a processor: the STM32L4+ or L4R5, with 640K of RAM and 2MB of flash, a simple RTOS. It was exactly the computer I was programming on when I stopped programming. 640K memory, different memory and battery requirements, but it was like going home again. I was using Emacs and make, just what I did then. Each of us has to find our own balance. I learned about myself that I could not have a happy week unless I did something that made me feel I was having a broad impact on something, and I could not be happy unless I was close to the metal on something. At Microsoft, I had my labs and people reporting to me doing projects like Azure and Live Mesh. I was scratching an itch I couldn't find some other way to realize, and the rest of the time trying to recruit others to a services-centric vision.

That is a really good question. I can tell you what it was like for me. From a very early stage, in college, I was fortunate to be exposed to and eventually work for what I would call a creative eccentric: someone a little nuts, somewhat of a magician, a salesperson, and a deep engineer. The first was Don Bitzer. I'm a Computer History Museum fellow, and I'm inducting him on October 14th. He had this vision in 1968 of how computers could change the art of teaching. He recruited a bunch of people. Every time he found a technical roadblock, being an engineer and physicist, he found a way past it. For example, storage was incredibly expensive, and the only way to get an image on a terminal was to use a storage tube. He envisioned thousands of students using graphics terminals, so he invented the plasma panel. PLATO terminals had 512x512 individually addressable dots, an integrated modem, a film projector with 256 slides, synchronized audio. He had this vision and inspired people by telling stories. I was young and wanted to be like this person because he could accomplish anything. As my career progressed, I gravitated toward these people. I met Doug Engelbart and J.C.R. Licklider, who had romantic visions of the future. My recommendation is you can't become that person overnight, but the more you put yourself in a situation where you support a risk taker, realize their vision, and see how they balance execution and promotion, you learn. You have to do something outside your comfort zone: speaking in front of people, raising money. The best part is feeling like you're part of an exciting journey. Attach yourself to those people, and you will become them.

Exactly.

Let me step back. What amazed me when working on the Safecast project was that, having developed Azure and brought early enterprise customers onto it, I knew what IoT was. At the time we called it M2M. When I started working hands-on at Safecast, I realized that all these people talking about billions or hundreds of billions of devices weren't insane. If you have a clear understanding of technology evolution, you can draw a line to where it will ultimately be. Imagine if the world was born that way, what potential solutions might look like. It was clear that Masayoshi Son, the crazy guy leading SoftBank, talked about a trillion IoT device future. It hasn't happened, but that doesn't mean he's wrong. I started to look at the impediments. My passion is not on the consumer side; I think a lot of people are doing good and not-so-great things, creating complexity we don't need. On the commercial side, I believe there is immense value in maintaining a connection to the customer, giving them feedback about how their product is working over time, even in areas with multi-tiered distribution. Everything you look at outside—a generator, a propane tank, a stoplight—will be cloud connected. I am trying to enable that future. We are concentrating on the communication domain. If we can help people focus on what they're trying to build and create this little embeddable data pump economically, not abuse it, we can get their trust. AWS has shown you can build a great business around simple infrastructure. If you treat developers well and solve their problems, you can maintain their trust. With Blues, we are solving a real problem: getting devices connected by cellular very easily. I believe you have to understand developers to build something they love. You can tell the difference: if a site says 'click for pricing,' it's not developer-focused. You want to show empathy for the journey the developer must go through. At the same time, we approach product managers in large companies with 10,000 to 100,000 unit potential deployments, showing them economically, from a security and sustainability standpoint, that betting on us is the best way to accomplish what they need.

In the early days of IoT, many people talked about coupling this to a subscription model for classic products. What we've found is that many people prototyped with ESP32s or Wi-Fi, but it didn't work out for one reason or another. They couldn't figure out how to modify the business model. The majority of people we deal with now realize they just need to embed connectivity into the base BOM and price of the product. They deliver better features to customers as a side effect. For example, a large-scale manufacturer of refrigerators can offer, at very little marginal cost, knowledge of whether food will go bad due to a power failure. If you don't have this grand transformation idea, you can make very material, small, incremental positive changes. If you buy a propane tank, you can know when it's running out. If you have a construction site, you can know where equipment is and how fast concrete is curing. For each industry, there are people within those enterprises who already know what they're trying to accomplish but don't know how to get from point A to point B. Consultants are ubiquitous. We need more people who will help bridge the gap from the domain expert to getting something out there. It will take all of us to eliminate that friction and make managing billions of physical assets as easy as the tool chain is for cloud developers to manage millions of instances.

It all depends on whether you're thinking about a new product or retrofit. Let me walk through a retrofit example. When we did Notecard at the beginning, we focused on new products, but once people have it in-house and see the power, they realize they can retrofit a million units already out there. I'll give you a concrete example. I visited a potential customer early on. They had an MSP430 plus an FPGA, a very small device already built. They wanted to get the result of machine learning cloud connected. They had started prototyping Wi-Fi, but cellular was needed. In an hour, the guy added two printfs to his code. You can do it with printf or Arduino Serial.write. You put together a text string that is a JSON texturing. One text string configures the Notecard: you say 'I am product ID X'—that's how it finds its way to the cloud—and 'I want to synchronize over cellular once an hour if there's data pending.' That's it. You just printf that out the serial port. Then, every time an event happens, they create another little JSON object in memory and send it out serial. That was the whole thing. It sounds too simple to be true, but it was good enough to ship. Our module is pre-certified, does TLS, firmware update of itself and the host firmware. It's extremely simple. If you just want to start seeing how you can get data, for example, building a mousetrap that reports open or closed, all you have to do is hook it up to a serial port or I2C. We have a serial over I2C protocol, so you do the same thing over I2C if you don't have an extra UART. All Notecard applications start with that simple model and move up. The Notecard has a modem, GPS, accelerometer, SIM, secure element. It packages them as simple JSON commands. For example, you can ask 'what is the orientation?' and it says 'face up' or 'on its back.' You can slap it on the back of a road sign and find out if it got knocked over. For GPS, you can build a simple tracking application by reporting changes of location, using the accelerometer so you don't have to power up the GPS if the device hasn't moved. The developer experience is you go to dev.blues.io and look at the vocabulary of JSON commands. We have a web-based simulator where you can do everything you would do to a Notecard directly on the website to practice. Then if you order the hardware, you hook it up to USB, use Web Serial. My goal is success: the simpler the app, the better. People who are focused on the three, four, five pieces of data they need sent to the cloud can get those devices spun very quickly. Then what they have to do is use standard REST APIs. The JSON you put into the Notecard comes into your website as that same JSON, decorated with metadata like cell tower location, voltage, RSSI. We give you all that information because we wrote the code wrapping the modem. Then you just have to do what you're going to do on the service side. We are not an end-to-end solution provider. Our core customers know what they want to do with the data and have it injected into their systems—customer support, service, maintenance. Some drop it into Snowflake and do analytics.

There are companies like Samsara that sell solutions: they sell you a box for tracking and a website, a SaaS offering where you go to their portal and see where your assets are. That's a complete end-to-end solution. We are like AWS: hyperscale cellular IoT. We are an infrastructure component you embed on your board. You get your data in the cloud, and it's up to you or your partner to build the app appropriate for what you're trying to do. If you're managing moving assets, you might want to see them on a map. If you're managing fixed assets and temperature, it's up to you or your cloud people to build that aspect.

It's an extremely quick way of getting things up and running. Some people want to inject data into Postgres or a time series database and hook it up to Grafana. That tends to be what people do if they have 25 people or 25 devices. It's a quick way of getting gratification. People who do things at scale—we're a hyperscale cellular IoT—need a user interface to manage devices at scale, ways to manage large quantities of data.

Totally. I encourage people to look at it because it brings hyperscale economics and usability to one-person projects. It's very easy and approachable.

The price of the Notecard is $50. You can get it at blues.io or through DigiKey. That $50 buys you the Notecard and the data is embedded on it: 500 megabytes of data and 5,000 consumption credits. As data is routed through our cloud router, the Notecard talks to the Notehub. For every little event that flies through, it's a consumption credit. We bundle prepaid consumption credits and data with the Notecards. For a large number of applications, you just buy that thing and put it in the board, and you won't have to pay a subscription. If you exceed those volume or data requirements, we have connectivity assurance plans that auto-recharge. It's quite a bit of data. We have very few customers for whom 500 megabytes isn't enough. I come from an era where we used modems, so everything is encoded and tiny. A good guideline: if you set up a TCP session, it's just under a kilobyte of overhead to make the connection. If you want a secure session with TLS, the key exchange is just under 4K. If you care about on-wire confidentiality and want every session encrypted, you don't want to connect and hang up every minute because you'll blow through your data. If you are power-miserly, you want to write a lot of measurements to the Notecard, let them queue up in flash memory, and ask yourself how often you really need them in the cloud. Once a day, every 12 hours, every six hours. By packing them together, we compress them heavily, saving on session overhead. A rule of thumb: if you have a dozen measurements and set it to connect in normal mode, you're talking maybe 400 bytes of data plus 700 for session setup. We have calculators for that. People with power-connected modules just tell it to connect constantly and leave it connected. We have customers sending data once a second, once every few seconds, and many doing it once a day. It depends on the application.

It may not be a surprise that the reason it's called the Notecard and the Notehub, and it was called Lotus Notes, is that the core synchronization and communication algorithms, all the core data structures, are modernized versions of exactly what we did in those days. It was super reliable, worked, and occupied very little wire bandwidth. We didn't have it at the time, so why not just use it?

It's actually very cool and simple. There are two core paradigms: the queue, which can be bi-directional, and the database. We call these things notes. You add a note, delete a note, remove it. When you queue a note, it sits on the Notecard until the next sync, and it compresses all those things together. If you put it in a database, we call them notefiles, it bi-directionally synchronizes with the server copy. For configuration variables, you set an environment variable on the server and have the whole fleet or a subfleet pay attention to that variable. It synchronizes down into a little database, and you can read it with simple JSON commands. It's a very scalable paradigm.

Always escape your quotation marks.

Many people right now are focused on the metaverse and web3. Not to say these aren't worthwhile, but I actually believe the thing I really want to happen, the dent I want to make, is realizing the tens of billions or hundreds of billions of device future. If you look at the landscape of innovation, I don't think people are giving enough credit in two related dimensions. One is wireless in general. There are many protocols: Wi-Fi 6 and beyond, 5G, 6G, sub-protocols like 5G RedCap. Getting those innovations delivered to developers is incredible. The other innovation is on the MCU side. The integration happening in a system-in-package in the next several years is mind-blowing. We've seen sophistication in ARM-based processors, the beginnings of RISC-V. People are building little things that will have an MCU, modem, SIM, eSIM, secure element, several neural processors for inference. It's extremely powerful and will change the game of what we can build. The reason I believe so much in our architecture, where we separate telecom from compute innovation, is that you'll want your choice of MCU for a given application. At the same time, there's innovation on the telecom side. Over the lifetime of a device, you may go through two or three generations of different cellular technologies. I believe LoRa has a great future too. There are four wireless stacks: Bluetooth, Wi-Fi, LoRa for wide area, and cellular for wide area. Each is finding its sweet spot. LoRa seems to be finding a sweet spot in smart city and agriculture applications. Anything in motion, or where you don't know where the product will be deployed, cellular wins. Everything is going to be cloud connected, so I'm super excited.

Go to the forums and chat with other people going through the same thing. In the two years I was trying to figure out how to build the Notecard, I didn't know if I should start with Nucleus or FreeRTOS. Each time I had to make a decision, I had to figure it out. The only way to learn is by finding people to talk to, going to a meetup, getting involved in a Slack or Discord discussion with like-minded people. Try to build a project together and solve a problem. You always end up knowing more than you did going in.

You don't want to find out about me, you want to find out about the company. I think you're pretty interesting. I'd say this 80 minutes we've been recording is proof positive. I am rozzy at a not very active Twitter account, and LinkedIn as Ray Ozzie. Blues is really where it's happening: blues.io. For this audience, dev.blues.io. Go to the shop, buy a starter kit—a Feather starter kit or a Raspberry Pi starter kit—and just start messing around. Scratch some itch. We would love to help you in the forums. There's a very active forum where we or somebody else can help out. We'd love to chat with you.

Thank you, Chris. Thanks for inviting me. I appreciate it.