Why Bluetooth Low Energy Still Trips Up Engineers — Even in 2025

Bluetooth is everywhere. From smart locks to wearables, it’s the silent enabler of countless IoT devices. But according to Muhammad Kasim, founder of NovelBits, engineers still stumble when trying to implement Bluetooth Low Energy (BLE)—and the reasons aren’t what you’d expect.

“You’d think that after 3,200 pages of spec, everyone would be on the same page,” Muhammad says. “But BLE is more complex in practice than on paper.”

In this interview, Muhammad shares his insights from nearly a decade of helping teams integrate BLE. He outlines the root causes of design complexity and what engineers need to consider—beyond the datasheet—when picking a Bluetooth platform.

From Embedded Engineer to BLE Educator

NovelBits began in 2015 after Muhammad, an embedded engineer by background, noticed a recurring issue: there was a serious lack of accessible training on Bluetooth Low Energy. Despite BLE being on nearly every smartphone and embedded roadmap, few developers understood how to implement it properly—especially when switching between chip vendors.

Today, NovelBits provides technical content, training, and consulting for both product developers and chip vendors, helping bridge that knowledge gap.

BLE’s Double Life: Classic vs. Low Energy

One of the biggest points of confusion? Bluetooth’s dual standards.

• Bluetooth Classic is what powers audio streaming—think headphones and car infotainment.
• Bluetooth Low Energy (BLE) is designed for battery-powered, always-on devices—like wearables, medical sensors, and smart locks.

BLE opened the door for ultra-low-power connectivity, but it also brought new complexity. BLE specs are vast and modular—many features are optional. That flexibility is great for innovation, but it means every chip vendor implements BLE slightly differently.

The Real Problem: The Messy Middle

Even if every chip complies with the BLE spec, Muhammad explains that the real issues emerge at the SDK (Software Development Kit) layer. This is the environment where embedded developers actually interface with the Bluetooth stack—and it’s where consistency falls apart.

“The spec might be universal, but the SDKs definitely aren’t,” Muhammad says. “Each vendor adds their own tools, APIs, and workflows. That’s where the confusion starts.”

This fragmentation means developers often have to relearn the BLE stack every time they switch vendors, even if the hardware capabilities are similar. And with the rise of Zephyr RTOS and Visual Studio Code-based development environments, the ecosystem is changing fast.

How to Choose the Right BLE Platform

According to Muhammad, engineers should evaluate potential Bluetooth solutions across both hard specs and soft factors:

Core Technical Considerations:

• Does the chip support features you need? (e.g., Long Range mode, high-throughput modes)
• Is the SDK well-documented and flexible?
• What’s the real-world power consumption in your use case?

Soft Skills That Matter:

• Developer support and community engagement
• Availability of debugging and power profiling tools
• Track record in your specific industry (e.g., medical, consumer, industrial)

“You’re not just choosing a chip. You’re choosing a partner in your product’s development journey,” Muhammad emphasizes.

Final Thoughts: Beyond the Spec Sheet

This interview highlights a key truth in embedded development: specs only tell part of the story.

To build reliable, power-efficient, connected products, engineers need to understand not only the BLE protocol but also the nuances of SDKs, vendor ecosystems, and real-world trade-offs.

If you’re planning a new Bluetooth-enabled product, don’t start with the spec sheet—start with the right strategy.