IoT

What’s Next For Me: Saving Lives With SUAS

by
A shot of the archer frs crew haning by the GCH, shot by an unmanned aerial vehicle, of course.

When Gordon Folkes III first approached me about joining Archer First Response Systems, I had a lot of questions. I had met Gordon through a hackathon in 2017, and I knew his company was working on delivering life-saving AEDs (Automated External Defibrillators) to cardiac arrest victims via unmanned aerial vehicles. I brushed shoulders with him at Orlando events from time to time, and he shared about what he was working on at the Orlando IoT Meetup last year. Still, I wasn’t quite familiar with what had been happening with Archer since then, and while the idea of joining a startup working on life-saving technology was definitely enticing, I wanted to know how viable this concept was before doing so.

The winners of the Orlando Smartest City Challenge, Justin Wells, Florin Lucha, Gordon Folkes III, and Jared Porcenaluk.
(from left): Justin Wells, Florin Lucha, Gordon Folkes III, Jared Porcenaluk, after winning the Orlando Smartest City Challenge hackathon in August of 2017.

So, I asked a ton of questions. First rule of joining any startup: is there funding? I do have a mortgage to pay, after all, and until we figure out that whole immortality thing, I still need to eat. Yes, there’s funding. Ok, well…

  • How many cardiac arrest victims are there?
  • How does this compare to ambulances?
  • How will people know to use the AED?
  • How far can the drone go?
  • Oh, drone is a loaded word. Unmanned Aerial Vehicle? No? Small Unmanned Aircraft System? Will people know what that is?
  • So how far can the sUAS go?
  • How will you know where to send it?
  • How will people know to ask for it?
  • Why not use AEDs from a local building?
  • What competitors are in the space?
  • How will this make money?
  • Where do you see the company in three to five years?
  • What’s the technology stack look like?
  • What challenges are you running into?
  • What’s the biggest obstacle to success?
  • Can I work in my pajamas from time to time?

I didn’t ask that last question, but thankfully it’s turned out I can work in my pajamas from time to time. Remember, kids, the code doesn’t care what you wear. For all the other questions, I got satisfactory answers from Gordon as well as Spencer Hehl, CTO. From him, I learned about their technology stack and the technical challenges that they’ve overcome as well as the ones coming down the pipe. The challenges form a technological playground that spans software, scaling, the cloud, and the edge, all within an environment that requires certainty and security unlike many others.

So, I did it. I had (and continue to have) more questions, but ultimately I knew that if they knew all the answers they wouldn’t need me. I joined.

And after being there for three weeks, it’s what I had hoped for. It’s solving problems quickly, moving fast and light, and also continuing to bootstrap a system that can be relied on, with a team that believes in the possible. I’m applying all of the knowledge I’ve gained at New Signature (née Nebbia) to give us the best chance of success as a company. While all of the details are a little hush-hush, I promise I’ll be updating you with more soon, and it will be worth the wait. I’ve seen this thing in action, and it’s incredibly impressive.

A shot of the archer frs crew haning by the GCH, shot by an unmanned aerial vehicle, of course.
The Archer FRS Team (Gordon Folkes III, Kade Aley, Spencer Hehl, and Jared Porcenaluk) by the Ground Control Hub.

Smart Bronco: Choosing Sensors for the Real World

by

Going from proof-of-concept to prototype, aka my single 1988 Ford Bronco II, offers up some challenges. Rather than using Seeed Grove to prototype temperature using a simple generic temperature and humidity sensor (the DHT11, if anyone is asking), I need to figure out how to read the coolant temperature from the engine block of a greasy 30-year-old Ford.

That means I need to consider a few things:

  • Temperature range (0 degrees F to about 300 degrees F ought to do it)
  • Thread size and pitch in engine block (3/8″ is the size and NPT, or National Pipe Thread, which indicates the pitch of the threads)
  • Waterproof (’cause it’s going to be in coolant)
  • Analog-to-Digital output (going from the analog input of the real world to a digital output requires some calculation, one that I’d prefer not having to figure out manually)
  • Accuracy (accuracy to about 1 degree F would be ideal, it can be a little more flexible but the more accurate the better)
  • How fast it responds to temperature change (how fast does the temperature vary? I might need to know if the temperature shoots up quickly! A few seconds would probably be fine)

Obviously these are a lot of things to keep in mind. You’ll be the first to know when I find a sensor (or a combination of things) that fits the bill!

Developing IoT Devices from Your Local Computer

by

Developing a typical software application locally often involves an IDE (Integrated Development Environment) or even a simple text editor (even Notepad), some sort of build system in the case of compiled languages (like C#) or an interpreter in the case of interpreted languages (like JavaScript). The process often looks like this: Write some code, compile it, run it, see what’s changed. If you are really cool, you can just run some unit tests as you develop to find out if what you have is working rather than running the whole application just to test one thing.

When you are developing for an IoT device, it can get more complicated. Sometimes there are emulators available that can simulate the physical device, other times it makes more sense to actually deploy code to the physical device. If there’s a physical device in the mix, you can deploy code over the wire, like through a USB cable that connects your device to your computer, or over WiFi, or in certain setups even through the internet.  For my Raspberry Pi 3, running Windows 10 IoT Core, I can develop locally using Visual Studio and deploy over my local WiFi new code to my RPi directly from within Visual Studio. For most devices, there are a few ways to develop and deploy to it and it’s highly dependent on the platform of choice.

Whatever the process, reducing the time it takes from changing something to finding out if it works is very important.   The first line of defense I have for being able to iterate quickly is unit tests. Unit tests can run very quickly, and can run against most of the code base all at the same time. Although they can be a pain to set up, the long-term efficiencies gained from knowing that most of your code works every step of the way is a huge time-saver.

This is true of regular development. When IoT is thrown into the mix, with the additional time it can take to deploy code to an emulator or a physical device, the efficiencies gained can be even greater than from application development. The next tactic is to use emulators when you can (as it’s typically faster than deploying to a device), and then when you do have to deploy to a device, make it as repeatable and quick as possible.

 

Smart Bronco: Choosing an IoT Operating System

by

What’s a piece of hardware without the operating system to run it? When buying a new desktop computer, the decision often comes down to a few choices: Mac, PC, or Linux. Operating systems in general are designed to run on a limited variety of processors, for example, Microsoft Windows historically has run on processors that run the x86 instruction set (they do occasionally get it to run, with some qualifications, on ARM processors). Linux has been compiled to run on a variety of computer architectures. macOS, it turns out, used to run on Mac processors and now runs on x86 and ARM.

With x86 and ARM being the dominant processors on laptops, desktops, and even phones, does the same hold true for IoT devices? Yes! And no. It depends.

If we are talking about microcomputers, which are essentially tiny desktop computers, often with GPIO (General Purpose Input Output) pins, then yes. The Raspberry Pi 3 is a widely adopted version of this. With an ARM processor, the same architecture as the ones that are in the vast majority of Android phones these days, it can run both many flavors of Linux and a special version of Microsoft’s operating system called Windows 10 IoT Core that gets specifically compiled for ARM processors.

When we want to go with even smaller, cheaper, less power-hungry (and less versatile) devices called microprocessors, the operating systems are more tied to the hardware because they run so “close to the metal” as they say. Rather than talking through abstractions, like the full-fat operating systems mentioned thus far, they often have strong dependencies on the underlying hardware. This category of operating system are typically called “Real Time Operating Systems.” Because there are many different types of microprocessors, there are many different types of RTOS in use today. For example, if you choose to use a Particle Photon, it comes with an operating system called “Device OS”. For any given microcontroller, there are usually a few different RTOS compiled down to be used by that hardware. With so many microcontroller choices, the mix-and-match options with operating systems are varied. Which one you choose is all about what you want to do. For example, if you wanted to use JavaScript to control your Particle Photon (rather than the out-of-the-box C-like language), you could install a new OS (or “firmware”) called VoodooSpark and run the Johnny Five framework on top of it.

For the Smart Bronco project, I am choosing a Raspberry Pi 3 with Windows 10 IoT Core running on it. Windows 10 IoT Core is like Windows-light, with the ability to run only Universal Windows Applications. It is specifically designed for the Internet of Things, even going so far as allowing users to create their own build of the operating system, for example if you’d like to remove the ability to do SSH in production for security purposes. When it comes to operating systems, I know that Microsoft has a great track record with stability and support, and so that confidence also helped make this decision easier for me.

As a developer, the operating system allows me to write code in C#, which is a language I’m familiar with. It will also allow me to take advantage of some of the tools that Microsoft gives for deploying updates to devices (more on that later). I also will be able to run multiple programs at the same time, which could be useful as I start to add more functionality to the Bronco. In addition, because I want to have the option for both “headed” (with a user interface) and “headless” (without a user interface), I know Windows 10 IoT Core gives me both those options.

In your own search for the perfect operating system for your project, making a choice and learning from it is more important that choosing the perfect solution right out of the gate.

Smart Bronco: How to Choose IoT Prototyping Hardware

by

Choosing hardware to prototype with in the realm of IoT can be overwhelming. There are so many choices! And, there’s so many constraints when it comes to putting a piece of hardware into production:

  • Power requirements vs. availability
  • Internet connectivity options
  • Processing requirements
  • Preferred programming language support
  • Security
  • Manufacturer’s support
  • Availability
  • Longevity

My advice is simple: Don’t worry too much about those constraints when you are just getting started. To make a prototype, focus on what’s going to allow you to fail early and often. In my experience, the prototype will only serve as a reference for the real thing. So, use the hardware that will allow you to get up and running quickly and worry about the constraints later.

For example, if you know JavaScript really well (or your team does), and your aren’t sure what processing power you’ll need, go with a microcomputer with some decent computing power that supports a mainstream operating system like a flavor of Linux or Windows. While options like Raspberry Pis with Windows 10 IoT Core or Raspbian works, don’t be afraid to spec out an Intel NUC or something similar if you want the full power of a desktop processor. This is a proof of concept, after all.

For me, I know the .NET platform pretty well, I’m familiar with C#, and I’ve used the Raspberry Pi with Windows 10 IoT Core before. I think I’ll stick with this tried-and-true formula (at least at first) as I validate that I can get information from a sensor reading the coolant temperature on the Bronco and send it up to Azure using IoT Hub.

Once the concept is proven, assuming that the concept is something like “Can we take this outdated protocol from an old machine and run it through an IoT edge device and get it to the cloud?”, the next step is to take those constraints into consideration and move the code to the hardware that will support those constraints. I’ll cover that another day!

Smart Bronco Project Announcement

by

 

Over the course of the next few months, I am planning on taking my 1988 Ford Bronco II and making it a little more smart and a little more connected, thanks to the power of the Internet of Things. I plan on using this cruddy old truck to experiment and learn about IoT being applied in the real world. Of course, because I work at Nebbia Technology, I will be applying DevOps practices and using the Azure cloud. I’m really looking forward to creating, learning, and sharing about how to apply IoT best practices to not only crusty Ford Broncos, but to new IoT projects and products as well. Stay tuned!

IoT & The Risks Of Bloodsucking Vampires

by

I recently had the pleasure of sitting down and consuming an entire bag of Doritos (don’t judge me, it was like the $1.69 midsize version) while watching a webinar about the coming Waves of IoT Innovation in the Retail Space. Cue the 50’s retro-cool mansplaining PSA.

It wasn’t really named that, but that was the gist. How IoT is coming to retail, how it is going to change the way we shop, how stores keep stock, and how assets are tracked. I believe in all that, in earnest. However, one key point, one little brain tickle that I couldn’t get out of my mind kept coming up: how can we use the data generated by beacons and IoT devices to push just-in-time ads to customer’s phones?

An example: Did you just walk by the Cinnabon without stopping? Maybe you have the Cinnabon app, and the last time you shopped at Cinnabon it noticed you got the Extra Large Creamy Original Fluffy Swirl of Sugary Cinnamon Goodness. So as you walk past the iBeacon at your local mall’s Cinnabon it ding pushes a notification to your phone. Are you sure you don’t want an Extra Large Creamy Original Fluffy Swirl of Sugary Cinnamon Goodness?

This is fine. I’m fine with this. Breathes. No, I’m not fine with this.

At some point we have to ask ourselves what future we want to live in. I personally do not want to live in a future where I’m constantly dinged. I think the advertisement industry already takes up too much real estate in the world. After years of telling people that ads support site creators, I finally caved and got an ad blocker. With advertisers battling ad blindness, these ads just started infesting my screen. Popups. Banners. Ads inline with the content that didn’t seem like ads at all until it was too late and my dumb brain forced me to read half of it. It just became too much.

I love IoT for what it can do to make our lives better. I want brands to think carefully about why people love them so much and use IoT in positive ways to cause us to love their stuff even more. I’m very much for you wanting to sell more of whatever it is you make, if you believe in it. If you think Cool Ranch Doritos are awesome to eat as a sometimes food, like I do, and you want more people to share in their crunchy, salty, sweet goodness.

Ahem. I have to eat something soon.

Then I am behind you 100%. What I’m not behind is a loudness war where the inevitable result is an across-the-board degradation of user experience. If you want to sell more Cinnabons, make a better product. Make a better experience. Don’t use the data to yell at me.

The Microsoft IoT Quick Guide

by

Microsoft has a bunch of tools labeled “IoT.” What are their similarities and differences? Why would you choose to use one over another (and do they play nicely together)? Let’s find out.

Azure IoT Hub

A connection from Azure to the device and vice versa without worrying as much about how to do so securely and reliably.

Pros: Lightweight, secure, reliable connection between device, cloud, and vice versa with SDKs for C, Java, Node, and .NET.

Cons: Few. This is the primary recommended way to communicate between devices and Azure.

When To Use: When you don’t want to reinvent the wheel for how to communicate securely and reliably between Azure and devices.

Use With: Azure IoT Edge, Windows 10 IoT Core, Windows 10 IoT Enterprise.

Azure IoT Edge

For when you want to take data from many sensors, process it locally, and send important stuff to the cloud.

Pros: Runs on Linux or Windows, open source, consists of modules that can be written in many languages and mixed and matched, runs some Azure services at the edge.

Cons: A somewhat complex solution.

When To Use: When you have a bunch of sensors, especially old ones, that you want to connect to the cloud. Factories are a perfect use case.

Use With: Windows 10 IoT Core on x86 devices, Azure IoT Hub.

Azure IoT Suite

A wizard walks you through the creation of a bunch of Azure services and code running on them. Use it to quickly bootstrap a fully featured IoT solution as a head start for your project.

Pros: Much, much faster than doing everything from scratch.

Cons: Can be complex and expensive for a proof-of-concept phase.

When To Use: When you are ready and funded to build your IoT solution with Azure and want to save three months of time figuring out how to architect it.

Use With: Azure IoT Edge, Windows 10 IoT Core, Azure IoT Hub.

Windows 10 IoT Core

The free, lightweight, yet completely serious Windows operating system for IoT devices.

Pros: Perfect for running a single UWP app.

Cons: Requires relatively hefty hardware (at least for IoT) and only runs Windows UWP apps.

When To Use: Kiosks are a great use case. Also could work as a small gateway or in consumer devices that can plug into the wall.

Use With: Azure IoT Edge on x86 devices, Azure IoT Hub.

Windows 10 IoT Enterprise

The not free and full-fat Windows operating system for IoT devices. This is exactly the same operating system as Windows 10 Enterprise, licensed for IoT use.

Pros: Full Windows allows for maximum flexibility.

Cons: Requires x86 processor and also more management know-how than Windows 10 IoT Core.

When To Use: When Windows 10 IoT Core is not enough.

Use With: Azure IoT Edge, Azure IoT Hub.

Azure IoT Central

The Software-as-a-Service for IoT. This is the no-code solution to getting up and running with IoT in the cloud.

Pros: Much of the groundwork done for you and abstracted away.

Cons: Not yet fully featured, little integration with other services, APIs aren’t open to developers.

When To Use: When you want to bootstrap something quickly, have little internal IoT experience, and all you need is a few dashboards and email alerts for your IoT product or service.

Use With: Doesn’t play nicely with much else yet. Stay tuned for integration with Azure Functions and Logic Apps, which will open a floodgate of integration possibilities.

Azure Sphere

The answer for securing and connecting tiny microcontroller devices, including a custom Linux operating system, hardware reference designs, and the cloud.

Pros: A cohesive solution for connecting low-power microcontrollers.

Cons: Specific to low-power devices.

When To Use: When you want an all-inclusive solution for connecting microcontrollers, like those in refrigerators and garage door openers, to the cloud.

Use With: Other services in Azure.

But Wait, There’s More!

There are many other services offered by Microsoft without IoT seared into their title that play nicely with the Internet of Things. If you have any questions or thoughts on those other services, don’t hesitate to reach out to me on Twitter @jporcenaluk!

Orlando: Poised For Tech (and IoT) Growth

by

Silicon Valley was born through several contributing factors intersecting, including a skilled STEM research base housed in area universities, plentiful venture capital, and steady U.S. Department of Defense spending. Stanford University leadership was especially important in the valley’s early development. Together these elements formed the basis of its growth and success.

—  Wikipedia

You need three things to start a fire: fuel, heat, and oxygen. In the case of a growth of any industry, the components are much more nebulous. What do you need to start a steel industry? In Pittsburgh, you had access to local coal for refineries. You had the convergence of three rivers and thus a major port. Then the Pennsyvania Railroad happened. At any given point, it could have failed, but through hindsight you see a manifest destiny of sorts. These varied facts built upon each other to make it nearly impossible to imagine Pittsburgh as being anything but a steel town.

And as the quote above notes, there were many factors that led to Silicon Valley’s rapid tech growth over the past three decades. Yet, the things mentioned: STEM research, venture capital, Department of Defense spending, etc., these were just fuel waiting for a spark. As you trace the history up, Fairchild Semiconductor’s shakeup in the late 1960s set the stage for explosive tech growth in the region. As the employees from this one company dispersed, they formed cottage industries that sprouted throughout what was to be known as Silicon Valley. The main outcome that was to be the backbone of growth was Intel. With a one-page business plan (and $2.5 million in funding) they started up, and the rest is history.

I often wonder if I’m in the right place. All the smart money goes to Silicon Valley, so it seems. Over a thousand people graduate from UCF with an Engineering/Computer Science degree yearly, and undoubtedly the best of the best are being picked off by recruiters to sell their souls to the devil and take that six-figure job in California or Seattle. If I sound a little bitter, perhaps I am. I want those people to stay. I want them to see what I see, the growing tech scene in Orlando and the daily job postings in the Orlando Devs’ Slack. I want to show them that if they stay, they can make things better here in their home rather than taking the chances in the hyped boom-bust-boom world of the West Coast.

But then I breathe. After spending three years commuting from Northern Virginia to D.C. I know some of the pros and cons in living in such a “happening” place. The pay is great, the cost is great, and the pace is fast. Well, except when you are sitting in traffic. The lawns are all manicured. You pay a lot of taxes, you pay a lot in rent. Everyone’s car is new, and having fun is going to a vineyard and if you work for a few decades you can afford that boat and can go sailing every weekend. And then you blink and your dead.

Maybe I’m being a little melodramatic, but I did go to college here and my wife and I did move back here for a reason. Life is different down here. If you want a boat, you make do. You get a stand-up paddle board or a kayak, because no one cares. No one is asking how many feet long your boat is or if you got the warranty or what the payments are, because people pretty much don’t care. Maybe we’ll just forgo the whole boat thing and get a cooler, sit on the beach and drink some beers.

And yet, we also work. We think outside the box, but we don’t take it too seriously. We have fun and play. We automate things so we can go back to the beach. It’s not forced. We don’t have suits and ties like the East coast, and we don’t have sweatshirts with our startup’s logo on them like the West Coast. We wear whatever we want, it’s fine. We’re here to get something done, and we’ll dress however we need to. Maybe slacks and some Sperry’s, maybe shorts and a button down shirt. Maybe just a t-shirt and shorts. It’s fine.

I breathe a bit more, because I think that someday those people who left will be back. When and if the startup bubble bursts or slowly deflates, they’ll be back. And even if not, we’re starting to build our own fuel. Florida Polytechnic has over a thousand students and is looking to get accreditation this year. I can comfortably say when that happens, its a matter of time before they are known as the MIT of the South. I hope that in a few decades, MIT is known as the Florida Polytechnic of the North. We have UCF, who’s growth is frankly incredible. And with so many different programs, we’re growing a society here, not just a tech hub. As you may or may not know, Research Park has untold monies flowing through it in Department of Defense dollars. Downtown Orlando is crammed with startups and techy folk just itching to build the next big thing. The Iron Yard and UCF’s Coding Bootcamp is pumping out legions of developers, all little seeds growing and sprouting. The Orlando Tech meetup is growing and expanding, we have the largest tourism industry in the world, we are the destination for many a conference (like Vegas, but we have a lot of substance to back up our style). All of this is fuel, fuel, fuel.

As you might know, I organize the Orlando IoT Meetup (you should sign up if you haven’t already), and my goal with the meetup is to grow IoT development opportunities here in Orlando. The fuel has been growing for a long time, and I’m hoping to make a few sparks in the kindling with the impending growth of the Internet of Things that some say is going to dwarf that of the internet itself.

Source: IHS (https://technology.ihs.com/Services/507528/iot-devices-connectivity-intelligence-service)

I honestly can’t contain my excitement. BRIDG, a $70 million facility built for the advanced manufacturing of sensor technology “like those in smart technology and other Internet of Things-based products” in Osceola is set to open this March. That’s next month, for those who are counting. Graduates of nearby colleges are pouring out with graduates ripe with the seeds of knowledge in hardware and software needed for this arena. I feel like the spark is lit, the match is burning, it just needs to be shielded from the wind so it can ignite the flame. What will be our Intel? What will be our Fairchild Semiconductor?

So what do you think? Is Orlando poised for tech growth? If you think I’m bonkers, send an email to me at jporcenaluk@gmail.com or Tweet at me @jporcenaluk. Heck, reach out to me anyway, I’d love to hear from you.

Review: “Enchanted Objects” by David Rose

by

David Rose’s “Enchanted Objects” book is a great start for anyone who wants to design IoT devices for, well, people. As IoT design matures, we need to look beyond what’s possible and look more at what is actually going to help our lives. Computers have become so cheap, so small, so fast, and so efficient that we have the ability to make nearly any object “smart.” So what do we decide to make?

David is an MIT instructor and entrepreneur who focuses on “making the physical environment an interface to digital information,”  and he covers a wide range of topics in his book. These topics are broken down into the following sections: the human drives behind what we want out of internet-connected things, how we can shape objects to fulfill those humanistic desires, and what the future looks like in that realm. David helps shepherd readers through the process of coming up with solutions to quite a few problems that speak to humanity’s timeless desires. He focuses not just on what the technology is capable of, but how it can transform our lives in ways we might now perceive as magical.

In the introduction of the book, he gives insight into his worst fears, a nightmare which he calls “Screen World.” In this dystopian future, every one of our beloved objects, our time-tested tools and mementos, are all sucked up into the “black slab.” This black slab is analogous to our modern smartphone on steroids, providing our every whim and desire yet sucking us into it’s cold and unfeeling void. People staring into their phones becomes a reality for everyone, all the time, with no escape.

Throughout the book, he shows a much more positive alternate reality of beloved things gaining additional abilities through the virtue of being connected to the internet and each other. He shows that objects that combine emotional ties and stoic usefulness can become more of both with transformative technology built-in. Our objects all help us out along the way without being disruptive. They are desirable, affordable, and inter-connected. They recede into the background when we don’t need them, and subtly hint when we do. The future he depicts is like a millennial San Franciscan’s Instagram feed: everything is clean, bright, and just messy enough that it feels human. Toward the end of the book, he likens the Internet of Things to electricity: awkward, cumbersome, and even dangerous for the first few years, but slowly it recedes into the background to the point where we don’t really think about it unless we don’t have it.

This proposed future is depressingly possible. What I mean by that is, currently the path we are taking is very different that the one proposed by David. Currently, the status quo is private companies trying to win with different standards and platforms, making it very difficult for internet-connected devices to easily communicate with each other. While much of what David writes relates to a single object’s ability to interact with you, and in that scenario compatibility isn’t an issue, he also indicates that the manifest destiny of the Internet of Things includes systems-level thinking. With information as a sort of currency, things will communicate with each other autonomusly to grease the gears of life as we move through it. We have a lot of work to do if we want to get to that level of interconnectivity. I mean, I’m finding it difficult to get my Alexa, Spotify, and my Phillips Hue lights to play nicely together without some custom solution. I’m not saying we can’t get there, but we need to put a lot of effort in to right the ship. This includes working hard to consolidate on standards.

Nonetheless, I appreciate David’s vision and I do believe we will get there, given enough time. I thoroughly enjoyed this book and whole-heartedly recommend it to anyone who is interested in or works in the IoT industry. We need to make IoT human-centric, and David’s book is a good start for anyone who shares that goal. David, ever the intellectual, examines all of the topics mentioned through an analytical view. Through his broad lens, he pulls influences from all areas of research to form views about what the Internet of Things should look like.

In examining our humanity first, and shaping what the world of IoT could look like around that, he provides a truly exciting peek at what the future could hold.