Cut the T&M Cord

Over the years, test-and-measurement equipment has evolved from stand-alone instruments, such as digital voltmeters and oscilloscopes, to add-in cards that transformed a PC into an instrument. As users became more sophisticated, vendors moved virtual-instrument cards out of PCs and onto specialized buses such as cPCI, VXI, and PXI. Instruments based on these buses look nothing like traditional test equipment. Typically, an attached PC runs prepackaged programs or custom code to control operations and perform data analysis tasks.

These types of instrument systems communicate with a host PC either directly over the instrumentation bus or through a hardwired communication connection such as Ethernet. That "tethered" connection limits the flexibility of some test systems, so engineers have "cut the cord," and now employ wireless communications between their instruments and a computer. That form of communication offers several advantages including mobility, ease of connection, electrical isolation, limited network access, and enhanced security.

Wireless access secured

Mobility, ease of connection, and electrical isolation require no further explanation. In the area of security, a wireless link can establish a connection only to a specific instrument, thus improving security by moving direct instrument control off of a corporate network. Security also works two ways—hackers can't crack test apparatus and people will access to the apparatus can't hack the corporate network. At least one company lets its engineers use their personal digital assistants (PDAs) as wireless "keys" that unlock specific equipment or test sequences. To increase security, the HP h5500 family of PDAs accepts a fingerprint reader. HP recommends people scan several fingertips so a cut or scrape won't block access.

Many early adopters who combined wireless communications and instrument systems relied on laptop computers. But PDAs offered by companies such as Palm, Compaq, Toshiba, and Dell provide reasonably fast CPUs, lots of memory, color displays, and several input devices—a stylus, pushbuttons, and a fingertip mouse. Thus, PDAs often serve as economic alternatives to bulky laptops.

These days, almost all PDAs provide Wi-Fi (IEEE 802.11b) or Bluetooth (IEEE 802.15.1) communications. Wi-Fi links offer faster communication rates, greater range, and more network nodes than Bluetooth. But Bluetooth requires less underlying software and draws less power than does Wi-Fi circuitry. In addition, two Bluetooth systems can automatically start to communicate. Thus, for short-range portable applications, Bluetooth provides an economic alternative. (Use caution when specifying wireless test systems for international use. The frequency bands established for Bluetooth communications may vary by country.)

ZigBee (IEEE 802.15.4), a new wireless mode aimed at sensing and control apparatus, also may play a role in communication between instruments and PDAs. Watch for ZigBee—still in its infancy—to blend the power and flexibility of a Wi-Fi network with the ease of use and flexibility of Bluetooth devices.

Many other options

Although PDAs provide easy access to wireless communications, instruments may not. Several vendors, however, offer wireless communication devices that connect to instruments through an Ethernet or USB port. In many cases, an instrument will simply "think" communications take place through a standard hardwired device. (Instrument must provide the necessary communication-port drivers.)

Software requirements extend to a PDA, too. It requires application software to monitor and process test results and to control the test apparatus. If you have a test application that runs on a PC, don't expect to drop its code into your PDA. PDAs require code specified to their processor, operating system (OS), and system resources. So you can't even cross-compile working C/C++ code and download it into your PDA.

If you already use a test development package, included tools may simplify the task of porting an application to a PDA. Software tools in LabVIEW, for example, eliminate the need to master the application programming interface (API) or OS for a specific PDA. A LabVIEW application that runs on a PC will smoothly compile and run on a variety of PDAs. Granted, developers may need to adjust their user interface. They can't get everything shown on a PC's monitor onto a small PDA screen, and they might substitute pull-down menus for dialog boxes that expect a typed-in response. Providing the capability to transfer a working test application into a PDA lets developers concentrate on their application.

If you do want to roll your own PDA application, several vendors offer PDA-specific tools such as C/C++ compilers, simulators, and emulators. And, if you don't like C/C++, tools provide compilers and interpreters for Basic, Pascal, LISP, Forth, and other languages. A variety of books at Amazon.com exist solely to teach PDA programming skills. But you're reading this column in a design magazine. Undoubtedly you'd want to solve a testing problem rather than become a PDA programming whiz. So, go for the test development tools that make the transition to a PDA part of the solution—in lieu of part of the problem.