Testing electronics products, such as cellular phones, has become more and more complex, often requiring longer test times and sophisticated test equipment. Simultaneously, cellular-phone manufacturers are being pressured to shorten design cycles, reduce production time, and cut costs.
Test engineers feel this pressure as much, or even more so, than engineers in other areas of a company. Consequently, they continually search for new ways to reduce test costs, such as by decreasing per-unit test times and equipment expenses. One method to reduce costs and meet time-to-market requirements is to test several products simultaneously on a single system, employing bus-sharing technology since it lets you use computers and test equipment more efficiently.
With today’s computers and operating systems, multiple applications are commonplace. For instance, we can download from the network, calculate a spreadsheet, send messages, and run these applications at the same time. But presently, this is not the case with most automated test systems.
Test systems usually manage multiple tasks, such as transferring data to the network while waiting for an instrument to respond to a command. However, very few test systems control multiple sets of equipment concurrently from one computer. When test-engineering teams investigated multiple-up testing of electronic equipment in the past, they often could not justify spending the time and money to develop the needed solutions.
Manufacturers of cellular phones have at least two potential situations where it is advantageous for a single multitasking computer to run multiple sets of test equipment:
When a unit is to undergo different, unique tests at several process or assembly stages (Figure 1).
When multiple sets of identical test equipment are to be used to satisfy high-volume demands or to mitigate long test times (Figure 2).
Increasing Computer and IEEE 488 Bus Utilization
When IEEE 488 was invented, circa 1975, only one instrument could use the bus at a time. Bus-sharing and multitasking techniques were not demanded because there was a low penetration of automation in most manufacturing operations. IEEE 488 bandwidth was not a limitation in 1975. Even with today’s PCs and modern instrumentation, IEEE 488 bandwidth is still underutilized.
IEEE 488 has a bandwidth of 500 kB/s without any special considerations. Instruments rarely talk or listen at more than 250 kB/s, although some specialized instruments can dump data at high rates for small bursts of time.
The wait time or gaps between instrument transactions are significantly longer than the time to send the data. Most of the test time is spent waiting for the instrument or a test set to respond and send data. This dead time or extra time could be used to communicate with another instrument.
When we use today’s computers to control a single set of test equipment, the computer has plenty of operating cycles to spare. The PC’s I/O also is not a limitation since it is spending most of its time waiting for instruments to acknowledge instructions or send back measurements. So, PCs in test systems today have the performance capability to easily run multiple applications and share instrument I/O.
Multiple-Up Tester Architecture
Typical instrumentation used for automated testing of cellular phones includes an RF test set to make all radio protocol measurements, digital I/O for fixture control, RS-232 communications facilities, and a power supply for emulating the battery. Equipment also is needed to make audio measurements of the microphone circuits and speaker.
Tests performed on the phone include battery tests, phone communications, check/calibrate transmit power, output RF spectrum measurements, bit error ratio, phase frequency errors, and audio tests. These tests are controlled by the PC and software in a sequence that compares results to test limits. The RF test set and power supply to the phone are used most of the time, while other instruments may not be fully used.
Normally, while the RF test set is making measurements, the bus is idle; for example, while waiting for the RF test set to send back a measurement. But by making it possible to use the idle or dead periods for communicating with other instruments, multiple-up implementations can be realized.
Concurrent Driver Technology
Recovering the dead or unused time requires an in-depth understanding of how IEEE 488 bus, I/O software (VXIplug&play drivers and VISA), and instruments work. With this knowledge, standard programming techniques can be used for effectively sharing the IEEE 488 bus among different applications.
Typically, in an IEEE 488 interconnected test system, the controlling program initiates the measurement, addresses an instrument to talk, and waits for data. Originally, the IEEE 488 standard restricted transactions so that no two instruments could use the IEEE 488 bus at once. As a result, no other process could use the bus until the measurement and data transfer were complete.
However, such a restriction prevents bus sharing. Therefore, it is essential to identify any bus transactions that could block other processes from using the IEEE 488 bus while not transferring data and to employ a software routine that circumvents blocking.
Preventing a program from monopolizing the IEEE 488 is relatively complex, so the required programming steps are best isolated within a single software routine. Any part of the main program that needs this capability then can simply call for and invoke this routine.
The coding task for the routine is greatly simplified for instruments that are implemented in accordance with the IEEE 488.2 Standard and respond to Standard Commands for Programmable Instruments (SCPI) commands. These instruments must include a bit in the status byte, called MAV, which is set when the instrument has a message available for transmission. All IEEE 488.2-compliant instruments also understand the command *SRE 16, which can cause the instrument to request service when MAV becomes true.
Instruments using SCPI can easily be triggered to start a measurement sequence and can be programmed to request service when the result from a measurement becomes available. To let other programs have access to the CPU and IEEE 488 bus, this software routine sleeps until the instrument flags a service request. The sleep mode of the routine uses a time-out, so the bus is not held up indefinitely if something goes wrong.
Since running multiple processes requires accessing multiple instruments, you cannot be certain which instrument caused initiation of a service request. So before reading any measurement result, a serial poll is performed and the request service (RQS) bit is checked.
If RQS is not true in a polled instrument, then a different instrument requested the service. In that case, the routine should go back to sleep and wait for another service request.
If a conflict occurs among instruments and an error is detected, the routine puts the instrument into a known state. For example, sending a device clear command to an IEEE 488.2 instrument resets its command parser so it is ready to accept a new command. Second, the SCPI command TRIG:ABORT can stop any measurement in progress. Finally, disabling service request is accomplished using the standard IEEE 488.2 command.
Two other aspects involving potential conflicts or complexity must be considered. First, some instruments have small input data buffers for commands. These instruments may accept a few bytes of data very rapidly, but then hold off bus data transfer until the received commands are parsed and executed.
To circumvent this problem, the bus-sharing program should recognize the message to be sent as being larger than the input buffer, send just enough bytes to fill the buffer, and then go to sleep so other processes can use the CPU. When the instrument’s input buffer is empty, the routine should continue to send the next bytes of data. This procedure should be repeated until the entire message is sent.
Second, certain commands, such as spectrum analysis measurements, may take a significant amount of time to execute. If the instrument is unable to accept data from the IEEE 488 bus while executing these commands, then the routine should sleep for however long the command takes to finish. The routine should send additional commands to the instrument only when the measurement is complete.
Conclusions
Many manufacturers of high-volume products, such as cellular phones, are looking for ways to reduce their costs and fully utilize their test equipment. An operational cellular-phone test platform demonstrates how multiple test instruments and a multiple-up operator interface can run simultaneously and asynchronously on one computer. In specific case studies, this multiple-up testing platform has shown savings in capital costs of up to 35% by reducing equipment and system integration, plus providing faster test times.
About the Authors
Stephen Greer is an R&D engineer at the HP Measurement Systems Division and the company’s representative on IEEE and IEC standards committees. The 20+ year HP employee graduated from Lehigh University with a B.S.E.E. degree and from Georgia Tech with an M.S.E.E. degree.
Chris DeSalvo, who has been with HP for more than 20 years, is the marketing programs manager at the company’s Measurement Systems Division. He received a B.S.E.E. degree from the University of Pittsburgh and has taken graduate-level classes in marketing and management.
Hewlett-Packard, Measurement Systems Division, 815 14th St. S.W., Loveland, CO, 80537, (800) 452-4844.
Copyright 1998 Nelson Publishing Inc.
March 1998