----设计一个连接到消费电子产品的短距无线(RF)设备
While the design team never expected it to be easy, when we initially thought about developing a short-range, two-way RF (radio frequency) link for an iPod controller and dock, those infamous words of design denial—"How hard can it be?"—did cross our minds.
Twenty-four months later, the Tuneview 2.4-GHz two-way RF iPod Dock and Remote hit the market. The Tuneview product features a 1.5-in. color LCD that enables iPod-like menu navigation with features such as "Playlists" and "Artists," and a realistic >50m operating range. We quickly followed the iPod version with a product that allows control of iTunes on a Mac or PC via the same remote control and a USB-connected RF transceiver. The design team is justifiably proud of the results.
Unfortunately, that pride is tempered by the fact that the products were a year late to market.
Why? When the team started the project, it had only limited RF experience. What's more, we decided not to use a proprietary RF module, commercial software, or IP (intellectual property), choosing instead to design everything from scratch, including the communication protocol, learning as we went. We found out that RF is a complex and difficult field because it is profoundly analog in nature. If your expertise, like ours, is in digital hardware and software, analog engineering is a huge challenge.
For example, the Tuneview project dictated that we successfully integrate three separate analog subsystems (radio, power amplifier, and antenna). The passive components (capacitors, resistors, and inductors) used to connect these subsystems behave entirely differently at microwave frequencies (for example, 2.4 GHz), and the parasitic effects become highly significant. Layout imposes a completely new set of requirements, and when it doesn't work, it is very complicated to figure out why. We learned our lessons the hard way.
Even the choice of RF technology is not straightforward. Technologies such as Wi-Fi, Bluetooth, and ZigBee spring to mind, but in our case we ruled out each because of a combination of problems concerning range, functionality, power consumption, latency, or interference immunity. After rejecting these alternatives, we looked at some proprietary 2.4-GHz solutions and found one that met our specification.
When the product hit the market and we had time to review the project, we realized that our experiences were applicable to any designer adding short-range wireless connectivity to a portable consumer product or peripheral. The result of our analysis was a decision to share those experiences in this article.
The advantages of RF remote control
The development team at Keyspan had been considering dramatically improving the traditional one-way remote control by providing direct feedback via the controller itself so users would know what they were doing at any time. Our instincts were confirmed when an end user approached me at a MacWorld trade show. "I like your remote controls," he said, "but what I really want is the prototype you're working on in the back—the one with an LCD screen on the remote that allows you to see your song list right there in your palm."
The target applications for the remote control were control of a PC- or Mac-based music player (for example, Apple's iTunes) and control of a dock-mounted MP3 player (for example, the same company's iPod). We wanted to avoid the typically large form factor of high-end remote controllers, instead favoring a compact, thumb-operated controller that had good performance in low ambient light. We quickly dismissed any thought of streaming audio or video to the device itself—that would have been far too expensive. Finally, we wanted a product that could be certified for use anywhere in the world. The concept was dubbed Tuneview, and the project started in earnest in December 2004.
Although we were convinced that an RF bidirectional remote controller was the product we wanted, designing it was another matter. Working with RF was a big departure from Keyspan's expertise. Up to 2004, the company's engineers had been developing USB adapters, smart cables, simple IR remote controls, and a line of network appliance USB servers. We had broad expertise in embedded systems, time-sensitive communications, and cost-sensitive design for manufacturing. What we didn't have was experience designing with RF; and we had only limited experience with handheld devices.
However, while the RF development looked daunting, we observed that most modern digital radios came in single packages with a straightforward digital CMOS interface on one side and an antenna on the other. Our first thought was "how hard can this be?" And we were motivated by the experience we'd gain with handheld RF devices, especially one incorporating an LCD.
A senior hardware engineer took a pragmatic stance and suggested we engage the services of a consultant to compensate for our lack of expertise. However, it proved virtually impossible to find a consultant who was willing to help with the basic design. Eventually we did locate an RF consultant with his own lab who, while being unable to do the RF design, was able to test and provide important feedback on our design iterations.
Selecting a radio
In conjunction with the marketing department, the design team mapped out the following spec for the Tuneview radio:
Less than $5 component costs;
Operation in the 2.4-GHz ISM (industrial, scientific and medical) band (allowing virtually global operation);
DSSS (direct sequence spread spectrum) or FHSS (frequency hopping spread spectrum), as required by the ITU (International Telecommunications Union) to provide immunity from Wi-Fi, Bluetooth, and other Tuneview units' interference;
30 to 50m range through walls, under realistic operating conditions;
Battery life of at least three months (and preferably six months) from standard AA;
100- to 300-kbps effective data rate;
Fast turn-on time (from deep sleep mode);
User intuitive remote control-to-base station pairing scheme.
We drew up a short list of the following standards-based and proprietary short-range, low-power wireless technologies:
ZigBee: Touted by the ZigBee alliance as "Wireless Control That Simply Works" and based on the IEEE 802.15.4 standard, ZigBee is designed for low-data-rate and low-power-consumption applications.
Bluetooth: Bluetooth is also based on an IEEE standard, this time IEEE 802.15.1. Bluetooth operates in the 2.4-GHz band and has seen good success in the cell phone and PC sectors. Diversification efforts by the Bluetooth SIG (Special Interest Group) have seen adoption in peripherals such as wireless headsets.
Wi-Fi: Wi-Fi is a third wireless technology based on an IEEE standard, IEEE 802.11. It is ubiquitous as a wireless-LAN technology powering thousands of networked "hotspots," homes, and offices. Wi-Fi is primarily used as a transport layer for TCP/IP networking.
Cypress WirelessUSB: Cypress' proprietary product—no relation to the so-called "Certified Wireless USB" of the Wireless USB Promoter Group based on the WiMedia Alliance's UWB ultrawideband common radio platform—is a proprietary, half-duplex 2.4-GHz radio. It uses a DSSS scheme to meet ITU requirements and to improve interference immunity in the presence of other 2.4-GHz radios.
Nordic Semiconductor nRF2401: Nordic's radio is a proprietary, wireless half-duplex modem operating in the 2.4-GHz band. It uses an FHSS scheme and a digital subsection that accepts bit streams in 256-bit packet formats. The receiver discards corrupted packets.
While the final selection of a wireless technology for Tuneview wasn't a trivial process, some were eliminated quickly, starting with ZigBee because it was, at the time, an unratified and unproven technology. Nevertheless, even if the project was starting now, we wouldn't have selected ZigBee.
At first, Bluetooth's ubiquity in PCs and Macs appeared to be a big advantage. Unfortunately, closer inspection revealed that virtually all computers are equipped with the lower-power Class 2 or Class 3 Bluetooth, with ranges of less than 10m. The more expensive and power-hungry Bluetooth Class 1 was required for Bluetooth to meet the 30 to 50m range demanded by our specification. Explaining to users that they needed to buy a Bluetooth dongle because the one built in to their computer wasn't good enough was not a palatable prospect. Moreover, Bluetooth Class 1 (which operates at 20 dBm) consumed more power than the AA cells could supply with any reasonable battery life, besides adding unacceptable cost. In addition, user pairing with Bluetooth using a PC or Mac wasn't very user-friendly.
While improvements in battery technology have seen Wi-Fi increasingly adopted on portable devices like PDAs and cell phones (primarily for Web surfing and emailing when near a Wi-Fi "hotspot", Wi-Fi's power consumption drains batteries quickly (particularly low-capacity AA cells). With Wi-Fi it would be impossible to meet the three- to six-month battery life called for in our specification. Secondly, the design team expressed concern about Wi-Fi's wake-up time from sleep mode, although this wasn't specifically tested. Finally, there were doubts about whether Wi-Fi chip vendors would be willing to supply a relatively small company like ours. Without a reliable chip supply, the company would have to source an expensive and bulky module instead.
In addition to the technical mismatches listed here, all the standards-based technologies proved to be poor fits for Tuneview's requirements. Standards-based technologies are a great idea when interoperability between devices from different manufacturers is required, especially if several are simultaneously communicating in a PAN (personal area network). However, ensuring the interoperability and PAN functionality leads to compromises, which manifest themselves in complex protocols that eat into the power budget and lower efficiency.
In contrast, Tuneview needed a simple, point-to-point, error-correcting protocol and that could be optimized for the specific traffic patterns and power-usage requirements of the application. The remote controller didn't need to interoperate with products from other manufacturers, as Keyspan would supply both ends of the link. Using a standards-based technology would incorporate unwanted functionality and complexity, requiring significant workarounds and adding cost. Furthermore, an expensive processor would be needed to run the baseband controller.
Overall, the prospect of using proprietary RF hardware and developing a customized, application-specific protocol proved particularly enticing. Communications protocols were something the Keyspan team had been designing for decades.
The first proprietary RF technology we tested was Cypress' WirelessUSB. The development team's initial efforts were hampered by the lack of a suitable development board, so they designed and built a USB radio dongle. Unfortunately, the effective data rate fell far short of the 62.5 kbps advertised, so the technology was abandoned. (Since then, Cypress has released higher-bandwidth chips in this family.)
After preliminary testing, we finally selected Nordic Semiconductor's nRF2401A as the proprietary technology on which we based Tuneview's RF link. According to the specs, the nRF2401A was a GFSK (gaussian frequency shift keying) single-chip transceiver with a maximum date rate of 1 Mbps. It comprised a fully integrated frequency synthesizer, a power amplifier, a crystal oscillator, and a modulator.
Output power and frequency channels are programmable by use of a three-wire serial interface. Current consumption is low at 10.5 mA at a transmission (TX) power of –5 dBm and 18 mA in receive (RX) mode from a 1.9 to 3.6 V power supply. The transceiver utilizes a proprietary ShockBurst feature in both receive and transmit modes to simplify protocol and software design, minimize power consumption, and relax microcontroller requirements.
The Nordic part exhibits a good balance among cost, receiver sensitivity, data rate, power-on time, and power consumption. In addition to the promising specs, the device met the development team's cost expectations. Moreover, since the developers were able to create their own communication protocol and could implement the baseband controller in firmware, they were able to maximize the radio's advantages while minimizing its disadvantages. For example, one disadvantage of the Nordic part was that after clocking the packet data into its buffer and transmitting, the transceiver didn't provide any way to let the processor know when the operation was complete. The design team overcame this problem by carefully fine-tuning a delay timer in firmware.
While the choice of technology is perhaps the most important decision, don't underestimate the importance of selecting the right vendor. Any RF project is going to be complex, and the more the vendor can help, the better. For example, we found the technical support from Nordic Semiconductor to be very good—this is very important when designing an RF link with minimal experience—particularly compared with experiences with some other vendors. For example, both Nordic Semiconductor's field-support engineers and specialists from the factory reviewed the layout. While the engineers were not able to validate the layout specifically, they made suggestions and understood the importance of a good design and strongly supported our plan to engage an RF lab to make specific network-analysis measurements to help match the impedance of the components.
Testing times
Although we had identified a suitable technology, a helpful consultant and a technically competent vendor, our challenge was only just beginning. One of the first lessons we learned as digital experts doing high-frequency analog RF design for the first time, was that getting all the circuit components in the right place and connected is only the first step. When operating at 2.4 GHz, traces on a PCB are not just connections between components; they are effectively transmission lines.
In the early stages, when the engineers put together circuits, they found that they would work, but not very well. Range would be just a few meters and signal quality so bad that the BER (bit error rate) was atrocious. We learned three important lessons: At 2.4GHz, every component attached to another had to be impedance-matched with its neighbor; second, every passive component (capacitor, inductor, resistor, or PCB trace) caused parasitic effects and acted simultaneously like a capacitor plus an inductor plus a resistor, and third, the physical orientation of the components was important because it affected to the parasitic effects.
This is where the RF consultant and his lab proved very useful. He had the equipment needed to measure the characteristic impedance of every part of the circuit and help establish the required component values for the appropriate "matching network." One key item of instrumentation was a Spectrum Analyzer ().
This device measures both radiated and conducted RF energy, not only at the fundamental 2.4-GHz frequency but also at all of the important harmonics where the energy must be minimized for regulatory purposes. Another useful item of instrumentation is a Network Analyzer that can "look" into a part of the circuit along the appropriate transmission line and measure its characteristic impedance.
When it came to the details of matching the impedance of RF components, the chip vendors, (including Nordic) could only help so much. The companies would certainly know the characteristic impedance of their products, they might also have a sample network developed for a similar situation. However, we found this of little use in practice because component impedance matching needed to take into account everything in the surrounding circuit, including the PCB material, the exact location of the ground plane, and other, supposedly unrelated, components in the circuit. If you want your 2.4-GHz design to work well, schedule in plenty of project time for testing and subsequent impedance matching of the circuits. There are no short cuts.
Finding the range
Range was a key part of our specification. The team saw this as a key differentiator for the consumer. The team decided early that we wanted the specified range to be realized under realistic operating conditions. This is one case where the engineer's desire for real-world performance won over the marketing folks. They agreed that if we had good news about the range, which could be backed up in realistic tests, it would help the product.
The team started with development boards () that featured the nRF2401A radio allied to a whip antenna and produced a power output of 1 mW (at 0 dBm). Since we planned to use either a chip antenna or a trace antenna, which would have some insertion loss, we knew that the measured range with these development boards would have to exceed our 30 to 50m goal. Unfortunately, we were only able to get 20 to 25m at best. To boost the range, we needed to add a power amplifier. This complicated the circuit and exacerbated the impedance-matching challenge enormously.
Since the nRF2401A used a single RF I/O line, in addition to that used by the antenna, the connection between the radio, power amplifier, and antenna required two signal paths instead of one. We accomplished this using two RF T/R (transmit/receive) switches. The receive path fed the antenna signal directly into the radio, while the transmit path routed the signal through the power amplifier. Rather than having one matching network (nRF2401A to antenna), we now had four (
).
In wireless communications, whether analog or digital, signal quality is measured via SNR. For digital data this can also be thought of as the BER. It turns out that, at a given range, the SNR required to achieve certain "user responsiveness" is much higher for two-way, half-duplex communication than it is for one-way communication. One way to understand this is to consider that a one-way link can send multiple packets, assuming that at least one will get through uncorrupted. In contrast, with two-way communication, a packet is sent, the transmitter waits for either an acknowledgement or a time out, then retransmits or sends the next packet as appropriate. Both one-way and two-way communication will degrade as the SNR decreases, but two-way communication degrades more quickly.
Tuneview requires two-way communication because the remote control has an LCD for displaying data from the music source. Because we wanted the remote control to be well behaved at the limit of range, we needed a good strong signal with a high SNR. We achieved this by adding a power amplifier to the circuit to boost the signal and by working hard to get the best impedance match and clean layout of the components to reduce noise.
Eking out the power
Battery life is vitally important for a product such as Tuneview. While consumers appreciate some compromises in order to support a screen, they are used to IR remotes with battery lives of months if not years. We decided in our spec that Tuneview must run for at least three months from two AA cells.
Our choice of radio, Nordic's nRF2401A was influenced to a degree by its ultralow-power characteristics. Compared with standards-based solutions such as Bluetooth and even ZigBee, the nRF2401's power consumption when transmitting or receiving is much lower. (Specifications vary according to the vendor, but a typical Bluetooth chip runs at 35 to 45 mA when transmitting or receiving, a ZigBee chip runs at 25 to 30 mA and the nRF2401A runs at 11 to 18 mA, with all devices operating at 0 dBm.
In addition to the radio, the communication protocol has a big influence on the power consumption. If the radio spends long periods switched on in transmit or receive mode, the batteries will drain more quickly. The secret is to minimize the "on" time and quickly switch the radio to a low-power-consumption "sleep" mode as soon as possible.
The team designed the communication protocol so that the battery-powered unit, the remote controller itself, would normally have its transceiver in a low-power sleep mode, while the mains-powered base unit's receiver was always on (except when the radio was transmitting), waiting for a signal from the remote control. Communications are always instigated by the remote. The remote control's transmitter features a latency of about 200 µsec before it starts sending, so that when a user presses a button the transmitter starts up quickly, sends the signal, switches on the receiver, receives the acknowledgement from the base station, and goes back into a low-power sleep mode. We designed the protocol to minimize the duration of all the stages of this process, limiting the drain on the remote control's battery.
The remote controller has three states (operation, sleep, and deep sleep). In deep sleep the processor is powered off—at the cost of a 1.5-sec startup time. The remote controller has the following characteristics:
Transmit/receive operating current: ~73 mA;
Sleep current: ~330 µA;
Deep sleep current: 10 µA;
Remote goes into deep sleep after 90 minutes of sleep.
Typical operating conditions (assuming use of the remote control twice a day, more than 90 minutes apart):
10 minutes of transceiver activity (button presses) per day @ 73 mA is 12 mAhr
2 × 90 minutes sleep @ 330 µA is 1 mAhr
21 hours deep sleep @ 10 µA is 0.2 mAhr
Assuming AA cell capacity of 2200 mAhr @ 1.5V, two cells have 2200 mAhr capacity @ 3V.
Battery life = (2200 mAhr)/13.2 mAhr = 167 days or 5.5 months
We arrived at this solution in stages. Given that the remote controller's microcontroller draws around 50 mA when running in normal mode, it was always clear that it would have to be put it into some type of sleep mode or the batteries would be drained in less than two days (2200 mAhr/50 mA = 44 hr). What wasn't immediately clear was that even in a low-power mode, the particular microcontroller we selected still drew enough current to restrict the original battery life to just over three months. This battery life was a good start, but as we had to make some changes to the power circuit anyway (some units had a slight whine and we measured more noise on the power bus than we were happy with) we added a feature where the microcontroller could be completely powered off. (The system then entered the 10-µA mode described above). When awakening from this mode, the device has to undergo an approximately 1.5-second "reboot" time.
|
Avoiding interference
The ITU's regulations governing the 2.4-GHz ISM band dictate that devices operating in this band in range of one another should not experience serious degradation of function. The ITU advises either DSSS or FHSS. In the latter case, transmission is limited to no more than 400 msec on a single channel.
The Nordic Semiconductor nRF2401A selected for Tuneview features an FHSS scheme. That meant we had to include a frequency-hopping algorithm when designing the custom link protocol. The algorithm commenced by creating a base channel and hop table from each Tuneview's unique serial number. The base unit has a default-pairing channel on which two units initially locate each other.
Once "paired" the two units allocate a pseudorandom "synchronization channel" that they both return to if they get out of sync. During normal communication, the remote control signals the base of a frequency channel change two to three times a second. Built into this is a scheme that registers channels plagued by higher-than-average error rates, and temporarily removes those channels from the table. This adaptive algorithm avoids interference from (or with) Wi-Fi and Bluetooth devices in the vicinity in addition to allowing several Tuneview units to operate in close proximity.
In some ways, the communication protocol was the "fun" part of the project, given our experience. The SNR of even the best wireless communication is somewhat like the signal quality of very early telephone modems and nothing like most modern wired communications. Since the radios are essentially wireless half-duplex modems, we started with well-known communications primitives that created a basic error-correcting transport mechanism. Since the Nordic part didn't indicate when it had finished transmitting, we paid special attention to the timing requirements and experimented until we got a transport mechanism that made good use of the available bandwidth. We then enhanced it with appropriate fallback and recovery mechanisms to deal with cases where a good link degraded over time because, for example, the end user walked with the remote control away from the base unit.
Next, we added frequency hopping by supporting link-level channel-change messages. The key to getting this right is to have a very deterministic timeout and agreed-upon "base" channel that all devices return to quickly if the link is lost. Finally, we put in the support for device pairing and the generation of unique "jump channel tables" based on the unit's unique serial number.
One interesting side note on the protocol was that we found it was advantageous to use a frequency-hopping radio because this allows certain leeway while still following the ITU and FCC regulations to pick the exact time of the "hop" in order to optimize throughput. In Tuneview's case, we did this by postponing the hop until after completion of the transmission of the current message while remaining within the 400 msec average regulation time.
Once the team had radios and firmware that were more or less working, had achieved the specified range (over 50m through several walls) and an acceptable SNR (or BER), it was time to start thinking about certification. Unfortunately, US FCC and European CE testing (FCC Section 15.247 and CE EN 300 328) seemed to indicate that the implementation was significantly over the limit (15.247 basically requires all radiation outside the fundamental to be 20 dB below that in the fundamental band) at both the second and third harmonic (i.e. 4.8 GHz and 9.6 GHz) (see Table 1). Consequently, we concluded that the radios would need shielding.
The next stage of the project was the team's most painful experience and one of which readers who are contemplating RF design should take special note.
We embarked on several months of redesign of the assembly and the PCB, and the design and early testing of a new "ground bucket" for the radio "bars" closer than ¼ wavelength at 2.4 GHz (approximately 20 mm) (). We got this to work well for the first two prototypes, and they passed the certification tests (with reasonable margins). Next, production started with shield parts that had been quick to tool but which were expensive on a per-piece basis.
We subsequently moved onto engineering the third unit of the product (using the exact same radio circuit and layout). (The first and second units comprised the remote control and iPod dock. The third unit was a USB dongle that attached to a Mac or PC.) However, when we came to test this redesign, we found to our dismay that the certification lab had incorrectly insisted we test the previous two units using constant carrier, rather than modulated carrier. The standard effectively measures the average power over a defined period of time. The modulated carrier (i.e. ShockBurst mode) does not keep the transmitter on continuously, hence radiates less average power. It turns out the regulations state the test should be conducted with the radio operating as closely to the actual end-user case as possible—in other words, using the modulated carrier.
The key lesson we learned—the hard way—was that you couldn't rely on the test lab to know exactly how the testing should be conducted. You have to find out for yourself what tests are needed.
Another important lesson concerns the vendor. Sometimes it pays to listen closely to them even if your instincts are against it. Nordic Semiconductor told us we shouldn't need shields for our application, even though we were using a 12-dB power amplifier to boost the range. The team was reticent to accept this input because the example Nordic used to reinforce the point was a very dissimilar consumer product with no power amplifier and which used only one-way communication. The initial testing confirmed our hunch and we discounted Nordic Semiconductor's advice and spent months designing shields.
However, when the correct tests were conducted, Nordic Semiconductor proved correct. I can't help wondering if they had one or more other customers who were doing something close to what we were doing, had shown they didn't need shields, but whom Nordic Semiconductor couldn't talk about.
Differentiate using RF
Our progress from RF novices to competent RF engineers was rough and eye opening, but extremely educational. In this one project, we made almost every mistake and had to dig ourselves out of many holes. We saw first-hand every alternative, every possible way things could go wrong and what happened when they did. This was not good for the project at hand, due to the costs and time delays, but it was a superb teaching experience.
Among other things, it became clear that direct measurements of key circuit characteristics were essential. In our case, this meant working closely with the consultant who had a lab and the appropriate equipment. We also learned that digital radio communications is something of a trip down memory lane, at least for those old enough to remember the telephone modems of the 1970s. Lots of microcontroller sleep is the key to good battery life. Clean power is critical, as is respect for the highly analog nature of RF circuits. FHSS can be a better interference avoidance scheme—especially for burst transmissions—than DSSS if the communication protocol is tuned correctly. And standards have their place: you have to follow the regulatory requirements and standards-based protocols are good for ensuring the interoperability of devices from multiple vendors.
At the end of the project, we have a highly versatile two-way radio with excellent range (50 to 70m through walls) that scales well and operates without clashing with Wi-Fi and Bluetooth (due to the highly adaptable frequency hopping scheme we devised). The radios power two different current products that are doing well and provide excellent IP for several prospective OEM projects. Perhaps the main benefit of the project wasn't the actual products—although they are selling well—but the addition of important RF skills and experience to the Keyspan Engineering portfolio.
If the Keyspan team had it to do all over again, we would ask the following questions early on:
1) Do the expected product volume and revenue reach numbers that adequately fund an RF device development budget, and
2) Is the product cost-sensitive enough to justify building a discrete RF circuit?
If the answer to either is no, we'd use a module.
京公网安备 11010802033920号
