我的团队一直在尝试实现蓝牙 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 对我们来说是一个充满错误的混乱之外。
我猜大多数使用 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 都有自己的实现,嵌入式产品(“裸机”)使用芯片制造商提供的蓝牙堆栈。