T he “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