如何应对如此多的蓝牙开发阻碍？

Question

背景

我的团队一直在尝试实现蓝牙 LE“api”一段时间。我们决定使用 BLE 而不是传统蓝牙，因为 iOS（我们的客户端设备类型之一）阻止任何不在其批准列表中的人使用传统 BT。我们主要使用在带有 Ubuntu Server 22.04 LTS 的小型边缘设备上运行的 Intel AX200/AX201 蓝牙硬件。尽管我们还使用 Raspberry Pi 4 和 nVidia Jetson 进行了一些开发测试。

在意识到 BLE 没有真正的 Java（我们的核心语言）桥接器/绑定后，我们在 StackOverflow 上得到了指导，建议 Linux 上的大多数自定义 BLE 都是通过自定义 BlueZ 源并将其自定义 GATT 特征添加到 BlueZ 源来完成的（例如修改

gatt-database.c

），所以我们就走了那条路。我们的少数特征非常简单，我们不是将所有业务逻辑构建到 BlueZ 源代码中，而是通过

popen

/

printf

/

read

调用 shell 脚本并与之交互，这些脚本处理大部分“业务逻辑” ，大大减少了微小更改所需的 BlueZ 重新编译量。

问题

也就是说，即使是最简单的特性，我们也很难让低功耗蓝牙发挥作用。一些蓝牙“客户端设备”具有可靠的连接，而其他客户端设备似乎有超过 50% 的“丢失”GATT 写入/读取，并且极其不可靠。也许这只需要一些重试处理，但也......

我们一直看到，每当我们的 Ubuntu/BlueZ 堆栈进入某种“故障”状态时，实际的 BT 硬件就会完全变砖，直到我们执行完整的电源循环。只有在硬重启后，我们才能再次看到正常行为。

与此同时，蓝牙无处不在，虽然即使是由谷歌/苹果等大公司制造的蓝牙也存在令人难以置信的错误，但它至少看起来可以通过一些小的戳/重试来工作。

BlueZ+Ubuntu 对于我们来说似乎太不可靠/有缺陷，无法使用它，我们正在考虑使用基于 UART 或以太网的接口，但在认输之前我想问一下......

问题

我们真的遗漏了一些重要的东西吗？产品如何在基于 Linux 的系统上成功使用 BLE？ BlueZ 对每个人来说都是绝对可怕的吗？我们应该使用不同的库吗？我们应该使用不同的硬件吗？

我的问题可能很模糊，因为我们甚至不知道根本问题是什么，除了 BLE 对我们来说是一个充满错误的混乱之外。

Answer 1

我猜大多数使用 BlueZ 的人都使用 DBus API (https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc)，任何有客户端的语言都可以使用它DBus 的库，而不是修改 BlueZ 的源代码。

如果您想尝试与 BlueZ 完全不同的解决方案，您可以在 https://github.com/Emill/node-ble-host 尝试我的库，在我看来，它更易于使用。然而它是为 Javascript 编写的...

仅供参考，大多数 BLE 产品不使用 BlueZ。 Android 和 iOS 都有自己的实现，嵌入式产品（“裸机”）使用芯片制造商提供的蓝牙堆栈。