Deeply Embedded Devices: The Internet of Things

The “Internet of Things” consists of interconnected, deeply embedded devices that need to communicate while maintaining extremely long battery life. Fortunately there are some low-power RF solutions that address both halves of the problem.

The “Internet of Things” is about connecting products that create, store, and consume data via the Internet. This allows processing to provide results that can be more easily used by people. The basic technical requirements to enable this are vastly different from the current treadmill of mainstream Internet-connectivity technology.

Mainstream connectivity strives to constantly increase bandwidth, range and features to counter dwindling margins and prepare for the next “killer” application. Whether this is HD media serving, on-demand TV, 4-play (voice, data, Internet and multimedia), Network Attached Storage (NAS), or the next thing you absolutely must have, mainstream connectivity requires a wider, faster-pipe mentality. Mainstream provisioning, however, is fundamentally disjointed from the requirements of the “Internet of Things.” While an Internet gamer will pay $150 to replace his 802.11b/g access point with the latest 802.11a/b/g/n access point, in order to reduce game “latency” or increase their virtual “survivability,” this is not a price option for adding connectivity to a thermostat, temperature sensor, garage-door opener, coffee maker, or lawn sprinkler. In short, the “Internet of Things” dictates a significantly different adoption model than mainstream broadband support.

Applications can be categorized as open, embedded, and deeply embedded. Open systems are compute-based products with purpose-loaded functions. Open systems may change their nature from one use to another. A laptop that is configured to be a word processor in one setting and an Internet-connected media player in another is an example of this. Due to the varying uses of open systems, the capabilities must be flexible yet high-performance in nature, with the limitations usually driven by cost. Embedded systems are fixed function. They may be very high- or low-performance, with a limited energy footprint. Deeply embedded systems are single-purpose devices that are used to detect something in the environment, perform a basic level of processing and then do something with the results.

Categories	Product Examples	Battery Life	Data Rate	Range
Open	PC	4-8 hours	High	Max.
Embedded	Access Point, iReader, Pocket Dictionary	AC Powered or up to 2 years	High	30 m - Max.
Deeply Embedded	Sprinkler Valve, Locks, Power Monitor	2 year +	Low - Med.	30 m

The “Internet of Things” is primarily driven by deeply embedded devices. These devices are low- bandwidth, low-repetition data capture, and low-bandwidth data usage “appliances” that communicate with each other and provide data via user interfaces. There are embedded appliances, such as high-resolution video security cameras, video VOIP phones, and a handful of others that require high-bandwidth streaming capabilities. This article instead targets the countless products that simply require packets of data to be intermittently delivered.

Data-rate requirements and the corresponding power consumption vary significantly between the different device categories. Open-type devices utilize Pentium class or similar processing, and run complex OS-based protocols for communication. Such devices require mains power, or utilize large batteries and have battery life measured in hours. Battery-operated embedded devices are products for which it is critical to reduce power consumption, design complexity, and cost through the optimization of computation occurring in the device. This is done through the use of specialized hardware, or less flexible purpose-driven software. Deeply embedded devices build upon this optimization and often require battery operation, which creates a critical need for low power consumption. These products utilize low-power microcontrollers such as the 16-bit PIC24F family from Microchip, which features low-power sleep currents down to 20 nA and allows the use of AA or coin-cell batteries for up to 20 years of operational life.

Examples of deeply embedded, Internet-connected devices include information displays for the home that can integrate heating and cooling control with lighting, music, and information displays (e.g. a web browser); security still cameras that provide an extra level of coverage for monitored services; appliances that allow time-of-start control from utilities for smart-energy control, to reduce consumers’ electricity bills; heavy equipment with sensors that can provide remote indication when in need of pending service; and toys or multimedia handsets that could be configured for subscription services, allowing updates during off periods.

The 802.11 protocol provides two basic methods of connectivity. The primary method is called infrastructure, or basic service set, and is implemented as a structured network with at least one central point that routes traffic among the devices and onto other networks. In this method, the central point is commonly called an access point, and all communications occur through the access point. The second method allows “unrelated” devices to connect temporarily. This mode is called ad hoc, or independent basic service set. Ad hoc communication occurs from device to device, but allows many devices to share the common network. A primary advantage of 802.11 over other wireless protocols is its intrinsic ability to connect devices to the Internet. However, this functionality is provided primarily through the infrastructure mode of operation. The Microchip TCP/IP stack and Microchip 802.11 radio combination supports both infrastructure and ad hoc modes of operation.

One example of a use for a deeply embedded Wi-Fi solution is for vehicle diagnostics. Considerable effort is spent designing the hardware and software for user interfaces in these types of applications. However, PDAs such as the iPod Touch or cellular phones such as the iPhone are perfectly designed for user interfaces with a rich and intuitive feature set. Most include Wi-Fi connectivity, which allows the use of infrastructure or ad hoc modes in the Microchip Wi-Fi module. As shown in Figure 3, the PDA or phone can connect to the Microchip Wi-Fi module, and the PIC24F 16-bit microcontroller runs the Microchip TCP/IP stack for ad hoc mode. The PIC24F microcontroller connects to the vehicle using any of the standard On-Board Diagnostic (OBD) interfaces, such as J1850, J1939, ISO 15765-4, etc. Vehicle status, such as RPM, MPH, and battery voltage, can be displayed in a variety of forms such as raw values, graphs, or gauges. Once disconnected, the PIC24F can connect to a central server using infrastructure mode to upload data, or download new firmware or parameters.

Latency is not a critical factor for data transfers in most deeply embedded devices. This means the data transfer has so little latency that a user does not discern a delay from an action to the corresponding reaction. Latency is often critical for handheld remote-control devices, because users get frustrated and consider it a poor user experience if the time for a local reaction to a button push on the device is discernable (more than 250 ms).

The 802.11 specification has a mode called “power-save poll” within the infrastructure service. It allows a device to go to sleep while maintaining a connection to the access point. A device can wake immediately and begin communication. Latency can be a little more than 100 ms for an external client to begin transferring data to a sleeping device. This is an ideal mode for remote controls using infrastructure mode, as it provides the ability to power down without a user-perceived reduction in latency. Battery life is only days with this mode if the unit is frequently used, so this usage model should be considered with a charging station. This scenario makes the usage model for such a device similar to that of a cellular phone.

“Power-save poll” mode is also an efficient way to reduce power consumption in devices where latency is not an important issue, such as those that transfer data more than four times a minute. In such cases, the act of reconnecting to the network consumes more energy than keeping the device connected via power-save poll. For example, the Microchip Wi-Fi radio provides the “power-save poll” mode autonomously to the microcontroller. An added advantage of this is that the entire client system can shut down during the sleep periods. An interrupt from the radio will provide the wake indication, in case there is data waiting on the AP. Additionally, for remote-control applications, a wake-on-button-press or wake-on-motion can be provided via the microcontroller, to maintain the illusion of always being on for the user.

For deeply embedded devices where latency is not critical, the best methodology for increasing battery life is to turn off the radio. The off state with leakage is the hibernate mode on the Microchip Wi-Fi radio. Once outstanding traffic is resolved via the TCP/IP stack, a single GPIO pin is used to deselect the device. This operation automatically disconnects power from the Wi-Fi radio. This mechanism allows the microcontroller and Wi-Fi radio combination to utilize about 120 nA in power-down mode. Such a combination is ideal for deeply embedded devices, because their low active power consumption stretches the system’s battery life.

In all of the aforementioned deeply embedded devices, latency is not critical. Other applications where latency is not critical include security or environmental sensors, data-upload services for medical monitoring, and consumer news devices, as well as information servers.

Deeply embedded devices don’t need 300 Mbps, 54 Mbps or often even 11 Mbps of throughput. A majority of deeply embedded devices use a low amount of bandwidth. They have data for transmission a few times a day, or expect to receive data possibly once a day. The amount of data they deal with is on the order of 100 bytes. By keeping external memory minimized or not using it at all, the overall system cost and power consumption remain low.

A normal infrastructure connection provides about a 5-10 second reconnect period from the hibernation stage. The connect processing between the Wi-Fi radio and an access point takes about 176 ms. Connecting takes longer than this, so the majority of the time is spent in the delays associated with the access point dealing with the connection. This can be easily seen by virtue of the time it takes a standard laptop (a high-end open system) to connect to a network. This time can be reduced by using the static addressing feature of the Microchip TCP/IP stack. With such an operation, the connect time with security can be reduced to less than a second.

Ad hoc connection from a power up can take less than 200 ms. For point-to-point-only remote-control devices, ad hoc operation is suitable because the achievable connection times are short. This method of operation is not often used for remotes because while it does resolve the connection-time problem, the limited use of the wireless technology for simple point–to-point only communications without LAN or internet connectivity can be better served by other wireless technologies, such as basic RF transceivers or the IEEE 802.15.4 protocol.

A very good application of the ad hoc mode of operation is as a default mechanism to enable easy configuration of the device onto the network of interest. Deeply embedded products that do not have a screen/keyboard to enter data need a method for the end user to configure the network, as well as the security parameters of their network. In this case, the codes can be entered using a temporary network. To use a temporary network, the product must be preconfigured to start either searching for a pre-determined infrastructure network, or by creating a pre-determined ad hoc network. In either case, another computer or Wi-Fi-enabled device (e.g. iPhone, Smartphone, etc.) connects to the product using the pre-determined network, and then configures the product to the final desired network. Once the appropriate network information is entered, a command can be sent to the product to restart in the desired network.

One advantage of 802.11 for deeply embedded devices is the ability to use pre-existing networks and the Internet. There is some concern regarding the impact to performance for other computers that use the network, when a low-bandwidth, deeply embedded device is also attached to that network. Wireless communication is a shared-bandwidth, media-access mechanism. There is a finite amount of bandwidth available for all to use before the airwaves get saturated with signals. The biggest impact is from clients utilizing the available bandwidth. Thus, adding a second 802.11g laptop to a network that already has an 802.11g-connected laptop on it will reduce the available bandwidth by 50 percent. The hibernate mode described earlier for power savings also serves, in this case, to minimize the effect on the network of embedded devices. Embedded devices should be configured to buffer their information and burst as required. Such usage will allow the devices to get on the network, transfer their data, and then get off the network. The effect of this will be maximum power savings and minimal impact on network-bandwidth capabilities.

A critical need of deeply embedded systems is to keep the communication system easy to implement and use. While the 802.11 protocol makes an ideal candidate for communication for these devices, many manufacturers are specialized in the art of their own product, and not in wireless IP communications. There is often no room in a critically costed product for more memory to run an operating system, in order to use an off-the-shelf driver that traditional 802.11 solutions offer. These drivers are created for complex operating systems, such as Windows, Windows Embedded CE, or Linux.

A significant benefit of a solution like the Microchip 802.11 one is the ease of implementation to the developer. Along with the basic networking features of security, infrastructure, and ad hoc; the stack supports various services that a deeply embedded product developer would require. Some of the services supported are ICMP, HTTP, SSL, DHCP, FTP, SMTP, SNMP, TFTP, DNS, and Telnet. These are sufficient for serving Web pages, sending and receiving data files, and handling e-mail services. The value to the customer is the ability to minimize code-space requirements by selecting only the services they require, accelerated time-to-market, and allowing concentration on device application and user interface, rather than on the underlying communications protocol.

The “Internet of Things” is about connecting a diverse set of simple, deeply embedded devices to the tools we already use. It allows servers and other instruments that can work in the background to provide a clearer understanding of what is happening—whether the interest is in energy conservation, product maintenance, health and safety, or just information retrieval. The Microchip 802.11 solution has been designed with the mindset for deeply embedded devices. This solution takes into consideration the speed, bandwidth, and latency needs of embedded devices—these being much less than what most people demand for their day-to-day Internet connectivity experience. This makes the solution much lower in power and easier to use than standard IP-connection alternatives. The solution is also compatible with the cost constraints of deeply embedded devices. These characteristics allow the system developer to concentrate on application development rather than on networking knowledge.

While it is said that the “Internet of Things” will progress to a billion new connected things by 2011, the majority of these will be in embedded and deeply embedded devices. The unique characteristic of IP connectivity is that having devices connected and providing improved efficiency is not the only benefit. The real return is the progression of benefits that will result from the interconnecting of devices to a wider and automated information database. This can include better performance through longer operation within optimal ranges, new revenue streams that will give users simplicity in dealing with things that otherwise go into disrepair, and also increased sales pull-through via product and information co-marketing.