Subscribe to EDN
RSS
Reprints/License
Print
Email

Eyes and ears everywhere: networking embedded devices

Extending the network to deeply embedded devices becomes a reality with low-cost wireless transceivers.

By Nicholas Cravotta, Contributing Editor -- EDN, January 22, 2004

AT A GLANCE
  • Low-cost wireless links can reduce installation and maintenance costs and provide mobility.

  • Battery life is everything, and the most effective way to conserve power is to reduce transmission frequency and length.

  • A hybrid transmission mechanism lets you more efficiently support a variety of applications on the same network.

  • Ease of use is essential when you consider managing hundreds of devices that aren't even smart enough to know they're part of a network.

Sidebars:
Mesh networks
Other considerations

The range of applications for embedded networks is growing as costs drop, considering that manual device management can be extremely labor-intensive. Industrial sensor networks are the foundation of this technology, as are control applications, such as for lighting control. New applications include supply-chain management, in which a mobile endpoint tracks and monitors a package; remote health monitoring, in which sensors collect signals from the human body to send to a monitoring station; and security applications using sensors to quickly secure a location.

Many companies are looking to wireless technology to connect embedded devices and avoid the high cost of installing cable and power lines. Devices such as temperature sensors may send only a few bytes of data every minute. For these applications, high-profile standards, such as 802.11, Bluetooth, and even Zigbee are often too expensive, offer too complex a protocol, and consume too much power. You can neither reliably monitor a factory on X10 technology, nor cost-effectively outfit a light with TCP/IP stacks. Many embedded networks need a low-cost, low-bandwidth wireless link.

Designing an effective wireless network requires understanding the trade-offs involved with using low-cost connectivity. The primary driving factor is power; you don't save much by not having to run a data cable if you still have to run power for a radio. However, you don't want to trade off the burden of manual data collection for the burden of manual battery replacement. To achieve long battery life—that is, several years of continuous use—you have to balance bandwidth, latency, range, topology complexity, security, and versatility.

Fundamentals

An embedded wireless network has several components. Endpoints are the actual devices you want to connect. APs (access points) or gateways aggregate multiple endpoints and often bridge to a wired network. Repeaters or routers connect distant endpoints with APs that are out of range and can provide routing redundancy for mesh configurations. If the APs themselves are wireless (consider the cost of running data cable to various points on a factory floor), you might employ a second-tier, higher bandwidth network to serve as a backbone (Figure 1). You can also aggregate data on a local basis, either wirelessly or via a bus, before hitting the wireless backbone.

A variety of radio options is available. You can purchase a transmit-only RF from Atmel for as little as $1 or a transceiver with a range of 130 ft at a maximum data rate of 10 kbps for $2. WirelessUSB from Cypress offers rates of 62.5 to 235 kbps at a maximum range of 50m starting at $2. For less than $10, you can buy a drop-in module from Xemics offering as much as 152 kbps with a range reaching several kilometers, or the self-configuring i-Bean module from Millennial Net, which operates at as much as 100m LOS (line of sight) at 115 kbps with low power consumption. Higher bandwidth devices are available, such as the WIT2410 from Cirronet, which runs at 460.8 kbps with adjustable output power at 10 or 100 mW, for less than $200 a module. APs range in price from much less than $100 to more than $1000, depending upon the robustness of the network and functions you need to deploy.

Links are available as integrated RF chips or complete modules. Modules often offer much beyond an RF radio, such as ADCs, digital I/O, PWM generators, memory, or an additional processor. Initially, you may want to retrofit the module to existing devices. Modules usually cost more than devices you build yourself, because they come with software and associated APs. Consider the difficulty of at some point integrating the module for cost savings: If you can't solder it onto a host board using an automated assembly system, you will be stuck with a labor-intensive retrofit on your assembly line.

Different endpoints have different connectivity needs. Monitoring devices on a periodic basis offers a consistent flow of data. However, 10 devices transmitting at 5 kbps require 50 kbps, assuming no contention or interference. To prevent contention, an AP could use a TDMA scheme, effectively dedicating bandwidth to each endpoint. This approach is useful for predictable traffic but less useful for bursty transmissions. Although they eliminate the need for traffic back-off and collision mechanisms, unused slots waste bandwidth. TDMA puts a hard limit on the number of endpoints an AP can support; as you add more endpoints, especially if you support mobile endpoints, you reduce the individual bandwidth to each device. You'll want some sort of QOS (quality-of-service) mechanism in place if you plan to approach the limits of your bandwidth. For example, lower priority devices could wait longer than higher priority devices before trying to use a channel, giving higher priority devices an advantage.

Consistent transmission, however, is the fastest way to reduce battery life. To reduce transmissions, you could employ a polling mechanism, in which endpoints transmit only when an AP asks them to. Polling increases bandwidth usage by reducing endpoint contention for the channel but increases the latency between transmissions, limiting response time. Polling also requires a store-and- forward mechanism, whereby an endpoint stores periodic data until it has the chance to transmit.

The store-and-forward mechanism is ideal for mobile endpoints that may temporarily leave the network; you can track a package while it is in the plant, store temperature data during transport, and recover the data when it reaches its destination. Mesh networks often use store and forward where endpoints can relay data from other endpoints or to buffer data when QOS is active (see sidebar "Mesh networks").

An event-driven mechanism enables endpoints to intelligently manage themselves. For example, when its time to water a golf course, you need to know only the moisture and temperature. By transmitting only essential information, this mechanism conserves power and bandwidth. However, it requires a more intelligent endpoint. You also need a "heartbeat" mechanism to make sure that the sensor remains active.

Given that a network may contain several types of endpoints, a protocol that supports a mix of these mechanisms can best use bandwidth and conserve power. For example, you could reserve several TDMA slots for event-driven or bursty transmissions, thus simultaneously supporting periodic and event-driven endpoints with the same AP.

Batteries for life

Battery life depends on length and frequency of transmission and reception. The i-Bean from Millennial Net, for example, can run for eight months on a 220-mAHR battery, if it transmits once per second. Dropping transmission to once every 10 seconds increases battery life to two years. Longer range translates to fewer APs to cover an area, but you need to transmit with more power.

You could determine when a battery fails by waiting until an endpoint stops transmitting. Alternatively, instead of adding a few components to self-monitor battery life, you could employ an RSSI (received-signal-strength indicator), in which an AP monitors endpoint-signal strength and sends an alert requesting a battery change when the signal begins to degrade.

Another way to increase battery life is to design transmit-only nodes, so the device does not burn power having to check for signals on a regular basis. Key to conserving power is not having to listen, so the radio link can drop into a deep sleep. For example, Bluetooth devices need to regularly synchronize to discover new devices. In such cases, servicing the protocol could consume more power than transmitting data.

Key fobs, for example, have no receiver. You need to implement a robust messaging protocol to ensure successful data transmission, because data collision and interference are likely, and message acknowledgment is nonexistent. A home-security system might use transmit-only endpoints to decrease costs. When an endpoint stops transmitting, the system assumes that the endpoint has been compromised; the endpoint signals an event by not signaling.

You can also apply these power-saving principles using a transceiver as a transmit-only device, reserving the receiver for rare instances. The device could either listen on an irregular basis for broadcast messages or transmit a "ready-to-receive" message to let the AP know when it is listening. Adjustable transmit power allows you to tune transmissions so that you use only as much power as necessary to reach the AP.

With low enough power consumption, you may be able to run the link parasitically off the embedded device, an important characteristic if you plan to integrate the link into your next generation of devices. If you need to know only the location of mobile endpoints, consider using much less expensive RFID tag technology.

Registration and intelligence

Registering devices on a network presents serious ease-of-use challenges. Automatic registration of devices by an AP eases the process but in exchange for a loss of control. When security is an issue and you don't want an endpoint to connect to a neighboring AP or if you want an endpoint to register with a particular AP when several are within range, you might use a manual process to link the endpoint to the AP. Even with automatic linking, devices have only ID numbers, which tell nothing about the devices' locations in the network. You need a means of clearly mapping out the topology of the network, as well as intelligently naming devices and fixing physical locations. It does little good to know that sensor 54332 has declared a temperature-threshold event if you don't know the physical location of the sensor. Even boiler_temp_sensor_57 leaves much to be desired.

To ease the attachment process, especially in networks with thousands of devices, you might consider having a PDA serve as a mobile endpoint. Instead of having a second technician in a control room to record the placement of a sensor, the technician placing the sensor could use the PDA to register, name, and describe the location of a device. It is easier to develop software for PDAs, and they are much less expensive than proprietary handheld instruments to replace if you drop them. Note that PDAs do not necessarily need to connect to the network; they could employ a store-and-forward mechanism for registration.

A question always arises concerning where in a network intelligence should reside. Implementing a Web server in an endpoint to support remote control and management eliminates the need for centralized control but seriously increases the cost of each endpoint. Such intelligence might make sense to implement in an AP, which could query an endpoint and wrap the data itself. This approach increases the cost of the AP but enables myriad new control and monitoring features.

However, the ability of an endpoint to manage its own thresholds and events is a key method of increasing battery life. Consider how much processing overhead a module offers and the development environment for adding intelligence and features to the module.

Given the aggressive innovation in low-cost RF technology, carefully plan how you will migrate devices and how legacy endpoints and APs will support new features (see sidebar "Other considerations"). As volumes increase and prices drop, new capabilities and capacities will emerge. For example, the Z-Wave from Zensys, which integrates RF, a microcontroller unit, flash memory, and a plug-and-play mesh protocol at a 9.6-kbps data rate, currently costs $5 in volume. The company plans to release a second-generation part in the second half of 2004, which will reduce the price to $2.50, and a ROM version that will cost $1 by the end of 2005.





 

Author Information
You can reach Contributing Technical Editor Nicholas Cravotta at editor@nicholascravotta.com.

For more information...

For more information on products such as those discussed in this article, contact any of the following manufacturers directly, and please let them know you read about their products in EDN.

Atmel
www.atmel.com

Cirronet
www.cirronet.com

Cypress
www.cypress.com

Ember
www.ember.com

Mesh Networks
www.meshnetworks.com

Microchip
www.microchip.com

Millennial Net
www.millennial.net

Nanotron
www.nanotron.com

NEC
www.nec.com

Toshiba
www.toshiba.com

Xemics
www.xemics.com

Zensys
www.zen-sys.com

RSS
Reprints/License
Print
Email
Talkback
Canon Resource Center

Featured Company


Most Recent Resources

Advertisement
Related Content

No related content found.

  • 0 rated items found.
Advertisement

KNOWLEDGE CENTER

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Engineering Careers
Jobs sponsored by
Advertisement
About EDN   |   Site Map   |   Contact Us   |   Subscription   |   RSS
© 2012 UBM Electronics. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other UBM Canon sites

UBM Canon | Design News | Test & Measurement World | Packaging Digest | EDN | Qmed | Pharmalive | Appliance Magazine | Plastics Today | Powder Bulk Solids | Canon Trade Shows