(Here’s the final post in On-Ramp To IoT, based on the Prototyping Connected Devices webinar co-presented by Todd Zielinski and Bill Horan and hosted by O’Reilly. Catch up on the series by reading the first three posts: Anatomy of a Connected Product; Getting Connected and Communicating; and Selecting a Cloud Provider.)
Now you’ve grasped the basic anatomy of an IoT device, identified how you’ll connect with and begin to communicate with the cloud, and selected a cloud service provider.
It’s time to get prototyping! There are a few ways to go, from kits to roll-your-own solutions:
EE Starter Kits
EE Kits provide a higher-level development environment right off the shelf and give you a working example – the helpfulness of which cannot be overstated. EE kits come with some prepackaging and may already include cloud connectivity. Here are short descriptions of a few popular kits to give you an idea of how they differ:
Ayla. Ayla worked with Murata and STMicroelectronics to put together a back-of-the-envelope kit using an Ayla module and the Murata Type-YD certified wireless module on a carrier board. The Ayla Design Kit comes with a package of software and source code to try out connecting to the cloud, and it goes for about $160.
Particle. Particle, which recently changed its name from Spark IO, ranges from $20 to $50. Particle has two modules, Photon and Core, for WiFi enabled devices; and one module, Electron, for cellular-connected devices. These connect as open-source hardware and software to Particle’s cloud service and stack. There are, of course, fees involved with both. The fees are not particularly high, but Particle’s business model is to essentially give away the hardware and charge for the service.
Nabto. Nabto is another partially open-source company. They have an off-the-shelf available cloud connection, a machine-to-machine connection kit with Ethernet modules, and a “Nabduino” – an Arduino-based development kit that costs about $100. Cloud fees are per device and have a fairly robust set of features, including peer-to-peer communications, automatic routing, and a small SDK footprint on the target device. There don’t seem to be many examples of wireless communications though — and no Bluetooth or Zigbee.
LSR. LSR’s TiWiConnect kit is a joint venture between LSR and its design partner, Texas Instruments. LSR is a proprietary cloud service, and Texas Instruments helps provide the firmware and software background. LSR provides a small, integrated module, and LIFT JSON-based API to its hosted cloud service – but you can host its cloud service software on your own server. It also provides sample mobile apps. Development kits cost $100 to $150; production modules are a little pricey.
Electric Imp. This is an SD card-format module with in-board WiFi and a connection to its own cloud service. Development is actually done in the cloud, using the company’s own scripted proprietary language called Squirrel. This option helps cut down on development time, but it does require using Electric Imp’s proprietary methodology and cloud. Development units cost about $45.
Modules are pre-packaged wireless chipsets that may or may not come with antenna. Using one is a nice way of adding radio communication and, potentially, network connection to a device that may not have it because of low power or memory.
Benefits of Modules
The module route is more expensive than buying a chipset, but it includes a software stack and software development tools that make it easier to get started on your prototype. Modules cut down on total certification costs, which can rise into the thousands. A module is a better choice for a smaller volume project, because it’ll be easier, quicker, and cheaper in the long run.
Another benefit of modules is their potential to work with your own cloud service versus a kit, which is going to be designed for a particular cloud. Modules can facilitate the addition of a lot of different, very simple embedded systems to your existing microcontroller without much work. Some modules have connections to the Web Services Security service programming interface (WSS SPI), which provides a framework for building secure Web services; UARTs (universal asynchronous receiver/transmitter), and so forth.
The Tradeoffs of Using a Module
Before you invest in a module, consider range. Modules generally come with a fixed antenna, and some have U.FL connectors. Think about where that antenna is going to be located and how you’re actually going to apply it. Also, as bandwidth and communication requirements increase and you need to increase customization, you’ll want to consider other options.
Overview of Module Providers
There are plenty of options besides GainSpan, Murata, U-blox, and AzureWave, which are some of the big, more popular module providers. GainSpan is an Intel spinoff. Murata uses a Broadcom chipset. U-blox is applied more often to GPS and cellular modem development. Azurewave uses Marvell’s chipset.
GainSpan or the Murata module run about $10, whereas others are closer to $20. The AzureWave module is potentially a little bit less expensive than GainSpan. In our experience, it really comes down to what you negotiate and what you’re looking for, for your particular application.
Chipsets (For Experts Only)
Upfront, a chipset will cost less money than a kit or a module, but it requires a lot more in the development process: you will be going through certification on your own, and potentially having to build the network stack, or develop the services you need. It will also be a challenge to get any support or even pricing for chipset from vendors and distributors. You’ll have to sort out the antenna layout, power supply, and board layouts. Getting built and certified on your own is possible, but difficult, so if you don’t have much experience, this route may not be the place to start. If you are high volume (over 10-100k units a year) or extremely space constrained, this might be your best option.
Overview of Chipset Manufacturers
Chip manufacturers define this market. The big players are Qualcomm, which makes the Atheros chipset; Broadcom, which is used in Murata and several other modules; GainSpan, the Intel spinoff; Marvell; Texas Instruments; and Silicon Labs.
Texas Instruments is a little more expensive but has good software and background support. Broadcom and GainSpan have their own software development kits (SDKs) available, and Silicon Labs makes Bluetooth and WiFi chipsets. MediaTek offers high-volume, low-cost chipsets. Redpine Signals has chipsets that do ultra-low power and multimode for Bluetooth, WiFi, and Zigbee all in one. Atmel is a new entry into the market and one to watch.
Once you’ve chosen your solution from the options above, it’s time to put it all together. Allow us to introduce you to our imaginary client, Sprinkl.r, an IoT startup who wants to create a device to water houseplants according to temperature and soil-moisture readings. The first thing we want to do with this client is to sit down and define the device’s requirements:
- Sprinkl.r wants to make fewer than 100,000 units per year, so we already know we should consider going with a module. This will help Sprinkl.r cut down on certification costs and get them to market faster.
- Sprinkl.r is looking for an always-on connection to keep constant tabs on houseplants for their users. They want to develop their own application on the mobile side and to easily develop portals with it.
- They want to go with an existing cloud service provider with a low cost-per-unit (per month) price, so they don’t have to build their own cloud service and can start selling as soon as possible. Fast time to market is really important for Sprinkl.r, because the IoT category moves so quickly.
What We Chose to Prototype Sprinkl.r
We chose a Murata/Ayla board – the kit goes for about $160, and it comes with an existing software stack. It uses the STMicroelectronics Discovery F303 board, which could be replaced with almost any M3 or M4 core from a software development standpoint. We went with the Murata WiFi module, which goes for roughly $10 or less in volume.
We mocked up a sample sprinkler control system using this device and hooked it up to our target flower with a moisture/temperature sensor and a pump driver. For the most part, this is just plugging together existing pieces in order to test the solution – as we emphasized earlier in the series, you want to test early and often.
Source Code Review
Ayla has an existing stack they’re handing out, and it includes management of essentially all the database properties, as well as the connection methodology and the JSON transport built in. We might use an STM 32F processor, but it could really be done on just about any processor since it’s fairly portable.
For Sprinkl.r, we connect basic data points, transport, and TCP networking through the Murata module over an SPI port. This module is already setup for SPI communications and has a baseline structure for the properties used in Sprinkl.r. It has some buttons and outputs already created as a properties table. You can add and remove individual properties, so we added a few to turn the pump on and off and test the moisture level of the soil.
The interaction designers modify the code to add sleeker design elements and animations, but for the most part the core logic remains unchanged.
Then we come to provisioning, which is an important part of a WiFi application. Provisioning is where the unit is being set up to work as an ad hoc network in order to set up its connection to the infrastructure or WiFi access point. Provisioning is a big part of IoT, and you want to make it as easy as possible for the end user to connect the device to the cloud service provider.
After provisioning, we decide to change the relative humidity value so we’re only testing every few minutes, to save power and memory but stay connected to the WiFi network.
When Sprinkl.r is up and running, there is an image button that can be pressed to call a function that creates a data point. Another function associates that data point with the sprinkler property. The library will call the REST interface and send that information to the cloud server. A JSON message comes back from the server and updates the two text boxes showing the temperature and moisture readings.
The Ayla framework really does most of the heavy lifting. With this structure in place, we can move from a low-fidelity prototype to higher levels of fidelity. Along the way we have opportunities to test, reiterate, and refine.
Good luck with your IoT prototype. If you’d like more information, watch the full webcast at O’Reilly where we go into the demo more comprehensively. Have faith. Development is planning and patience. And remember Thomas Edison’s wise words: “I have not failed. I’ve just found 10,000 ways that won’t work.”
(On-Ramp is an ongoing series explaining engineering techniques used in product development.)