Category Archives: IoT

Going to production with chipsets.

IoT is hotter than ever and there are a ton of folks getting jazzed about the Raspberry PI 2, the Arduino, Intel Edison and other awesome and cheap devices that are incredibly powerful. The issue is that these are maker boards designed for hobbyists, not production boards that you could actually leverage in a real production product. This is deliberate on their part as they are going after a specific audience and they do an outstanding job of it. There are a ton of folks prototyping on these boards, as they should, and getting their proof of concept running. But then, there needs to be a path to production. The great news here is that there are a lot of great paths depending on what you’re trying to accomplish and what features you need in your board.

It’s a good idea to start with your path to production in mind when you pick your maker board. Reason being, if you have a similar chipset and capabilities to what you’re going to go to production with, it’ll minimize churn when you get to that point. If you’re going to be going to production with a minimal real time operating system, it’s probably a bad idea to start with an x86 board with gigs of ram and processing power.

Embedded OS Options

Since it affects your chipset choice, the first thing is to talk about the different embedded OS options and their capabilities. The options range from real time operating systems (RTOS) to embedded Linux to many different flavors of Windows.

The first question is what are you trying to accomplish? What’s your device going to be doing?

Power systems make a huge part of this choice for you. Is it going to be battery operated? Rechargeable? Constant wall power?

Is it going to be doing communications? With what? Over what type of radio?

How are you doing security?

Are you doing processing on the device? Or is it simply a remote sensor or actuator of some sort?

How complicated is the processing that it needs to do?

Obviously cost is also a factor. What’s your target “BOM” or Bill of Materials?

How large is the space you’re going to put it in? Does your device have ventilation? Some processors require more robust cooling systems or have more sensitive temperature ranges. It matters if you’re putting a device in the arctic circle or in the middle of death valley.

What’s your development language? Realize that I put this fairly far down the list of considerations because it’s possible you are going to have a language forced on you. But if you can choose, would you prefer C, C++, Python, JavaScript, .NET or what.

That’s a lot of questions but it really drives down to four basic options that are chosen most of the time, Windows, Linux, an RTOS (real time operating system) or a microcontroller where you are writing firmware.

Windows 10 IoT Core is the current build of Windows for smaller devices. Your options for development are the languages that run on Windows 10. That’s quite a few including C, C++, .NET or any other type of runtime that runs on Windows so you can get Python, Javascript/node.js and the like to run on it. This makes it an extremely versatile option. It’s also a very robust option when you’re talking about security, communications and the like. If you want to get started on this option, check out http://ms-iot.github.io/content/GetStarted.htm. The downside on Windows 10 IoT Core is that it’s limited to the x86/x64, Atom and ARM chips.

Linux is another great choice. On many devices you can run something as big as Ubuntu however there are a number of variants of Linux that are specifically built for embedded devices. The one that I’m most familiar with is OpenWRT. It was originally built for firmware on routers but it’s a tough little operating system that works well on a lot of little devices. It’s more limited on languages in that it doesn’t run .NET but you can run C, C++, Python, node.js, Java and the like. It’s also able to do communications and security just fine. And it runs on a very wide set of processors.

The downsides of both of these options is that while they have more capabilities, they have latency compared to an RTOS. If you really need real time, you’ll need to look at something a little deeper but to be honest, it’s been years since I’ve done anything with real time. I’m usually close enough that the user doesn’t notice vs the exact number of milliseconds matter.

The other option is some type of firmware where you’re skipping the operating system completely and programming the device to do exactly one thing and do that thing well (theoretically). In these cases, typically security and long range communications are offloaded to a gateway device that is running one of the above options.

Chipset Options

The second thing to do is talk about the types of chipsets and their capabilities. I’m not going to go through every possible chipset in the world but there’s a few that are specifically focused on the IoT.

Of course you can run an x84/x64 if you are going to be on constant power or at least near power. The Intel Galileo is maker board based on this chipset. It runs Linux and Windows Embedded (that’s prior to Windows 10 IoT Core)

Intel’s Atom processor is the next on the list. This is a great little chipset built for lower power consumption and longer battery life than the x86/x64 chipsets. These can still run many flavors of Windows as well as Linux. A great prototyping/maker board for this is the Raspberry PI 2. It’s running a 900 MHz quad core Atom processor.

The Intel Edison runs a Quark processor, comes with BLE and WiFi on board and the whole system can fit inside an SD card if you need the space. It runs Linux. I’m not wild about Intel’s toolchain for development but it’s a good chip.

Atheros is another great chose if you are looking at Linux as your host. A great board for this is the Arduino Yun. It has both an Amtel chip for more real time/micro controller options as well as the Atheros chip for running linux. Their default distros are running OpenWRT.

The Amtel chipset is the first microcontroller that we’re going to talk about. These are even lower power consumption than the Atom but they also have less capabilities. The huge advantage that these bring to the table is that there is very little that can go wrong with them. Since you are basically writing firmware, you can just plug them in and let them run. The Arduino is an example of a maker board that you can use with the Amtel chipset.

There are lots of other chipsets that are pretty awesome but I’m going to skip those for now

Manufacturer Options

There are a ton of manufacturers that are out there. Before you pick your manufacturer, you should pick your chipset and then start shipping around.

Dog Hunter is the manufacturer behind the linux system on a chip that’s on the Arduino Yun. They’ve got a great little chip called the Chiwawa. In quantities of 5000 or more, you can get these down to sub $10.

Intel is obviously the manufacturer of the Edison. They are a known quantity and know how to produce in quantity. They also make a Quark SOC that’s a well-established chipset.

The reality is though that you might need to go to China and meet with some of the manufacturers yourself. But to meet these folks, you have to know where to go. The great news is that there’s a ton of great resources to help you locate a partner and start conversations. GlobalSources.com, ThomasNet and Alibaba.com are a great starting point for components. It’s like the Yellow Pages for manufacturing. If you start looking through, you’ll find folks that do production for all the major players such as Nokia but also for little guys. But don’t trust what’s on their web site as your end all be all. First of all, manufacturer’s websites are A: marketing and B: notoriously out of date and poorly designed. Research the companies looking in your favorite search engine for the manufacturer’s name and the words “scam” or “fraud” or “fail”.

Quantity Options

In physical manufacturing, quantity matters. It takes time and effort to set up the manufacturing of a given item. There is also the possibility that there’s specialty equipment and the like that either needs to be purchased or tuned to make your device. Both of these, time and equipment, cost a lot of money. That price needs to be amortized across a large number of units in order to really drive the cost down. If you want 10-20 of a small device, expect to be paying hundreds to thousands each just for the setup and manufacturing before you get to your “BOM” or Bill of Materials. Reality is that if you are only ordering a couple hundred devices, that’s a “small run”. In fact, some manufacturers look at anything less than 10k as a small run. This means that either they are not interested or the price goes up fairly dramatically. That said, don’t go do a run of 10k of something without verifying that it works and that customers like it.

Summary

There’s a lot of questions that you have to answer before you get started building. Most people start with the board that they get cheap at Radio Shack but don’t think down the line for when they are going to try to go to production. Before you make that mistake, think through the choices that you’re going to need to make and then pick a board that’s a good fit for you.

BTW – I talked about some of this on the .NET Rocks Episode 1144 – Getting Practical with IoT

Tessel 2 Nitrogen

I’ve been playing a ton with the IoT space over the past 4-6 months. It’s been a ton of fun from a number of directions.

  1. I love to play with devices. I’ve got Arduinos, Raspberry PIs, Minnow Boards, Galileos and more. But my latest is the Tessel.
  2. I love playing with large scale cloud infrastructures as well.
  3. I love learning new technologies.

This last bit has pushed me in all three of those areas. I’ve been working with Tim Park on an IoT framework called Nitrogen which is built in node.js and runs in Azure. Working on Nitrogen has really pushed my node.js knowledge and I had never done anything with Ember prior to this. And then pile on top of that the vast number of devices out there and there’s something new for me to learn every day. 🙂

Yesterday I started playing with my Tessel and seeing if I could connect it up to Nitrogen’s MQTT gateway. Ivan Judson was kind enough to stand one up for me that I can start playing with. It was ridiculously easy to get going from there.

I started with the Climate Logging over MQTT project found on the Tessel site and modified it for Nitrogen.

The big change with Nitrogen is the format of the topic for subscriptions. Rather than being a simple string is a JSON object. For example, rather than just being “temperature” or something like that, is a subscription to messages routed to this particular device.

var subscription = ‘{“to”: \”‘+deviceId+‘\” }’

Check out all the code on Github at https://github.com/joshholmes/tessel2nitrogen.