Deciding on ZigBee

Deciding on ZigBee

CHAPTER 2 Deciding on ZigBee One of the first questions I get from an OEM is, “How does ZigBee compare to wireless technology X?” So before I get int...

303KB Sizes 1 Downloads 80 Views

CHAPTER 2

Deciding on ZigBee One of the first questions I get from an OEM is, “How does ZigBee compare to wireless technology X?” So before I get into the technical details of how ZigBee works, perhaps it would be good to spend a bit of time on what ZigBee is really good for, what it is not good for, and how it compares to some other popular, competing networking technologies. I have seen plenty of companies trying to shoe-horn ZigBee into a problem space that just doesn’t make sense for the technology, and I’d like to help you avoid that. Another common question put to me is, “What does ZigBee cost?” That is a complicated question. Obviously a book is not the right medium to keep current on prices, but it can help you ask the right questions, and describe “hidden” costs, some of which you may not have considered yet. I love ZigBee. ZigBee is great! But I am also an engineer, and I like to consider a variety of factors before deciding on the solution that is right for any particular problem. And yet another question I am often asked is, “So what does ZigBee stand for?” Well, I’ll tell you. There are many people who expect that ZigBee is an acronym and they are actually correct, even though the acronym has been forgotten over time. The acronym represents the attributes associated with the original ZigBee objectives, which sort-of evolved into a mission statement for the technology. “ZIGBEE” originally stood for a “Zonal Intercommunication Global-standard, where Battery life was long, which was Economical to deploy, and which exhibited Efficient use of resources.” Two other objectives were added a short time later: “Reliable” and “Secure.” But by then, of course, it was too late to change the name. In addition there was concern among the promoter member companies that ZigBee might not get taken seriously, and that their respective companies might not pay for travel to the exotic locations hosting the ZigBee Alliance quarterly meetings if they added the other two letters to the original acronym, forming the new one: “ZigBeers.”

w w w.new nespress.com

CH02-H8597.indd 45

7/26/2008 12:36:20 PM

46

Chapter 2

2.1 Deciding on the Right Technology This is a book about ZigBee. But ZigBee isn’t always the right solution for a given problem. This section discusses some other possibilities for networking sensors and control devices, and some of the advantages and disadvantages of each approach.

2.1.1

Wired Versus Wireless

Wireless is inherently unreliable. Does this sound strange coming from a proponent of ZigBee? It’s true. There are so many factors that affect wireless; RF noise coming from machinery, changes in the physical environment, even the vagaries of the atmosphere. In the 2.4 GHz spectrum, which is the ISM band used by ZigBee, there is even more interference. Water, people, concrete, metal, foliage can all change the wireless characteristics, causing packet delivery to fail. Now granted, ZigBee, with its mesh networking and per-hop and end-to-end retries and acknowledgments, turns what is an essentially unreliable medium into a very reliable network, but ZigBee is not the only solution to network devices. A wired network doesn’t have any of the above problems. But wires do have problems of their own. Wires have connectors, and connectors get broken over time, especially if they are plugged in frequently. The wires themselves get caught on things and get cut. One major white-goods manufacturer I spoke with was changing over the entire production line to wireless to avoid just this problem. A wireless system can test and inspect the washing machines, dryers and refrigerators coming down the line without any of the drawbacks of wires. Salt and water corrode wires. A wire on a ship corrodes or chafes over time, and so becomes less reliable than a wireless solution in that same environment. Wired solutions can be more expensive per foot. At a recent building construction show, the number used was $10 US per foot (2007 dollars) for wired control. That $10 is not in just the cost of the wire, but the cost of conduit, installation, and maintenance. In a similar situation, ZigBee wireless is generally considered to cost less than $0.10 per foot, including the cost of the wireless boards and installation. But there are many good, prominent wired protocols and hardware out there. Don’t just jump into wireless because it’s the next greatest thing. Determine first if wireless is a great thing for your application. Wires don’t have the interference problems of wireless, but wires need connectors.

www.n ewn es p res s .c o m

CH02-H8597.indd 46

7/26/2008 12:36:21 PM

Deciding on ZigBee

2.1.2

47

Other Wireless Technologies

802.15.4 is a great MAC and PHY specification, and ZigBee, which relies on the 802.15.4 MAC and PHY, is a great networking protocol. ZigBee is well-targeted at the wireless sensor and control network space. But 802.15.4 is not the only radio which targets this space, and ZigBee is not the only networking protocol which runs on the 802.15 MAC and PHY: ●

Non-ZigBee 802.15.4 radios are not supported. One thing that is not obvious to the casual observer is the fact that ZigBee runs only on 2.4 GHz (ISM band) 802.15.4 radios. The 802.15.4 specification allows for 900 MHz, and 868 MHz radios as well, but ZigBee doesn’t run on those radios, due mainly to data rate. ZigBee requires a higher data rate than the 40 kbps offered by the 900 MHz standard and 20 kbps offered by the 868 MHz standard. The 2.4 GHz 802.15.4 specification operates at 250 kbps, a rate sufficient for the ZigBee protocol. The newer 2006 802.15.4 specification offers higher data rates in the sub-1 GHz RF spectrum, but those have not yet been adopted by ZigBee. The other reason ZigBee chose the 2.4 GHz spectrum is that products can interoperate worldwide in this RF space.



Wireless USB is emerging as a great technology for small, battery-operated devices. For example, the Cypress CYWUSB6934 is used in a number of pointto-point devices such as a wireless mouse. This technology is very inexpensive, great on batteries, but is not meant to function on a scale as large as ZigBee can, and doesn’t have the security. Wireless USB is based on Ultra Wideband (UWB) which supports 480 Mbps data rate over a distance of two meters (about 6.6 feet). If the speed is lowered to 110 Mbps, UWB will go a longer distance (up to 10 meters or about 30 feet). This technology generally focuses on the PC peripherals, but could be adapted to the sensor and control space.



WiFi™ is also starting to see more use in sensor and control networks. WiFi is a ubiquitous, well understood technology that previously targeted the PC and laptop space. It’s a bit more expensive than ZigBee, typically requiring a larger CPU to run the full protocol. WiFi can mesh like ZigBee and if you Google “WiFi mesh” you’ll see a number of vendors that serve this space, but there are no interoperable standards for meshing WiFi. WiFi is not as good with batteries, using up batteries in hours, rather than the months to years of ZigBee, but not all control networks require batteries.



Bluetooth™ is very secure, and is used in headsets and cell phones everywhere. Bluetooth is relatively inexpensive, but due to its frequency-hopping technology,

w w w.new nespress.com

CH02-H8597.indd 47

7/26/2008 12:36:21 PM

48

Chapter 2 does not have the battery life of a ZigBee device. Think of Bluetooth battery life as days, not the months to years like ZigBee. Also, Bluetooth doesn’t scale well and is typically limited to networks of seven devices or less, whereas ZigBee networks can contain thousands of devices. ●

Wibree falls under the Bluetooth Special Interest Group, and is aimed at watches and body sensors. It’s designed to be very, very low power, but again is limited in the number of nodes in a network. At the time of this writing, Wibree was not in production, but still in the specification stage.



Z-Wave, by Zensys (see http://www.zen-sys.com), is useful if you are planning home automation products. Z-Wave is aimed specifically at the home automation space, and while not a standard (Zensys is the only manufacturer of Z-Wave), it is used by some of the large home automation manufacturers, including Danfoss, Leviton, and Universal Electronics. The new ZW0301 contains a 32 K flash 8051 CPU, and a radio that operates in the 868 MHz space for Europe and the 908 MHz space for the U.S., at 9 kbps (compared to ZigBee’s 250 kbps). Zensys is naturally worried about ZigBee, because these two technologies compete directly, and so Zensys has formed a group called the Z-Wave Alliance, and regularly releases white papers promoting Z-Wave over ZigBee.



Proprietary radios are still the norm today. I remember this used to be the case in operating systems, too. Everyone had their own system, but while there are still quite a number of proprietary operating systems, most OEMs realize it is cheaper in most cases (all things considered) to go with a commercial operating system. I believe this will happen to radios over time in this space. There are so many good radios in various RF frequencies. Texas Instruments makes one called the Dolphin. Nordic Semiconductor makes a variety of low power radios, such as the nRF2401A. The biggest issue with the proprietary radios is the lack of a protocol. So much of RF communication is in the software. If you have to write your own, it can cost significant amounts of development effort, which equals time and money. Which brings me to software protocols.

ZigBee operates in the worldwide 2.4 GHz ISM band. Proprietary radios are the primary competitor of ZigBee today.

www.n ewn es p res s .c o m

CH02-H8597.indd 48

7/26/2008 12:36:21 PM

Deciding on ZigBee

2.1.3

49

Other Software Protocols on 802.15.4 Radios

The 802.15.4 radio (MAC & PHY) specification provides the foundation for the ZigBee networking protocol, but ZigBee is not the only protocol that runs on these radios: ●

802.15.4 MAC may work for you. Yes, it’s possible to build a network with only the 802.15.4 MAC and PHY. Most 802.15.4 silicon vendors offer an application development solution on their 802.15.4 MAC. Granted, it’s only point-topoint or a star network. Granted, it doesn’t have device or service discovery or interoperable applications like ZigBee. But, a MAC-only solution does have a smaller footprint than ZigBee and might be enough networking protocol for your application. The MAC uses the same per-hop retry mechanism that ZigBee uses, the same network associate commands, and the same sleepy end-device polling commands. What the MAC-only solution is missing is the applicationlevel compatibility and the higher reliability and multi-hop nature of mesh networking.



SimpliciTI™ may work, too. This Texas Instruments protocol is a simple, pointto-point, or repeating protocol for use with their 802.15.4 radios and solutions. This protocol is extremely small (4 K flash), and they tout it as being extremely simple. There are only 6 API calls.



Synkro, originally by Freescale Semiconductor, is now an emerging standardsbased protocol targeted specifically at the consumer electronics space. This protocol uses 802.15.4 radios and solutions to control televisions, DVD players, stereos, and the like. Sony is one of the early adopters of this technology and it looks as if the standard might take off. It’s still too early to know at the time of this writing, but the consumer electronics manufacturers are looking to avoid the IR fiasco (too many proprietary control methods), and instead focus on standardized RF for the remote. Synkro is point-to-point, not meshing, but does offer a form of frequency agility to avoid potential interference problems.



MiWi, by MicroChip, is a peer-to-peer and mesh protocol specifically targeted at the Microchip MRF24J40 radio. This protocol has no cost associated with it if used with the MicroChip solutions.



PopNet™, by San Juan Software, is a small-footprint full-mesh solution that could be considered “ZigBee Lite.” Like ZigBee, PopNet supports broadcasting, unicasting, and mesh route discovery. Unlike ZigBee, PopNet fits into 16 K of flash and does not require ZigBee certification.

w w w.new nespress.com

CH02-H8597.indd 49

7/26/2008 12:36:21 PM

50

Chapter 2 ●

TinyOS is a mesh networking technology written in a language called NesC. This C-like language allows sensors to be treated as objects. TinyOS was even adopted by one of the ZigBee stack vendors, MeshNetics, as the foundation for their ZigBee solution.



6LoWPAN, standardized by IETF.org, is an 802.15.4 networking protocol that looks similar to IPv6. Companies such as ArchRock (http://www.archrock.com) are promoting this emerging standard for interfacing sensors to the World Wide Web.

All of these protocols have their own strengths and weaknesses. And there are plenty more protocols! With the exception of PopNet, and a vanilla 802.15.4 MAC, I have not personally written software or produced products using the other protocols, so I won’t try to give advice about which one is best for your particular application. I did, however, want you to be aware that ZigBee isn’t the only networking protocol available on 802.15.4. But ZigBee is the primary protocol based on 802.15.4, so if standards or interoperability are important to your application, ZigBee is the route to go. ZigBee is the primary networking protocol based on 802.15.4 radios, but many other protocols are also commercially available.

2.2

Deciding on a ZigBee Solution

Okay, so you’ve decided ZigBee is the right solution for your product. Now, which ZigBee solution is best? Sorry. I can’t answer that. But I can give you a set of questions to think about. At the time of this writing, some of the 802.15.4/ZigBee radio vendors (also called ZigBee silicon providers or platform vendors) include: ●

Atmel



Ember



Freescale



Integration Associates

www.n ewn es p res s .c o m

CH02-H8597.indd 50

7/26/2008 12:36:21 PM

Deciding on ZigBee ●

Jennic



Microchip



NEC



Oki



Radio Pulse



Renesas



ST



Texas Instruments

51

In general, the easiest way to learn the latest details of the 802.15.4 offerings from these vendors is to go to the World Wide Web. All the vendors include PDF data sheets and various white papers to show why their solution is best. The Web sites for larger corporations (which have vast and often confusing Web sites) tend to include a simple way to find information on their ZigBee products, such as http://www.freescale. com/zigbee, or http://www.ti.com/zigbee, or http://www.st.com/zigbee. For smaller companies, the ZigBee information tends to be found somewhere on their home page. Below I’ve compiled a list of questions you should ask yourself when evaluating each platform vendor: ●

Is the platform certified?



Will the product use an integrated MCU/radio or a stand-alone radio?



Does the platform have enough memory for the application?



Does the price-point make sense for the product?



Is the part low-power enough for the power supply?



What voltage range does the part support?



Does the part support all the required physical characteristics?



Are you familiar with the silicon vendor?



How good is the stack?



What tools are available to support compiling and debugging?

w w w.ne w nespress.com

CH02-H8597.indd 51

7/26/2008 12:36:21 PM

52

Chapter 2 ●

What reference designs are available?



What is the availability of the radio?



Is an alternate supplier a requirement?

Is the ZigBee platform certified? A combination of the radio, MCU, and ZigBee stack software is called a platform by the ZigBee Alliance. Some ZigBee platforms are certified by the ZigBee Alliance, and some are not. Is this important to you? If your product will interact with products from other companies, such as Home Automation, Smart Energy, or Commercial Building Automation, I would say the answer is a resounding, “Yes!” The platform you choose must be certified. If your product will be a stand-alone network, then the range of vendors opens up. Be sure to check when evaluating a vendor. A non-certified stack may not work with other ZigBee stacks. Will the product use an integrated MCU/radio or a stand-alone radio? OEMs using ZigBee often choose an integrated MCU and radio. This combination can be very cost-effective, allowing both the ZigBee networking protocol and the application to reside in a single chip, 8-bit solution. The single chip solution offers the advantage of containing everything required for the application except a power supply and sensors (see Figure 2.1). The MCU will contain memory, UARTs, even LCD, LED, or keyboard controllers, and (hopefully) enough RAM and flash (ROM) to host your application. Most single-chip solutions are built on an 8-bit processor, often an 8051 (although some of the newer parts, such as Freescale’s MC13223 contain a 32-bit ARM7). Check with your vendor for their latest offerings. The single chip solution works fine for many applications. But sometimes, an 8-bit MCU just doesn’t have the memory or raw processing power that is required. It may surprise you (it did me), but variable airflow valves (VAVs), those vents you see in the ceiling of every office building, use a 32-bit CPU with a very complex application to control the opening and closing of the vent. If you are choosing a stand-alone 802.15.4 radio with some host CPU, the main question is whether ZigBee will need to run on that host processor. ZigBee normally runs as software (including a small OS or kernel), much like Windows or MAC OS X runs on

www.n ewn es p res s .c o m

CH02-H8597.indd 52

7/26/2008 12:36:21 PM

Deciding on ZigBee

53

The Freescale Solution ZigBee Hardware

Software

CPU Application(s)

Flash Memory

Gateway (UART) Interface

RAM UARTs

ZigBee Stack

SPI GPIOs & A2D 802.15.4 MAC

802.15.4 Radio

Chip

Figure 2.1: ZigBee Chip Solutions Contain Everything Needed for the Application your PC or laptop. If you plan to use, for example, an ARM 9 with a stand-alone 802.15.4 radio, does a ZigBee stack run on that combination? The answer is often, surprisingly, “No.” Most ZigBee implementations run really well on the integrated MCU/radio solutions, but may not be portable enough to run on another MCU, or the silicon vendor who supplies the ZigBee stack may not be willing to release full source code. Most don’t. Another way to use whatever CPU you need for your application, and still use ZigBee for the networking communications, is to treat the ZigBee integrated chip as a communication “module” (see Figure 2.2). The ZigBee stack and a small serial

Host MCU

ZigBee Chip

Figure 2.2: ZigBee as a Communications Module

w w w.ne w nespress.com

CH02-H8597.indd 53

7/26/2008 12:36:21 PM

54

Chapter 2

“gateway” application run in the single chip solution, while the main application runs on the host processor, talking to ZigBee through a UART. Does the platform have enough memory for the application? It might surprise you, but ZigBee is quite large. As a protocol designed for 8-bit devices, ZigBee often stretches the limit, using most of the CPU’s RAM and ROM, leaving only a few kilobytes of flash left over for your application. When evaluating vendors, make sure you first do a code-size estimate for your application. Then, using the development kit from the vendor, build the Home Automation On/Off Light application (nearly every vendor offers this application) for a ZigBee Router device. Check in the .map file to see how much room is left for your application, both in terms of flash (ROM) and RAM. Is there enough? Because there are so many options in ZigBee, it can sometimes be a pretty big task to configure the stack to include only those pieces that your application needs. Feel free to call the vendor’s support line, or to check out their online help. This will also help you evaluate the vendor’s ability to support your product development. Does the price-point make sense for the product? The price of a solution is not just the price of the silicon. I often see customers say, “Well, this chip is $0.05 cheaper!” when the cost of the external components required for the radio to function make it significantly more expensive than the alternatives. Consider the following production costs: ●

What external components are required?



Can the board layout be two-layer, or must it be four-layer?



What quantity will I ship? This can greatly affect price per unit.



Do the cost of the tools make a significant difference?



How solid is the software? Will it require significant development or debugging effort?

Only after you’ve evaluated all of these questions can you determine the real cost of that particular solution. First, create a bill-of-materials (BOM), and then price them out with one or more distributors. Consider also the cost of manufacturing. Some solutions require only two layers on the board, which makes manufacturing costs less. Others require four layers, which increases manufacturing costs.

www.n ewn es p res s .c o m

CH02-H8597.indd 54

7/26/2008 12:36:21 PM

Deciding on ZigBee

55

One cost that is not always considered is the cost of the software. It used to be that hardware was the major cost in any given design. Today, more and more, it is the cost of the software that really makes or breaks a product. Is the part low-power enough for the power supply? All 802.1.54/ZigBee radios can go into low-power modes. When evaluating low power for a particular radio or single-chip solution, consider both the wake power and the sleep power. The sleep power, for most applications, dwarfs the wake power (and makes the wake power almost irrelevant). Put together a little spreadsheet, or use the power calculator provided at http://www.zigbookexamples.com, and you’ll see why this is. If a node only wakes for a few milliseconds every few minutes, then power consumption while sleeping is everything. This may be irrelevant if your application does not require battery-operated nodes. What voltage range does the part support? One thing that might not be readily apparent is that battery supplies vary widely in the voltage they can produce with a given charge. Some of the longer-lasting battery technologies (some that will last 20 years or more) start out providing five volts and end up providing only two volts. Many 802.15.4 radios (or MCUs) cannot deal with such a wide range without a power regulator which completely defeats the long battery life (power regulators consume power). So, make sure to match the batteries to the radio. And don’t forget all the other power consumers on the board, including sensors. Does the part support all the required physical characteristics? Sometimes temperature, shock, or other factors are required for a given application. Will the radio be in the tire of a car? It had better withstand Phoenix heat and Fargo cold. Most ZigBee radios are in the industrial range of ⫺40 to ⫹85 Celsius. Are you familiar with the silicon vendor? One factor that plays into both schedule and cost is familiarity. If your company (or you personally) have worked with a particular vendor before, you may prefer to stay with that vendor; you know the quirks of their parts, tools, and sales processes. This can have a significant impact on both cost and schedule. Start out with the vendors you know. Then evaluate other vendors as appropriate.

w w w.ne w nespress.com

CH02-H8597.indd 55

7/26/2008 12:36:21 PM

56

Chapter 2

How good is the stack? Not all ZigBee stacks are created equal. ZigBee is a complicated specification with many edge cases. I’ve seen many stacks not take care of even the basics, in their first incarnations. Here are a few tests for you to try before wasting your time building an application on an unstable stack: Build a diamond network with a light on one end and a switch on the other. Alternatively, turn off the middle nodes. Does the stack recover a route and turn the light on every time? For more on this, see Chapter 4, “ZigBee Applications.” Turn on 20 nodes at once. Does the stack handle it gracefully, and do all the nodes join the network? Run a test in a secure network, with a node sending a packet via APSDE–DATA. request to another node two hops away. Put a 32-bit incrementing counter in the payload, to show the number of messages sent. Send a packet after every data confirm. Let this test run for a few days. Is the stack still sending the packet? Is the number of messages sent reasonable? Expect at least one message every 100 ms or less. Build a max-depth network for the stack profile (10 hops across in stack profile 0x01, 30 hops in stack profile 0x02). Can the stack send from end-to-end? What tools are available to support compiling and debugging? The proper tools can make a significant difference during development of a product. Are your developers already familiar with the tools? Do they allow your developers to debug efficiently or are they wasting significant time fighting tools? Do the tools provide the information needed in a clear, easily understood presentation? It can be so frustrating trying to debug an application that cannot set sufficient breakpoints, or does not detect NULL points. What reference designs are available? Reference designs can save time and money when building custom 802.15.4 boards. All silicon vendors offer reference designs for their radios and MCUs. A reference design will usually include a full schematic and a bill-of-materials. A word of caution to those of you who make your own boards: you may build boards in your sleep, but building RF boards is another thing. I’ve seen so many projects fail

www.n ewn es p res s .c o m

CH02-H8597.indd 56

7/26/2008 12:36:21 PM

Deciding on ZigBee

57

because the engineering house thought it knew how to build the RF board, only to find that they couldn’t build it to production quality with a sufficient radio range. Consider outsourcing board layouts to a company that has a proven track record, or consider using modules in your design. Everyone thinks they will ship millions of copies of a given product. But why not get your initial production going using off-the-shelf, precertified boards (aka modules), and then do a cost-reduction phase later? In most cases, you’ll be better off with this approach. What is the availability of the radio? Sometimes companies forget to consider supply carefully enough. Sometimes, a project will begin and plan to use a silicon product not yet in production. The vendor you work with says it will be in production in June, but June comes and goes, July and August come and go, and pretty soon your product is late or canceled or you must scramble to find another solution, because the vendor’s silicon is just not ready. My advice is to only plan products on silicon that is already in production. Also, make sure that the supply will be big enough for you. Sometimes there is supply now, but the silicon manufacturer won’t be making another run for two more years. Perhaps the fab is used for something else in the meantime, or the company uses a third-party fab. It’s a shame to have a successful product, only to run into supply problems. Is an alternate supplier a requirement? Some vendors will not consider a technology without multiple suppliers of that technology. That’s one of the great things about ZigBee. There are so many suppliers. But while ZigBee speaks the same language over-the-air, ZigBee does not have a common software API. If you have a product that requires multiple suppliers, design your application software so that it is portable among stack vendors. Carefully consider all aspects of your design when selecting hardware. See http://www.zigbee.org for a complete list of ZigBee silicon and solution providers.

2.3

ZigBee Modules

A ZigBee module is a board that is manufactured “application-ready.” The module will almost certainly be government-certified, including CE Marking in Europe,

w w w.ne w nespress.com

CH02-H8597.indd 57

7/26/2008 12:36:21 PM

58

Chapter 2

IC in Canada, and FCC in the U.S. The module will certainly have various I/O pins, including binary GPIOs, and analog-to-digital pins. The module can be battery-operated, and comes in a usable form, sometimes with a common connector to attach the module to a motherboard (see Figure 2.3). I can’t say enough good things about ZigBee modules. Modules save you money and time, and until your production reaches the millions of units, there is rarely a good reason to build your own board (other than it’s fun and you’ve always wanted to build your own RF board, anyway). Figure 2.3 shows a variety of modules. Simply google “ZigBee Modules” to get a sampling of what modules are available. At the time of this writing, some popular ZigBee modules are built by Panasonic, MeshNetics, LS-Research, Digi, Cirronet, AeroComm, and many others, representing all the major ZigBee vendors. Ask your hardware vendor what ZigBee modules they can recommend. All the ZigBee module vendors offer some sort of development kit, which includes a larger development board where power can be easily applied, sensors and other peripherals can be added, and application software can be downloaded.

ZigBit Module with Dual Chip Antenna

Part number: ZDM-A1281-A2 PAN4555

Apex and Apex LT

Freestar

Figure 2.3: A Sampling of ZigBee Modules

www.n ewn es p res s .c o m

CH02-H8597.indd 58

7/26/2008 12:36:21 PM

Deciding on ZigBee

59

Other module vendors provide a “wire-replacement” or other application to use ZigBee communications without knowing anything about ZigBee. Simply connect the module to a UART on two more devices, send a few Hayes-style AT commands and you have a mesh network. Easy! Most modules are priced for the under-100 unit OEMs. But generally, if your company will ship volume products, a better price per unit can be negotiated. These same modules can be used with any protocol (802.15.4 MAC, ZigBee, proprietary) that runs on 802.15.4 radios. If you later replace the modules with custom boards, the software does not change, except possibly for a few low-level drivers interacting with LEDs or other pins. Okay, one more plug for modules. I have seen many projects fail because of overconfidence from the hardware design group. They’ve created printed circuit boards in their sleep. They’ve shipped many successful products, and know how to make a board. They’ve looked at modules, but none of them are just perfect. So they embark on making a custom board, only to find six months later that RF is hard. Really hard! Subtle things, such as a technical balan that matches the specification but doesn’t perform as expected, can cause delays. Perhaps the range available from the radio is just not what it should be. Perhaps there is noise near the chip that interferes with the application. Perhaps the antenna design just isn’t doing what the simulations say it should. Do yourself a favor. Use a module, at the very least, through the Beta phase. For many products, modules are cheaper even in the long run. They are certainly cheaper in the short run. Save the custom RF board during the cost reduction phase of the product.

2.4

A ZigBee Checklist

This is really just a list of things to remember when building a ZigBee application. There is no right or wrong answer, and this certainly isn’t a definitive list, but make sure you’ve thought about each item below. Hopefully they will save you some time and money, more than you’ve spent on this book. Protocol Selection How often does the application need to communicate? Think of all nodes that need to speak and develop a worst-case “bandwidth” simulation. Can the application be less “chatty?”

w w w.new nespress.com

CH02-H8597.indd 59

7/26/2008 12:36:22 PM

60

Chapter 2 ●

Does the protocol need to speak 802.15.4? ZigBee?



Is simplicity (a shorter learning curve) more important, or is compatibility with industry standards more important?



How large will the expected network be? Normal case? Largest configuration? Is it better to ship more quickly with a smaller network size target?



Will it interact with products from other OEMs?



Will other networks be in the vicinity? Other 802.15.4 networks? Will they cause interference?



What security is required by the application?



Is low latency more important or low power?



How important are gateways? To a host processor? To a PC? The Internet?

Hardware Selection ●

Will a ZigBee module work for the Proof-of-concept? Beta? Production?



What power supply will be used? Does the hardware selected support the appropriate voltage across the life of the power supply?



Develop a power budget. What are all the power consumers on the board?



Is size an issue? Does the package need to fit into a small space? How small?



Is range important? What type of antenna will be used?



Are there any MCU hardware or peripherals that are particularly important to the application? For example, is a second SPI port needed? A UART?



Is time important to this application? Is an external crystal needed for accuracy while in low-power mode?



Is the price range for the part acceptable?



What other hardware is needed beyond the hardware provided by the primary 802.15.4 silicon vendor? Will they have any troubles working together?

www.n ewn es p res s .c o m

CH02-H8597.indd 60

7/26/2008 12:36:22 PM

Deciding on ZigBee

61

Stack Selection ●

Is the ZigBee stack certified? If not, is compatibility important?



How easy is it to set up a 12 node network? Set up as large of a network as you can when evaluating a stack. Many problems don’t appear with just a few nodes. Try 20 or more, if possible.



Have you done the diamond network test (verify automatic route recovery)? If not, see Chapter 4, “ZigBee Applications,” for a complete explanation.



Try turning on all the nodes, to join the network at once. Does the network figure it out and eventually allow all nodes to join? This test can be tough for some stacks.



On the selected hardware, how much room does the stack leave for your application? In ROM (Flash)? In RAM?



Does the application use a ZigBee public Application Profile? If so, is the one from the stack vendor good enough? How much work is needed to go from a technology demo to commercial quality on this profile?



What software is needed, beyond what the stack vendor provides, to complete this application?

Application Development ●

How many developers will be on the project? Do they have sufficient tools? Are they familiar with the tools, or will there be a learning curve?



Would ZigBee or protocol training be helpful for your staff?



Is a protocol analyzer (such as Daintree) budgeted for? Plan at least one for the group, perhaps one per developer.



Can the application be developed in parallel to the hardware? If so, are the silicon vendor reference boards good enough? Are ZigBee modules needed?



Plan to build a mock-up test in the intended physical environment (at the loading docks, for example). How many nodes are needed? What test software is needed to capture the proper test data? Can a network of proper size be built ahead of time using a mock application?



How will the software be tested? Will there be an automated nightly build?

w w w.new nespress.com

CH02-H8597.indd 61

7/26/2008 12:36:22 PM

62

Chapter 2 ●

Think about in-field testing? How will this be conducted? How will the application be debugged in the lab? In the field?



What debugging diagnostics are needed to ship with the product?



Is a watchdog used? Under what conditions?



How real-time does the application need to be?



How will the application manage non-volatile memory (persistent storage)? Are there other ZigBee tables or memory that must be managed by the application? If so, what are they?



Think about designing the application so that it is portable between processors and stacks. Is the application paying attention to the Endian-ness of its own application protocol? Will a mixed network be used with different Endian MCUs?



Is any application code that is stack-specific separated from application code that is stack-neutral?



Is it better to write the application in-house, or hire a third party already familiar with ZigBee and Networking?

Manufacturing ●

Will units be manufactured in-house? If so, how will they be managed?



If manufactured out-of-house, can they meet your volume and schedules? What tools do they have for serializing the board images?



How will MAC addresses be assigned to each board? How will they be managed? Do they need other information assigned at manufacturing time?



How will the nodes be packaged?



How will they be shipped? Are the radios excluded from air shipments (which don’t allow RF)?

Deployment ●

Who will be the installer(s) of the network? How simple does it need to be?



How will the installer(s) know if routers are near enough to each other?

www.n ewn es p res s .c o m

CH02-H8597.indd 62

7/26/2008 12:36:22 PM

Deciding on ZigBee

63



Does every node in the network at least have two routers within hearing range? How will the installer know?



How will the installer verify that everything is installed correctly?



Will the network be built in pieces, such as one hotel room at a time? Or will the network be built out from the center?



Does the application take care of all commissioning simply and easily for the user?



How will nodes be replaced if they break, or stop functioning over time?

w w w.new nespress.com

CH02-H8597.indd 63

7/26/2008 12:36:22 PM