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!
So while I was figuring out how to get my application approved for the Microsoft Store, I decided to move forward with actually writing some code. Eventually I want to read the temperature in the Bronco, but before I get there I wanted to just test out reading temperature at all. Taking little steps and learning along the way is how I like to develop, as it makes it a lot easier to respond to failure. Only tactically when I realize I’m on a wrong path do I pivot. It’s a similar philosophy as laid out in the Lean Startup, which prescribes a lot of these ideas for starting a business, but they seem to apply for development as well.
In order to prototype this out, I knew that I didn’t want to think too much about the hardware. After all, I’m a software person, and besides I think there’s little value in reinventing the wheel unless it’s for the distinct reason to learn how the wheel works. So, I leveraged a hardware and software abstraction and used the Seeed Grove kit for Raspberry Pi that allows me to not worry about translating the analog world into the digital world. The Grove System is specifically created to make prototyping less painful, and I can certainly attest to that. With the Grove Starter Kit for IoT based on Raspberry Pi as a starter point, which I received as part of an IoT bootcamp put on by Microsoft, within an hour or two I was getting the temperature of the real world and displaying it on my screen.
While not all that earth shattering, that allowed me to create the code that I will need when I’m starting to use a temperature sensor more appropriate for the Bronco. And that is exactly what prototyping is for, so it was a great success. Now, if only they would approve my app for the Microsoft Store, then we’d be cooking with gas. Or cooling with coolant, I suppose.
Being rejected is difficult. When I submitted my Universal Windows Platform (UWP) application to the Microsoft Store, I had no reason to think it would not pass with flying colors. I followed their checklist. I checked all the appropriate boxes, dotted all the t’s and crossed all the i’s.
Wait, the other way around.
Either way, it was rejected, and the reason (in my mind) was quite funny. There was no screenshots of the application! That was the reason! Why is this funny? Well…
The purpose of the IoT application is that it will be pre-installed on an OEM device. Aka, this thing is built to be installed on an IoT device that shows up in a store and sits on a shelf, and when a user buys it and takes it home, the single application that is installed on it will show up. They won’t even know it’s a Windows 10 IoT Core device, they won’t know it is connected to the Microsoft Store, they won’t go and find the app to download.
Well, that won’t really happen for the Bronco as it’s just kind of a proof-of-concept for that, but the logical issue still stands. No one is going to see this app in the Microsoft Store (and in fact, one of the checkboxes I checked was “hide this from the Microsoft Store search).
So, putting a screenshot or two of what the app does seemed a little superfluous to me. Perhaps it’s for the reviewers to make sure there’s a little meat to the potatoes in submissions. I know that the Microsoft Store (and really, all app stores) have an issue with quality of apps, so maybe that’s what they wanted to check out.
Either way. I’ll keep you up to date when I find out if they approve it!
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.
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.
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!
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!
