Upgrading to bluetooth AFH

Even though the revised Bluetooth spec with AFH (adaptive frequency hopping) is not due for many months, many vendors offer Version 1.2 Bluetooth devices. In other words, they offer a proprietary AFH scheme that you will be able to update to the AFH spec through a firmware upgrade. As nice as this upgrade sounds, it poses some significant engineering issues.

Although you can upgrade devices that you haven't yet shipped, devices in consumers' hands are another story. Somehow, you have to get the consumer to either load the upgrade or connect the device to the Internet. Then, you have to enable the device to complete a robust hot-upgrade; the device cannot crash if the upgrade doesn't complete, and the device has to run the code it is replacing while loading the new code and then make a successful changeover. You also need to prevent hackers from upgrading unsuspecting user's devices with rogue code. None of these engineering prospects is simple.

Another obstacle is how to store the upgrade. Many vendors store firmware in ROM to keep their chip set's price less than $5. Thus, to upgrade the firmware, you need to supply external flash, which drives up the total price of your device—a consequence vendors don't like to point out. Note that some AFH schemes can require significant amounts of processing; you need to leave some headroom on the processor; otherwise, you might see reduced performance in your application when you implement the upgrade.

Finally, there's the issue of compatibility with non-AFH devices. Dealing with legacy equipment calls for a strategy similar to the one targeting devices that simply don't play well with others: product churn. Devices that cause problems do not succeed in the market. People will bring back a Bluetooth headset, not a Bluetooth phone. For more on recent Bluetooth developments, see "Bluetooth interoperablility: It's all in the details" on pg 55.