For embedded IoTs the time is not yet here -

For embedded IoTs the time is not yet here


The Internet of Things is supposed to describe a world where connected devices improve our lives. But an embedded engineer finds crippling tradeoffs in every solution today.

Let me introduce myself: I'm an embedded software developer. As far as signal processing, processor selection, battery handling, interfaces to peripherals, and optimization goes, well, I've got those skills nailed.

But I've discovered that working with a connected device requires a fairly significant expansion of those skills. I should point out that it's hard to find this complete skill set in one individual: The diversification of computer science means that deeply embedded engineers often have trouble talking to server engineers

I've had to learn Javascript, HTML5 (and CSS), server-side programming (PHP), how TCP/IP works, and how to use Wireshark (it's not as trivial as it sounds). I like to learn new things, but I admit to wanting to strangle an Internet-enabled stuffed animal I was working on when a vendor suggested that Ajax had just the functionality that I needed, and that I should learn it. Gee, thanks.

As a developer, cost, functionality, and perceived ease-of-use influence my technology choices. To that end, I've connected devices via BTLE, cell modems, Broadcom 802.11 WiFi chips with MCUs running TCP/IP stacks, other WiFi chips that have serial interfaces, and Electric Imp's WiFi cloud solution. But no matter how careful I am in the selection process, once I've started working on a design I've never come across a connectivity solution that didn't make me wish I'd chosen something — anything — else.

Moreover, I would not want to give any of the connected devices I've created to my non-geek friends. The reason is that, for a user, setup is a larger barrier than is generally accepted by device manufacturers. As wireless costs come down, the configuration remains an unsolved issue, which causes products to have a higher support cost than expected. Security, too, is an issue that sabotages usability, leading grandma to have a 190-character password scribbled on a sticky note that was once on top of her router.

Even if you have a broad background (or a large team), there is no ideal connectivity solution. Let me repeat: There is no ideal connectivity solution. Each technology has its advantages, sure, but the disadvantages can far outweigh the positives.

Here's a brief assessment of the technologies I've had hands-on experience with:

1 – Bluetooth and Bluetooth Low Energy (BTLE) require a smartphone and/or an always-on base station that communicates to a server. That likely means an app on the major smartphone platforms and a service/daemon on the base-station OSs. Plus, to collect and act upon the device's data will probably require a cloud server. On the plus side, configuration is relatively simple — as long as you have a display on the device. Battery usage is minimal, which makes this a good choice for pedometers and other pocket devices.

2 – Connecting to a WiFi processor using a TCP/IP stack on your processor makes for a reasonably complex system requiring an RTOS. It also can drive up the cost of the MCU by moving the application from a Cortex-M0 to a Cortex-M3 with the associated battery drain. Configuration is very difficult, usually requiring the user to switch to the device-as-a-server (a.k.a. device-as-an-access-point ) to set the SSID and password. Also, the quality team (if you have one) is going to need to verify functionality with a wide range of home routers and (seemingly standard) web browsers. The battery usage is high when the radio is on, which means that intelligent local processing is needed, along with some message batching if possible. This option works well for printers (plugged in) and scales (which spend most of their time sleeping).

3 – Connecting to a WiFi processor via serial means the processor can remain smaller, which is a cheaper and more power-efficient option. However, configuration is still difficult, probably even worse since the setup will not be as customizable as running a local stack. There are often fewer power optimizations for the WiFi processor so, oddly enough, limiting connectivity is often a priority for developers.

4 – Electric Imp provides an interesting configuration option for 802.11 WiFi. It requires a smartphone, blinking the screen to send the SSID and password to a receiver on the device. It also takes some of the burden from the device developers by creating a WiFi + system cloud solution. However, it still requires many parts: device software (developed in Squirrel), a monitoring agent on the software (also Squirrel), and a web interface (Ajax, HTML5, etc.). The power levels are in line with other often-asleep devices, so batteries will do fine if you use enough of them. This option is great for the home hobbyist hacking together a monitor to see if the stove has been turned off. But using the Electric Imp in large scale means letting someone else store your data and working with them to connect users with devices in manufacturing.

5 – Cell data modems are easier for the user, but they require coverage and are expensive (who needs another cell plan? ). Connecting to the user account is still non-trivial, particularly if the user doesn't have a keyboard. Note that Amazon did cell modems for the initial Kindles (though the current Kindles are WiFi instead of cell modem now — it is much cheaper for the OEM). Battery usage is higher than on WiFi, though the distance is greater. This option is excellent for devices that need to always be available, even when WiFi coverage is unlikely, such as traffic light cameras, cars, and smartphones.

6 – Some products create their own wireless networks, running a base station or small server. This makes configuration much easier. However, the server likely has to use one of the above options or a wired connection to get to the Internet. And creating a device solely to communicate with other devices is expensive; it is primarily an option for systems with lots of little devices (such as home lighting). This option isn't scalable to true connectivity, rather it is a stopgap along the path to true device connectivity.

The Internet of Things is supposed to describe a world where connected devices improve our lives: The refrigerator tells the phone to put a needed item on the shopping list; the house detects there is no one home and turns off unneeded appliances (especially the oven!); the car tells the thermostat that it is 15 minutes from home arrival, to make for efficient climate control; the possibilities are endless and endlessly amazing. But we aren't there yet.

Too many connected devices cause more headaches than help. They are unreliable, too difficult to use, dangerously insecure, or impossible to configure. I know what I'm asking — security and ease-of-use are natural enemies. But I'm tired of being the target audience, using my engineering skills to make not-quite-there products work for my home.

Let me know when your four-year-old and my grandma, working together, can put the device on the Internet. Then tell me again about the Internet of Things.

Elecia White is an embedded systems consultant at Logical Elegance.  She wrote the book Making Embedded Systems for O'Reilly. She has a podcast  about creating gadgets, from idea to engineering to product. Elecia will be speaking in more detail about the rocky road to connectivity at DesignWest 2014, where the call for abstracts is open.

See more articles and columns like this one on up for the newsletters . Copyright © 2013 UBM–All rights reserved.

(This blog has also been published on EETimes. )

12 thoughts on “For embedded IoTs the time is not yet here

  1. Well this rang a chord with me as I took a break from writing code to configure all the networking setup options on my companies latest device via a 2 line 16 char lcd and rotary switch (I can only just fit an ip address on that). I think you make some gre

    Log in to Reply
  2. It is possible to do TCP/IP without an RTOS. I've done TCP/IP using lwIP, which works fine bare metal.
    Also, when it comes to connectivity, any thoughts on ZigBee?

    Log in to Reply
  3. May be I am a bit old, a post 68 generation person. But if NSA or other secret agencies do collect data from devices with IoT, liberty, human rights and those of privacy get thrown into trash. Never will a device using IoT be able to withstand NSA or simil

    Log in to Reply
  4. Agree. I think even the Bluetooth is too complex to use. Perhaps IoT would first take off in commercial/infrastructure market, but I don't see any incentives for a home to deploy such complex, expensive thing that causes more trouble rather than save them

    Log in to Reply
  5. I'm going to play the devils advocate here. I think it is completely possible to have pretty robust connectivity using a variety of connection technologies and they might be non trivial to connect, but you can make them work. The bigger challenge in the

    Log in to Reply
  6. I don't agree with you. Things can get complex but it shouldnt be a reason to stop initiating the plan. I've had this dream before TI.
    after all no one has to force anyone to use it. And when people start using it, things can get much better. bugs can be

    Log in to Reply
  7. There is also WPS to consider but ofcourse not all routers support this feature but there are other ways to work around the problem of hosting a server on the embedded system for configuration update, definitely not the end of the road.
    Service discovery

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.