Ask any IoT vendor what makes their product exciting? They all point to applications, the unique ways in which devices deliver value to users. Therefore, it makes sense to focus your development resources on your application: first, last, and always. However, for your application to work, you need a reliable connection. This comes from technologies like Bluetooth Low Energy (BLE).

Bluetooth Low Energy is an excellent choice for connecting IoT products with mobile devices and/or the cloud. It's flexible, reliable, widely supported, and battery-friendly. There's just one problem: Opening up the BLE SDK and looking at the API, even the most experienced developer runs into a wall of complexity.

Learning to deal with this complexity takes a lot of resources, better redirecting resources to the features that make your product unique. From the user's perspective, connections just need to function. But while the BLE stack is largely invisible to the user, it requires a lot of expertise to optimize. Frankly, it's because the BLE code is a bit weird.

Confronting the Complexity of Bluetooth Low Energy

Typical APIs in a BLE stack are full of unfamiliar terms like GAP, GATT, CCCD, and "blob request". The code obeys its own set of rules and is not well documented. This adds cost and complexity in the development cycle of any IoT product.

Additionally, a BLE system requires three areas of development, each of which must work seamlessly with the next:

Firmware Development: This is the embedded software that runs on the chipset. Firmware must be configured and optimized to get data where it is needed, when it is needed, without damaging the battery. Chances are, the firmware developers on your team won't have a lot of pre-existing knowledge of Bluetooth.

Mobile App Development: Mobile developers are usually experts in iOS, Android, or both, not Bluetooth. Many Bluetooth features on mobile devices are confusing and undocumented, so developing BLE expertise from scratch takes a lot of time.

System-level architecture: Bluetooth development challenges for firmware and mobile are similar. But there are also system-level difficulties. Firmware and mobile developers must agree on common parameters, behavior and communication details. This collaboration must run through the entire production timeline; otherwise, you will run into interoperability gaps.

So, how to solve the complexity of BLE stack? You basically have three options, only one of which is the right choice for most IoT projects.

Three Paths to Bluetooth Low Energy Development

如果您正在构建物联网设备，您将拥有一个开发团队：固件开发人员、移动开发人员，或者可能只有一名专家处理系统的两侧。诀窍是为您的开发人员提供他们所需的工具，以创建健壮、可靠的蓝牙连接，没有错误或互操作性缺陷，并且不会超出时间或成本。

以下是实现蓝牙低能耗开发的三种方法。它们按降序排列，在简单性、成本节约和更快的上市时间方面从最差到最佳。

3、花时间学习蓝牙的所有知识

蓝牙开发的第一个选择是开发自己的内部专业知识。说起来容易做起来难。如果固件和移动开发者没有蓝牙的经验，那么iOS、Android和芯片制造商提供的库就没什么意义了。例如，GAP和GATT是什么？应如何设置PDU和MTU大小？应使用哪些连接参数，以及如何配置这些参数？

开发BLE系统几乎就像在没有课本的情况下学习多种新语言。很多专业知识基本上都是部落知识：你必须花很多时间在晦涩难懂的论坛上。这种形式的自我教育非常耗时。这也增加了出错的风险。通常，这些错误直到产品发货后才变得明显。

那么下一个选择是什么？

2、聘请蓝牙低能耗顾问

如果你没有时间进行自我训练，你可以随时寻求外界的帮助。不幸的是，专门从事BLE的软件顾问很少。它们也相当昂贵。因此，咨询路线的第一个缺点是成本。

事实上，许多咨询公司实际上并不是蓝牙专家。大多数人都是多面手，在涉及微控制器和协议组合时知识渊博，但在BLE独特的生态系统中却不那么丰富。

考虑到与蓝牙顾问合作的成本和复杂性，您可能希望探索另一条路线。这让我们找到了最有效的方法，通过现有的开发团队将BLE功能带到您的物联网产品中，并且没有陡峭的学习曲线。

1、使用蓝牙低能耗中间件平台

蓝牙低能耗中间件平台是位于蓝牙堆栈和应用程序之间的软件层：固件和移动两者。该中间件使用简化的API将芯片供应商令人困惑的代码重新格式化为熟悉的英语可读语言。它去除了芯片生态系统中内置的许多不必要的功能集，同时预先优化应用程序以满足您的独特目标，无论是高吞吐量、低能耗、安全性，还是这三个目标。

该中间件支持固件开发人员和移动开发人员，同时简化了包含这两个世界的整体系统架构。简而言之，中间件允许任何开发人员创建可靠、优化的BLE系统，而无需成为（或雇佣）专家。在某种意义上，中间件是您的专家。通过中间件揭开蓝牙低能耗开发的神秘面纱，您的团队可以专注于使您的产品与众不同的功能。