In the last post, I described a framework for putting together an Internet of Things system: the device, communications layer, Internet handling, the server cloud, and the interface to the user. In this post, we’ll get to where the technology meets the users. I intend to focus on the communications box though we’ll come back to the system view in the next post.
Within the communication area, I’m going to focus on the first few, fraught, minutes of getting the device out of its box.
Sadly, most unhappy users can trace their displeasure to the configuration of IoT products. Other problems are more surmountable: if users love your device, getting them to put a Bluetooth dongle on a central computer in their house isn't difficult. But if they turn on their shiny, expensive new gadget and immediately feel stupid, well, they won’t like your product.
Let’s start with 802.11 setup. I made a flowchart (below) to show how to setup my newest connected devices. Note that it flows right and then left, zig-zagging.
This configuration is not too difficult. It should be familiar to many of you, either as engineers or as consumers. WiFi setup usually requires the user to switch to the device-as-a-server (aka device-as-an-access-point) to set the SSID and password. Unfortunately, the system behaves differently and the battery usage is high when it is in access point mode. Accordingly, we are going to require the user to push a button and put the batteries in at the same time. This extra step will ensure that the user doesn't accidentally put the system in set up mode.
Once the radio is in access point mode, our device will serve up some pretty webpages that help the user enter SSID and password. Once those are configured, we’ll write them to non-volatile storage, reset the system and go back to behaving normally (but now connected to the internet).
From the device perspective, connecting to a WiFi module using a TCP/IP stack on my processor makes for a reasonably complex system, requiring an RTOS and driving up the cost of my MCU.
In general, if my IoT coffee cup could have done all of its processing (whatever that is) on a Cortex-M0, the WiFi complexity will now drive us up to a Cortex-M3 with its additional processor cycles, RAM, and code space. Unfortunately, we’ll also get the associated increased cost and battery drain. So as we determine our bill of materials (BOM) for getting the device to the Internet of Things bandwagon, we must remember that it is probably more than simply adding a part.
But that isn't the difficult part. Let’s look at some of the comments we can expect from users.
While I have invented this little chorus, these comments really happen. Users are whiney; indubitably they are whiney in public.
Setup is a larger barrier than is generally accepted by device manufacturers. Even as wireless costs come down, the configuration remains an unsolved issue, causing products to have higher support costs than anticipated.
In the diagram, we start off losing people who can’t figure out how to push the button while simultaneously putting the batteries in. That feels a little Darwinian.
The next user falls out of the process because they've never configured a network. Maybe the user is a lawyer or a doctor or anyone who has an IT guy at work to take care of these problems. They don’t know what the wireless signal indicator means or how to change networks. While it is something we engineers do when we go to conferences (or meetings or coffee houses), it isn't obvious to everyone.
As for the next unhappy consumer, I really shouldn't make fun of people who don’t know their wireless passwords. Security is an issue that battles usability. It is what leads grandma to have a 190 character password written in poor handwriting on a sticky note that was once atop her router. (Stop me if you've been there. And I suspect you have.)
Finally, there is the smart guy who gets all the way to the end; he knows how to do this! He is an engineer, technically inclined, and/or has battled through this process before.
However, while the module we bought might have said 802.11 a/b/g/n, it doesn't actually run on all of those varieties, most of them are 802.11b underneath. So our technical user returns our product because he doesn't want a slow device slowing down his superfast 802.11n network.
Through this, I haven’t shown our internal quality team and their ever- lowering morale. They are going to need to verify functionality with a wide range of home routers and (seemingly standard) web browsers. Depressingly, there will be some that simply don’t work with our module.
That’s fine, 802.11 has a lot of issues, let’s try Bluetooth Low Energy (BTLE aka 4.0) instead. With that, the users can use their phone to set it up. There won’t be awful WiFi passwords and the strange initial configuration mode isn't so strange.
My flowchart assumes the system has a display (in the “Enter ID from device” box). The configuration gets a little trickier without that. If we simply use radio signal strength to determine the closest device, we can pair with that or make a list of the closest, allowing the user to select based on distance.
However, as the list to select from becomes long, mistakes can and will be made. This is most fun on the manufacturing floor: due to Bluetooth pairing unexpectedly, the final testing of a unit may not be done on the unit about to be put into a box and shipped. Proximity is tough when you've got a lot of them.
This does affect the end customer as well. Consider the use case when a whole family opens a new game controller or when a conference gives away mice and everyone tries to pair at the same time. Hilarity ensues. (Because if you don’t laugh, you may cry.)
Understanding the importance of the screen (or requiring a plan that goes beyond proximity), what do users think of our BTLE device?
We lost one user right away: he doesn't have a smart phone. Possibly, he does have a smart phone but it isn't “BTLE”, “Bluetooth 4.0”, “Bluetooth Smart Ready” or whatever the description has changed to.
Our device depends on another device. How are we going to communication the stats for our device on our box so it isn't technical gobbledygook? Now how are we going to describe the stats for the device that our device depends on?
In the end, this isn't so bad. We lost one user because having another radio powered in their smartphone will make it die faster. We still got two happy users so let’s see what happened to the guy who fell out of the process by not having a smart phone.
The folks without a smart phone have a process with a few extra steps as they configure it on their computer.
Of course, I've been saying “smart phone” as though there is only one model. Because Bluetooth requires a translation layer to get to the cloud, you will need to write an app for each smart phone operating system (iOS and major Android distributions).
Now, we are adding a computer program for aiding in the setup procedure. The computer will also need an always running component, a service or daemon. Which operating systems will be supported? Mac, Windows (which varieties?), Linux (again, which varieties?).
This device has gone from a simple coffee cup to a major software project.
Of course, the newly identified can of worms is not limited to BTLE, we had an inkling of this problem with 802.11 where we might have tried to solve some of the configuration difficulties with a friendly setup program, only falling back to web browser configuration if the friendly method failed.
A connected device has a lot of software to go with it.
Still, let’s see what our users say.
We lost one user when their computer didn't support BTLE. Another tiny dongle is another thing to lose. But new computers have Bluetooth 4.0 built-in so it is ok, we’ve still got other users. He’s a Luddite with no smart phone and an old computer.
Of course, he wanted to buy your product. All the people we've crossed off, who have fallen off of the happy-user list, we've left them behind. At each stage, we had good technical reasons for moving on. But they wanted to buy the product: they willingly shelled out the extra money to buy the device that could connect to the cloud. And we’re cavalierly crossing them off our list of potential users.
This seems wrong, really wrong. Our early adopters are precious and, as engineers, we have to do better to keep them engaged, to fulfill the promise of the Internet of Things. Whether it is communicating to users that a dongle is a short-term measure or making it so attractive that people don’t mind buying a hub to put something else on, we need to stop ignoring the difficult users and make solutions for them.
Still, we've still got some happy users so BTLE is ok.
Before we go on to cell modems, I want to mention the proprietary protocols such as ANT and Zigbee. The process for setting up one of those devices is very similar to the BTLE configuration. Let’s see what those users think of the process.
This time we got hit with two dongle whines because the proprietary protocols are not going to be included in computer hardware, they are likely to always need dongles. Worse, they are unlikely to be worked into cell phones. To connect to a phone now, users need rare and custom dongles there, in an even more inconvenient location than on their computer.
On one hand, going to a proprietary communication method is simpler in many respects, primarily security. Buts its difficulties are in the fact that it is propriety. It seems like an easy road as you consider it but it is more like going down a side road, getting off the highway everyone else is building. (Did you mean to take that exit?)
Some products create their own wireless networks by running a base station (or small server). This is primarily an option for systems with lots of little devices, such as home lighting.
This makes configuration of the devices much easier, though the server likely has to be always on. It also has to be configured through one of the listed methods or through a wired connection to the internet.
Creating a server-device solely to communicate with other children-devices is expensive. Either customers have to buy the server separately, paying for something that doesn't appear to have a function, or the child-devices have to each cost more to amortize the cost of the free or no-profit server hardware.
Worse, this option is only a stopgap along the path to true device connectivity. We only do this because there isn’t a good way to build an IoT system that works in this case.
On the other end of the spectrum, cell modem configuration is so easy it feels like cheating, from an engineering perspective.
Of course, cell data modems require coverage. And connecting to user accounts is nontrivial, particularly if the device doesn't have a keyboard. Since the cell number is hidden from the customer to prevent unwanted charges, in manufacturing a serial number provides a record of the cell number. This can be used by the customer while logging into their account via the web (not on their device) to activate or pair the device (with the given serial number) to the user’s account.
Also, note that Amazon did cell modems for the initial Kindles and that was very popular. However, current Kindles are mostly WiFi now; it is much cheaper for the OEM.
For cell modems, battery usage is higher than on WiFi though the distance is further.
In short, 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 smart phones.
It seemed so easy but it is never easy. If it was, our job wouldn't be called engineering, it would be called vacationing.
Cell modems themselves are expensive; expect them to be a significant chunk of your BOM for a consumer device. Worse, the costs don’t end with the module, cell modems have an egregious amount of overhead associated with them.
The plan costs depend on the device and what sort of service it needs. Next, your company must work out how it will pass the data costs to customers. Few customers are willing to pay for another cell phone so many companies choose to pre-package the data plan costs.
That requires that we forecast the data usage over the lifetime of the product. It can be expensive if you are wrong, eating into your profits whether your estimates are too high or too low.
Finally, never forget, that cell modems are power hogs.
That covers the general methods for wireless configuration. New products and standards are coming out all the time but the models are about the same (at least so far).
There are other tradeoffs to consider when designing your product, questions that go beyond that first 3 to 45 minutes of the device’s life. In the next post, we’ll go back to the system view and explore these tradeoffs.