One questionable early decision made for some trouble down the road.
In its basic form, this looks like a fairly simple, straightforward design. However, as most of you know, very rarely is anything simple about any design. In this case, the object of the Tear Down was a remote-controlled car, not unlike lots of remote-controlled cars used by kids all over the world.
The end product, a Masserati, was manufactured by Nikko of Japan, one of the world's largest manufacturers of such products. What made this toy different from other remote-control cars is that it could be controlled by a Motorola iDEN mobile handset, in addition to the traditional remote. A separate module that holds the wireless capabilities is plugged into either the standard remote or into the handset. By plugging into the handset, the car gives the user feedback, like speed and direction.
|For a full archive of articles and related On-Demand seminars, click here|
The original concept was conceived by Steve Bozzone, an engineering manager at Motorola, who formed a small team to create a prototype. Bozzone led the project all the way through manufacturing and shipping.
The original idea was conceived in February 2004, with the first prototype coming that summer. At that point, a manufacturing partner was needed, which is where Nikko entered the picture.
The car was developed as part of an iDEN promotion for Nextel, a sponsor of NASCAR racing. Hence, the first design was done both as a Masserati and a NASCAR vehicle.
A few key parts
As shown in Figure 1, the car's pcb basically contains two key ICs, both from Freescale: a 13192-4534 wireless transceiver and a M9S8GT60 microcontroller. The Freescale parts were chosen thanks to the long relationship between Freescale and Motorola's iDEN division (note that both groups were part of Motorola at the time). That particular chip set was simultaneously being looked at for other applications. The Masserati was one of the first end products to use that chip set.
The remote control contains a PIC microcontroller from Microchip. That part was chosen for two reasons: it cost less than anything else that was available, and the engineer responsible for designing the remote was familiar with the architecture.
While the 2.4-GHz transceiver is capable of running a ZigBee stack, the Motorola designers opted for a proprietary wireless protocol because it allowed them to use an MCU with less memory.
“Looking back, we might have been better off going with ZigBee,”says Bozzone, “but it was pretty early in the ZigBee days. Going with ZigBee would have made it compatible with other devices. And now a more integrated part is available, so rather than use two ICs, it could be done with one. That would have cost less.”
Dealing with the slump
The biggest design challenge had to do with a “voltage slump.” Typically, remote-control cars are designed with separate power sources for the motors and the logic. Six batteries total are generally used, with four running the motors and two running the logic. Motorola opted to go with four total.
This thinking was to reduce the cost, weight and area required by getting all the power from one set of batteries. However, when the motors were drawing a lot of current, the voltage would slump down and the microcontroller would reset. Bozzone notes, “It seemed like a good idea at the time. But it's something we would do differently if we were doing it again.”
Newer isn't necessarily better
The package that housed the transceiver caused some solderability issues. A QFP, which was not available at the time, would have been a better choice. Nikko wasn't that familiar with LGA technology, so there was a learning curve for them to use that device. Their factory, by Motorola standards, is very low tech. So introducing that part into their process was a challenge.
There's an identical transceiver, the MC13192, at each end of the transmission, one in the dongle that attaches to the remote and one in the car. As you can see in Figure 2, the chip is housed in a 5- by 5-mm package.
According to Ryan Kelly, a marketing applications manager for ZigBee applications at Freescale, “They're not running the ZigBee protocol, but they could have opted for it. ZigBee is the networking layer that runs on top of the 15.4 physical and MAC layers. In other words, the car uses the same radio and MAC software that ZigBee would use, but not the ZigBee software.”
ZigBee, sort of
ZigBee is a sophisticated networking layer and would be overkill for this application. All that software is written by Freescale. ZigBee employs a mesh network, being able to cover large areas with redundant paths through the network. It also offers interoperability, whereby other compliant controllers could have been used with the car.
The MCU is part of the MC9SO8GT family. It comes in various flavors, with the amount of flash and RAM differentiating them. Motorola is using the GT60. To run the 802.15.4 MAC, about 60 kbits of memory are needed. Note that like the transceiver, the same MCU is used in both the remote dongle and the car. The MCU and transceiver communicate over a four-wire SPI interface.
There was also an “issue” with the antenna. The transceiver contained separate transmit and receive antennas. And it wasn't discovered until too late that the antennas were too close together.
The mechanical issues turned out to be easier than the electrical issues, thanks to the expertise of Nikko, who handled all the design aspects of it, like tooling up the parts. But to them, the board was like a black box. They didn't make any changes there whatsoever. Motorola simply forwarded the necessary files and Nikko created and populated the boards.
The final problem to deal with, one that didn't crop up until the final stages, was that the car's electronics, particularly the wireless subsystem, was susceptible to humidity. Tests performed in the Motorola lab were quite different from the tests performed in Nikko's manufacturing facility in Malaysia, where it's very humid. That, combined with a not-so-efficient antenna, creates a car with less than optimal range.
Richard Nass is editor in chief of Embedded Systems Design magazine. He can be reached at .
The candor and openness of this article is refreshing, and makes it all the more effective as a warning of what NOT to do next time. Thanks –
Castro Valley, CA