The “Internet of things” is about connecting products that create, store, and consume data via the Internet. This allows processing to provide results that people can more easily use. The basic technical requirements to enable it 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 to reduce game “latency” or increase virtual “survivability,” this isn’t 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.
APPLICATION TYPES Applications can be categorized as open, embedded, and deeply embedded (Fig. 1). Open systems are compute-based products with purpose-loaded functions. They may change their nature from one use to another, such as a laptop that’s configured to be a word processor in one setting and an Internet-connected media player in another. 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 offer very high or low performance, with a limited energy footprint. Deeply embedded systems are single-purpose devices that detect something in the environment, perform a basic level of processing, and then do something with the results.
The Internet of things is primarily driven by deeply embedded devices. These devices are low-bandwidth, low-repetition datacapture and low-bandwidth data-usage “appliances” that communicate with each other and provide data via user interfaces. Embedded appliances, such as high-resolution video security cameras, video VoIP phones, and a handful of others, require high-bandwidth streaming capabilities. Yet countless products simply require packets of data to be intermittently delivered.
Data-rate requirements and the corresponding power consumption vary significantly between the different device categories (see the table). Open-type devices utilize Pentium class or similar processing and run complex OS-based (operating system) protocols for communication. Such devices require mains power or use large batteries and have battery life measured in hours.
It is critical to reduce power consumption, design complexity, and cost in battery-operated embedded devices through the optimization of computation occurring in the device. This is done via specialized hardware or less flexible purpose-driven software.
Deeply embedded devices build on this optimization and often require battery operation, which creates a critical need for low power consumption. These products utilize low-power microcontrollers such as Microchip’s 16-bit PIC24F family, which features low-power sleep currents down to 20 nA and allows for the use of AA or coin-cell batteries for up to 20 years of operational life.
Examples of deeply embedded, Internet-connected devices are:
• 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
• 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 (Fig. 2). The primary method, called infrastructure or basic service set, 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. 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.
INFRASTRUCTURE CONNECTIVITY A primary advantage of 802.11 over other wireless protocols is its intrinsic ability to connect devices to the Internet. This functionality is provided only through the infrastructure mode of operation, though. The Microchip TCP/IP stack and ZeroG 802.11 radio combination supports both infrastructure and ad hoc modes.For instance, vehicle diagnostics can take advantage of deeply embedded Wi-Fi solutions. Developers spend considerable effort designing the hardware and software for user interfaces in these applications. However, PDAs such as the iPod touch or cellular phones such as the iPhone are perfect for user interfaces with a rich and intuitive feature set. Most include Wi-Fi, which allows the use of infrastructure or ad hoc modes in the ZeroG module.
The PDA or phone can connect to the ZeroG module, and the PIC24F16-bit microcontroller runs the Microchip TCP/IP stack for ad hoc mode (Fig. 3). The PIC24F microcontroller connects to the vehicle using any of the standard on-board diagnostic (OBD) interfaces like J1850, J1939, and ISO 15765-4.
Vehicle status, such as RPM, MPH, and battery voltage, can be displayed in a variety of forms (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.
Conitnue to page 2
LATENCY Latency isn’t a critical factor for data transfers in most deeply embedded devices. This means the data transfer has so little latency that a user can’t 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 experience if the time for a local reaction to a button push on the device is discernible (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.
Remote controls using infrastructure mode will find power-save poll ideal, as it provides the ability to power down without a userperceived 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 also efficiently reduces power consumption in devices where latency isn’t an important issue, such as those that transfer data more than four times a minute. In these cases, reconnecting to the network consumes more energy than keeping the device connected via power-save poll. For example, the ZeroG radio provides the power-save poll mode autonomously to the microcontroller.
An added advantage 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 data is waiting on the access point. In addition, for remote-control applications, a wake-onbutton- 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 isn’t 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 ZeroG 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 ZeroG radio. That mechanism enables the microcontroller and ZeroG 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 these deeply embedded devices, latency isn’t critical. Other applications falling into this category include security or environmental sensors, data-upload services for medical monitoring and consumer-news devices, and information servers.
Deeply embedded devices don’t need 300 Mbits/s, 54 Mbits/s, or often even 11 Mbits/s of throughput. Most deeply embedded devices use a low amount of bandwidth. They have data for transmission a few times a day, or they 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, overall system cost and power consumption remain low.
A normal infrastructure connection provides about a 5- to 10-second reconnect period from the hibernation stage. The connect processing between the ZeroG radio and an access point takes about 176 ms.
Connecting takes longer than this, so most 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. 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 CONNECTIVITY 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 scarcely used for remotes, though. While it does resolve the connection-time problem, the limited use of the wireless technology for simple point-to-point-only communications without local-area network (LAN) or Internet connectivity can be better served by other wireless technologies, such as basic RF transceivers or the IEEE 802.15.4 protocol.One very good application of the ad hoc mode would be as a default mechanism to enable easy configuration of the device onto the network of interest. Deeply embedded products without a screen or 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 either start searching for a predetermined infrastructure network or by creating a pre-determined ad hoc network. In either case, another computer or Wi-Fi-enabled device (e.g., iPhone, smart phone, etc.) connects to the product via the predetermined network and then configures it 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 preexisting networks and the Internet. There’s 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 (Fig. 4). A finite amount of bandwidth is available for all to use before the airwaves saturate with signals. The biggest impact is from clients using that 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%.
The hibernate mode described earlier for power savings also serves, in this case, to minimize the effect of embedded devices on the network. 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 get off the network. The effect of this will be maximum power savings and minimal impact on network-bandwidth capabilities.
Continue to page 3
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 specialize in the art of their own product and not in wireless IP communications.
Often, there’s no room in a critically priced product for more memory to run an operating system, which requires an off-theshelf driver offered by traditional 802.11 solutions. 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 and ZeroG 802.11 example 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 required by a deeply embedded product developer.
Stack-supported services include 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. Customers benefit because they can minimize code-space requirements by selecting only the services they require, time-to-market is accelerated, and they can focus on device application and the user interface, rather than on the underlying communications protocol.
SUMMARY 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/ZeroG 802.11 solution is designed for deeply embedded devices. It considers the speed, bandwidth, and latency needs of embedded devices, which are much less than what most demand for their day-to-day Internet connectivity experience.
As a result, the solution is much lower in power and easier to use than standard IP-connection alternatives. It’s 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, most of these things will be in embedded and deeply embedded devices. The unique characteristic of IP connectivity is that having devices connected and providing improved efficiency isn’t 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 give users simplicity in dealing with things that otherwise go into disrepair, and increased sales pull-through via product and information co-marketing.