When evaluating Bluetooth solutions, consider all the different features as well as your product’s longevity.

“For some reason people take their cues from price action rather than from values. Price is what you pay. Value is what you get.” – Warren Buffet

Let’s get right to the point. As a veteran of the embedded wars going back to when “embedded” became something more than the market dominance of Microsoft and Intel (“WinTel”), I continue to be fascinated by the idea of a “free lunch.” Depending on which pocket you choose to pay for software, hardware, or tools, the idea of free remains part of the FUD legacy.

If you pay nothing for software (like the Bluetooth that’s already embedded in chips or RTOSs) but it costs you 50 percent more in development costs and perhaps significant time in opportunity costs associated with delayed time-to-market, is free Bluetooth really free? It depends on who is counting. Short of having definitive data to either support or to deny the claims of Linux, open-source software, or free Bluetooth, developers, their managers, and CFOs can be mislead into undertaking development efforts that can prove to be more costly that using commercially available software.

Let’s look to the issues surrounding wireless protocols in general and Bluetooth in particular. This information is based on the results of the 2015 EMF Embedded Developers Survey (1061 responses). Here are the percentages of wireless technologies used in embedded designs:

If we had added up all of the uses of the Wi-Fi protocols, we’d have a number that’s larger than Bluetooth. Developers that use one Wi-Fi protocol are inclined to use several Wi-Fi protocols.

So we’ve established that Bluetooth is an important protocol for embedded and IoT applications. Let’s look at the comparisons between Bluetooth user data (free and not free) and Wi-Fi and “other” wireless protocol users.

From the table, we see that when comparing free and commercial Bluetooth user data along with Wi-Fi and other wireless protocols, Bluetooth in general offers a lower cost of development. The comparative development time between free and commercial Bluetooth appears to be the same. However, three is a significant difference between behind schedule completions. This is an important finding.

Let’s look at “design outcomes” as a further comparison between the free and non-free versions of Bluetooth. As part of the survey, embedded developers were asked “How close was your final design outcome to your pre-design expectation?” The possible responses were “within 10 percent, 20 percent, 30 percent, 40 percent, or 50 percent, or not within 50 percent.”

I believe that within 10 percent is an exceptional design outcome and within 20 percent is a very good design outcome. Developers were asked to answer the question for “Performance” and for “Systems Functionality.” The results are presented in Table 2.

When we compare the developments that use the free and non-free Bluetooth protocols for on-time completions (100 percent – behind schedule completions) and for design outcomes, it becomes abundantly clear that the free Bluetooth protocols have a cost burden that’s imposed on developers and their developments.

This should come as no surprise. Chip vendors that offer free Bluetooth do so to enhance their chip sales. Freescale, for example, offers the MQX RTOS free with its chips. This is quite strange since the vast majority of developers use VxWorks with Freescale processors. Apparently there’s a marketing disconnect between marketing and sales at Freescale.

What do developers get when they buy a Bluetooth protocol stack and not use a free one? Maintenance is a continuous issue and when a free stack is used, the developer must either have his own staff deal with issues or rely solely on the open-source community. This is fine some of the time, but there are other occasions where more control over the commercial product is required.

Alternatively, when a stack is purchased, maintenance, update, and support can be obtained from a team of experts in the technology and their implementation of the protocol stack. This level of service means that dedicated staffs aren’t required for this area. Instead, these staffs can be available for the many other aspects of product maintenance.

There are also development advantages, as commercial stacks will often offer an ecosystem rather than just the stacks. This could include design environments and debug tools and evaluation hardware. Such an ecosystem contributes greatly to on-time and on-budget projects.

Finally, qualification is a complex, costly, and time-consuming task with some open-source stacks. This task is greatly simplified by a commercial stack that comes as a qualified component and is backed up by the people experienced with the testing and qualification process.

In summary, here’s why taking the Bluetooth stack provided by chip suppliers may not always be the best option:

It creates dependencies that are best avoided; if a product is to be in the field for many years, end-of-life (EOL) issues must be dealt with. Choosing software that’s provided with a chip then means that the software will also need to be changed when the hardware goes EOL. This is double trouble. It’s better to pick a Bluetooth stack that has an abstraction layer so that the same upper layer software will run despite changes to the hardware. Increase quality and performance by choosing an independent stack.

Other than the dependency on the hardware vendor, there’s the issue of meeting requirements. What if the required functionality or RTOS isn’t supported or if the required quality isn’t provided? Let’s face it. Chip vendors are in the numbers game and as such, must cater to the mainstream. But what if you want to create functionality that’s beyond mainstream? The choice in these situations is to pick an independent stack vendor, one that specializes in Bluetooth technology and takes the time to provide for new innovative functionality.

Jerry Krasner, Ph.D., MBA, is the Vice President of Embedded Market Forecasters and its parent company, American Technology International. A recognized authority with over 30 years of embedded industry experience, Dr. Krasner was formerly Chairman of Biomedical Engineering at Boston University, and Chairman of Electrical and Computer Engineering at Wentworth Institute of Technology and Bunker Hill Community College. In addition to his academic appointments, Dr. Krasner served as President of Biocybernetics, Inc. and CLINCO, Inc., Executive Vice President of Plasmedics, Inc. and Clinical Development Corporation, and Director of Medical Sciences for the Carnegie-Mellon Institute of Research. Dr. Krasner earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology/Biophysics from Boston University, and an MBA from Nichols College.