Low-volume handheld designs: not for the faint of heart
Designers of handheld devices confront more technological issues than do designers of many products a thousand times the size. When the devices are specialized and the expected unit volumes and revenues are modest, the design challenges get even tougher.
By Dan Strassberg, Contributing Technical Editor -- EDN, June 22, 2006
| AT A GLANCE |
| Designing handheld devices for specialized applications requires engineers who are comfortable wearing many hats.FPGAs can be good choices even for handheld devices that are made in small quantities. Other good choices include low-power microprocessors and microcontrollers with onboard flash RAM.The choice of a power philosophy is an important part of handheld-device design. Designers need to think through such issues as where batteries should be charged and how to package them. |
Not every handheld electronic device is a cell phone, a PDA, or even a DMM (digital multimeter). Such devices are made in quantities of 100,000 to tens of millions. Many handheld devices for inventory control, medicine, environmental monitoring, pollution control, and a host of other 21st-century applications will be lucky to yield orders for a few thousand pieces over their product lifetimes. On the other hand, customers for these units are often willing to pay far more than the $499 price of a top-of-the-line PDA that includes wireless capabilities.
From hardware, software, and mechanical standpoints, designing specialized, low-volume handheld devices often differs significantly from designing high-volume consumer units. This article examines differences and similarities in the way that engineers perform the design jobs and some of the products that enable engineers to create low-volume handhelds that can make a profit for the companies that sell them.
Designers of handheld devices—regardless of the sales volume—must constantly keep in mind interactions among such elements as the display; user-input hardware, such as touchscreens, buttons, or keyboards; user-interface software; processing elements, such as microprocessors, microcontrollers, or FPGAs; battery and power subsystems, including battery chargers and ac-line-operated supplies; analog or mixed-signal components; and molded-plastic parts. They must also think about component power dissipation and thermal sensitivity and consider such issues as usability; battery life; component cost; assembly-and-test cost; size; weight; and ability to withstand extremes of ambient temperature, humidity, shock, and vibration (see sidebar"Designing a user interface for a PDA application"). Designers of high-volume products work under intense time pressure because the product-life cycles are so short, but at least the design teams are fairly large, allowing team members to focus on their specialties.
Developers of low-volume devices—units manufactured in annual quantities of 10,000 or fewer pieces and perhaps 30,000 pieces over three years as actively marketed products—may have more time to execute their designs, but few, if any, have the luxury of working in narrowly specialized technical areas. Lower unit volumes mean lower revenue, which means smaller product teams in which each member must wear several hats. If you are temperamentally suited to the challenge, working in a small team on problems with which you have only limited experience can be enormously challenging and fun. On the other hand, for those who can't roll with the punches and improvise practical solutions to unfamiliar problems, the experience can be a living hell. Even worse, finding out on the job that you weren't cut out for this type of work can prove seriously unsettling.
Will a standard PDA work?
Although most handheld-development projects present moderate to high technological risk, one variety of low-volume handheld-product development presents low risk: standard PDAs bundled with application software that enables them to perform well-defined functions in relatively narrow market niches. Probably the most important activity related to developing such products is selecting the PDA. The chosen unit must support an appropriate software-development environment; the application designers must be able to equip the unit with adequate hardware resources, such as memory; and the PDA manufacturer must provide credible assurance that the replacements for the current models will not obsolete the application-specific software that the developers plan to bundle with the unit.
If such a product must withstand moderately greater physical abuse than the off-the-shelf PDA on which it is based, the vendor of the application-specific version may supply the unit enshrouded in a sleeve that augments the shock-and-vibration protection inherent in the unit's own case. Sleeves for many popular PDAs are available from dozens of vendors—usually at list prices of approximately $30 each (Reference 1). Slightly less than $100 buys a more rugged case, the Otterbox 1900, whose vendor claims that a PDA mounted in its product will float if you drop it into a swimming pool and will function unimpaired when you retrieve it (picture). Otterbox supplies a range of accessories that enable PDAs mounted in its cases to perform functions you don't usually associate with off-the-shelf PDAs. The accessories include a windowed enclosure for a bar-code scanner, a GPS (global-positioning-system) pod, and a waterproof pod for cable exit and entry.
Using a ruggedized handheld-computing platform, such as Juniper Systems Allegro, is a more flexible—and more expensive—approach than sleeving or encasing a standard PDA (Figure 1). Although basing your design on an existing platform, such as the Allegro, shields you from some of the vicissitudes of starting your new-product project with a clean sheet of paper, the approach can transport you from the arena of minor development programs to the world of significant projects. Moreover, if you need hardware capabilities that you can't get from the platform supplier or a third party, you may have to develop them—or even the entire platform—yourself. This approach can represent a major commitment for a device whose estimated total unit volume is 30,000 or fewer pieces.
FPGAs: right for some
For products that you do not base on PDAs or handheld platforms, the chances are improving of your building your design around one or more FPGAs instead of—or in addition to—a standard microprocessor or microcontroller. FPGA suppliers say that FPGA-based designs for products manufactured in quantities of a few thousand units per year can make economic sense. Despite their enthusiasm, these companies recognize that not every design start culminates in a product that goes into production and that some products that reach production fail to achieve success in the marketplace. For the FPGA companies, the name of the game is having their ICs designed into enough big winners to make a respectable profit despite the expenses associated with programs that fail to meet customer expectations. Moreover, projects that themselves don't succeed can still lead to relationships between FPGA companies and customers that give rise to follow-on projects that yield big profits. Like the handheld business, the FPGA business is not for the faint of heart, but companies of both kinds often get more than one chance for success.
If the idea of using FPGAs in battery-powered products seems inconsistent with the ICs' reputation for high speed at the cost of high power dissipation, you need to look closely at FPGA manufacturers' newest product offerings and application literature. You have every reason to wonder whether many handheld-system applications need FPGAs' speed. Although it may appear that using FPGAs in handhelds requires paying for speed that you can't use, FPGA manufacturers insist that, even when you ignore their great speed, FPGAs can often be cost-effective in handhelds. As for power dissipation, however, all FPGA manufacturers offer devices whose power requirements are supposed to be appropriate for battery-powered handheld applications—although several manufacturers seem skeptical of their competitors' low-power-consumption claims.
Actel is particularly proud of its flash-based FPGA technology, boasting a long list of attributes that the company claims SRAM-based parts from its larger competitors, Altera and Xilinx, can't duplicate. In one area, though—feature sizes—the SRAM-based parts appear to have a decided advantage. The latest generation of SRAM-based FPGAs have 90-nm features, whereas flash-based parts' feature size is 130 nm. SRAM-based chips thus occupy half the silicon area of flash-based chips of equivalent complexity. According to Actel, however, that simple statement is misleading. Actel says its flash-based architecture is more efficient than that of competitive SRAM-based parts, so if you were to build functionally equivalent devices using the two technologies, the flash-based part would be less complex and, thus, notwithstanding the larger feature size, would occupy considerably less than twice the area of the SRAM-based part.
Other Actel claims include the ability to build mixed-signal FPGAs into its new Fusion series; elimination of the need for a separate device—typically, a flash RAM—to store the configuration data that loads into the FPGA at power-up; no delay for the configuration data to load after power-up; almost complete immunity to brownout, in which momentarily reduced supply voltage can require reloading the FPGA's configuration data; and greater immunity to "upset," which can allow such phenomena as cosmic rays to alter an FPGA's configuration.
All FPGA suppliers offer ranges of soft microprocessor and microcontroller cores, which you can embed within FPGAs. Soft-core architectures and capabilities vary among the suppliers. Depending on the complexity of your system requirements and the capabilities of your FPGA supplier's cores, soft cores may enable you to avoid using additional processor elements. Still, designers often use soft cores not as replacements for conventional processors, but rather to facilitate implementing such functions as state machines, whose synthesis with conventional logic can be cumbersome. If soft cores can't meet all of your processing requirements, you need to investigate embedding a hard core in your FPGA or using a separate microprocessor or microcontroller chip. Although the list of suppliers of suitable processors is long, Texas Instruments points out that its low-power ARM microprocessors and microcontrollers that incorporate flash RAM are ideal for handhelds (Figure 2).
Regardless of whether you are using a separately packaged microprocessor or microcontroller, an equivalent hard core, or one or more soft cores, you will generally have to select an operating system. Nevertheless, some intrepid designers—especially in the realm of FPGA-based designs—continue to use high-level languages, such as C, to code functions that you would normally think of as part of an OS. One key rationale for this approach is a sufficiently high level of programming expertise within the project team. Another is the ability of skilled programmers to tailor code to a project's exact requirements, thus minimizing memory requirements and thereby enabling reduced chip dimensions.
Handheld-device designers can choose among many dozens of operating systems. If you include OSs whose vendors classify their products as embedded OSs, so many choices exist that having an open mind can prove counterproductive. Objective study and comparison of OS capabilities, advantages, and disadvantages can consume more time than management generally allows developers. Fortunately, most companies have investments in tools for one OS or another, and experienced developers have personal investments in learning to use particular OSs and tool sets. Hence, most development teams escape lengthy investigations. Usually, low-volume applications don't attract many competitors, so, even if the project team's OS or tool- set choices aren't the best, there is low probability of the team's or the customers' finding out. There will be no competitors who might say, "Look what my device can do that theirs can't." Unless the choices are really wide of the mark, customers will likely find the product's capabilities, cost, and performance acceptable.
The best known OSs for handheld devices come from PalmSource Inc and Microsoft. Microsoft's continually evolving handheld-product names may constitute a subtle test of whether prospective users are intelligent enough to adapt to the company's products. The current Microsoft OS for handhelds seems to be Windows Mobile 5.0, which is a descendent of Windows CE 5.0, in which the company insists the letters CE stand for nothing. Operating systems that publishers identify as "handheld" enable developers to customize specialized handheld units' user interfaces. However, the further the application developers stray from the OS designers' idea of the device "personality," the more likely users are to experience usability problems.
Power is a big deal
Batteries are major factors in the design of handheld devices. The device designers must first decide upon a power philosophy. The main choice is whether to use rechargeable batteries. Then, if the batteries are to be rechargeable, will they require recharging while still within the handheld unit? Will they permit recharging outside the handheld unit, enabling users to quickly swap spent batteries for freshly charged ones? Or will they require recharging outside the handheld unit? Common alkaline cells, which you normally think of as nonrechargeable, became available a few years ago in versions that you could recharge a limited number of times in an appropriate charger. However, a Web search for such batteries revealed only one company, PureEnergy Battery, that supplies rechargeable versions of standard-sized alkaline cells and chargers for the rechargeable cells. Most suppliers have apparently returned to older technologies, such as NiMH (nickel metal hydride), as the basis for rechargeable cells that can replace standard-sized alkaline cells. Although some rechargeable-alkaline technologies, such as that of Zinc Matrix Power Inc, appear to offer great promise, they haven't yet yielded commercial replacements for standard-sized alkaline cells.
A handheld unit's power philosophy has serious implications for the product's usability. Suppose, for example, that the unit can operate for only eight hours before you must recharge its batteries and suppose that the batteries must be inside the unit to be charged. Unless the batteries can quickly recharge—not yet a common feature of batteries for handheld units—the unit is likely to prove unsatisfactory in applications that require it to be available over the course of two successive shifts.
Battery packs have become commonplace in many products—especially laptop PCs—although a laptop battery pack would be both too large and too heavy for a typical handheld. Nevertheless, a battery similar in concept to a laptop battery pack but that is smaller and lighter—and consequently stores less energy—has great initial appeal for handhelds. After a little reflection, however, it becomes evident that this approach has several drawbacks.
|
One of the good features of a laptop battery pack is that it lets you rapidly swap it out—often rapidly enough that, thanks to energy stored in an ultracapacitor, the laptop can keep running while you swap battery packs, even with the laptop's hard drive spinning. Also, you can recharge the battery pack either in a separate ac-powered charger or while the pack is within a laptop that plugs into the ac line.
For a handheld—particularly one made in small quantities—the disadvantages of a smaller version of a laptop-style battery pack are tooling costs, which can be in the neighborhood of $40,000 for the molded-plastic parts, and problems with availability of replacement packs after the handheld device is no longer in production. In addition, keeping the handheld plugged into the ac line to recharge the batteries is a nonstarter. Unlike laptop users, handheld-system users aren't mainly sitting at desks. Batteries for handhelds require separate chargers.
Use standard-sized cells
All battery packs consist of cylindrical cells or slightly more space-efficient prismatic cells. According to Robin Sarah Tichy, PhD, product-marketing engineer at Micro Power Electronics, two of these cells are popular enough to be called industry standards. One is the 18650 cylindrical cell, which measures 18.3×65 mm (Figure 3). Lithium-ion versions of these packs have terminal voltages of 3.6 or 3.7V, store 2.4 Ahr, and provide capacity that may in the future reach 3 Ahr. The other, the 103450 prismatic cell, measures 10×34×50 mm; offers the same voltage as the cylindrical cells; and now has 2-Ahr capacity, possibly increasing to 2.5 Ahr at some future point. Both sizes are available for less than $10 each in small quantities. In Tichy's view, designers of low-volume handhelds should choose one of these two sizes to guarantee ongoing availability of batteries for their products.
There may be no need for specially molded parts, however. Some manufacturers have begun to offer shrink-wrapped groups of cylindrical or prismatic cells connected in various series, parallel, and series-parallel configurations. Tooling costs are minimal, and you can swap the shrink-wrapped packs just as rapidly as you can swap packs in molded enclosures.
| Reference |
|
|
Designing a user interface for a PDA application By Mike Neal, National Instruments  As wireless technologies, such as Wi-Fi and Bluetooth, continue to proliferate and consumer products running the Windows Mobile or Palm operating systems become more common, engineers and scientists will use these technologies to create applications that solve real-world problems. Mobile devices offer a remarkable amount of computing power in a small, portable package. Through the use of programmable software, such as National Instruments’ LabView, you can use portable devices to create custom application packages that acquire, analyze, present, record, and wirelessly transmit data.However, mobile devices, such as PDAs, are not without limitations. One obvious constraint on PDA applications is the relatively modest amount of real estate available on a typical PDA screen. Most consumer PDA screens are only slightly larger than a credit card. As a result, it is essential to simplify the UI (user interface) as much as possible to ensure UI readability without sacrificing capability. You can use the following features to create well-organized, straightforward UIs: Menus: You can simplify the UI layout by creating custom menus that appear at runtime. Menus can organize and group operations yet can still make the functions easily available. For example, in a data-acquisition application that contains a graph, menu items could include the options Menu for general operations, such as acquiring data; Zoom for controlling the graph; and Help. Tab controls: When you use several front-panel objects together or during a phase of operation, tab controls can help to simplify the application. For example, a program with tab controls may require the user to first configure several settings before a test can start, and the user can then modify aspects of the test as it progresses. Finally, the user can display and store only pertinent data. Each tab can contain a related group of controls and the user simply navigates among the tabs to perform tasks. Decorations: When creating UIs that have too few controls or indicators to warrant use of a tab control, engineers can use decorations such as boxes, lines, or arrows to group or separate objects on a front panel. Default text: For most handheld devices, the input device is usually a pen or a stylus, which slows text input on a PDA. If possible, you should implement default values for controls to reduce the amount of text the user must enter. Author’s biography Michael Neal is a LabView product manager at National Instruments (Austin, TX). His current projects include the LabView PDA module and the localized editions of LabView. He received a degree in biomedical engineering from the University of Texas—Austin and joined NI in January 2003 as an applications engineer. |
For More Information
| Actel www.actel.com | Altera www.altera.com | ARM www.arm.com |
| Juniper Systems www.junipersys.com/ | Micro Power Electronics www.micro-power.com | Microsoft www.microsoft.com |
| National Instruments www.ni.com | Otterbox www.otterbox.com | PalmSource Inc www.palmsource.com |
| PureEnergy Battery Corp www.pureenergybattery.com | QuickLogic www.quicklogic.com | Texas Instruments www.ti.com |
| Xilinx www.xilinx.com | Zinc Matrix Power Inc www.zmp.com |
-
Giayee-Embedded handheld device design
Embedded Linux/WinCE based Hardware & Software Development, from the PCB development to device Manufacture. Professional with over 7 years development experience from China.( www.giayee.com )
Sun Sijia - 2009-3-3 18:37:00 PST -
Dan,
Thank you for your article on low-volume handheld designs. You covered a number of issues that are specific concerns for those types of devices and markets. One critical concern that I have encountered, which is important for low-volume medical or military devices, is that of component obsolescence. If a device is going to be on the market for more than 3 years, possibly as long as 10 years, larger subsystems may have to be custom designed rather than purchased commercial-off-the-shelf (COTS). This is true for devices that use a either a pentop computer or a PDA for its platform; pentop computers and PDAs have very short life cycles, just as you described. If a low-volume medical (or military) device uses a COTS platform, such as a pentop computer or PDA, then either you have to buy sufficient quantity of units up front and store them in inventory over the life cycle or get a contractual agreement from the vendor to stock them for you. Of course either of these options will cost your company more than buying COTS parts that do not account for obsolete parts or inventory.
Part of the problem for low-volume medical devices is that they must get FDA approval before they can sell. FDA approval does not allow for changes in the product once approved. If a COTS vendor changes a major subsystem that your company purchases for its medical product, you could be prevented from continued sales with a new vendor-supplied subsystem in the product.
The same might be true for military devices. I am sure that designers and their companies need to consider component obsolescence and inventory when contracting to build low-volume military devices that will last a long time.
My experience indicates that even with the added cost a custom design may not be far fetched after all, particularly for the platform. A custom design allows you to get exactly the form factor and user interface that you want for the platform; it also allows you to uniquely brand the enclosure for your product. Finally, custom design does not fall prey to vendor enforced obsolescence quite as easily as COTS.
Kim Fowler - 2006-29-6 12:59:00 PDT
