Product Design and Development Blogs | Voler Systems

Using ZigBee to Integrate Handheld Tester | Voler Systems

Written by Walt Maclay | Apr 7, 2009 8:00:00 AM

Voler was approached by a service provider with a need for handheld HVAC testers that service field representatives could use when they go to residences and businesses to perform an energy audit for the owners’ heating and air-conditioning systems.

Voler worked with the IT manager and a lead user to develop a written specification to meet their needs. Together we developed a proposal for a testing system with three remote units that are wirelessly connected to a master that plugs into the USB port on a PC.

One remote unit monitors pressure from the air-conditioning compressor and temperatures in the compressor, the other two measure the humidity and temperature of the air coming out of the vents. Once this data is collected in the PC, they use custom software to analyze energy use and generate a report that includes practical energy saving suggestions. The new system with remote sensors enables the service field representatives to do the entire audit in a half-hour on-site. The results are more accurate, and they have to do a lot less retesting, because the equipment is more reliable and easier to use.

Handheld Zigbee Tester

The HVAC service firm’s first questions were “Is this feasible?” and “How much would it cost?” Voler developed a multi-phased approach, starting with a feasibility study, which included an evaluation of the performance of key components. It included developing a detailed specification, prototyping a trial unit, gathering feedback from prototype use to revise the design, and building the final product. At each step, Voler and their client evaluated the feasibility and cost-benefit trade-offs.

During the feasibility stage, one of the biggest challenges was with a ZigBee module that provided wireless connectivity for the different elements of the system. The ZigBee modules have very limited features compared to what they are advertised to do. Many of the advertised features are not included in the default on-board firmware and are only available after you write additional custom firmware.

We evaluated many ZigBee suppliers at the beginning of the project. Many of the modules didn’t do what they claimed to do; they didn’t transmit the distance they claimed to transmit. The features didn’t work as advertised, so we had to actually try them out and verify them. We did this evaluation with manufacturer development boards prior to beginning the rest of the design so that we wouldn’t have surprises later on. This saved the customer and us a lot of time and money, because we looked at four different manufacturer’s modules and had to discard three of them as unsuitable. This was a critical step in developing the product because if we hadn’t qualified the suppliers until the end of the project, we would have had modules that couldn’t meet the customer’s needs. The modules would have already been designed in and it would have been very expensive to change.

 
Zigbee Tester Board and Cover

We selected a ZigBee module that met our distance coverage requirements, but we still had trouble getting all the units to connect with each other reliably. To reduce power consumption, the standard operation of the Zigbee module is to turn on briefly to transmit data and turn off. To consume the least amount of power it is off most of the time. But when it does turn on, it transmits and becomes recognized by the other units.

Initially, this was not done reliably. We contacted the manufacturer, who was responsive but hadn’t faced this question before, so we continued to perform our own internal tests. We ultimately determined that we needed to increase the default time allowed for linking to other devices. We evaluated changing the ZigBee module firmware or using an external microcontroller to manage the operation. For the volume we were dealing with it was less expensive to use a separate microcontroller to control turning the ZigBee module on, timing the operation and then turning it off. The final modules reliably discover the network and get recognized.

At the end of the feasibility stage, we determined this was an attractive solution by evaluating the cost and the development time frame. Voler delivered a prototype, which was tested by the service field representatives to verify field usefulness. Prototyping is a normal part of the process; it allows a low-cost way to make sure that the design intent really matches how it will be used in the field. Sometimes defects are found or the people who will actually use the final product when they have a chance to experience the prototype suggest new features. We encountered a couple of minor items that were not initially thought of and developed a final specification. We then developed and manufactured 50 systems. Currently, they have about 30 service field representatives using these handheld testers in Northern California, Nevada, and Utah.